> Between Rust and Zig, the problems of C++ have been solved much more elegantly
Those languages occupy different points in the design space than C++. And thus, in the general sense, neither of them, nor their combination, is "C++ with the problems solved". I know very little Rust and even less Zig. But I do know that there are various complaints about Rust, which are different than the kinds of complaints you get about C++ - not because Rust is bad, just because it's different in significant ways.
> It is so objectively horrible in every capacity
Oh, come now. You do protest too much... yes, it has a lot of warts. And it keeps them, since almost nothing is ever removed from the language. And still, it is not difficult to write very nice, readable, efficient, and safe C++ code.
> it is not difficult to write very nice, readable, efficient, and safe C++ code
That's a fine case of Stockholm Syndrome you've got there. In reality, it is hard. The language fights you every step of the way. That's because the point in the design space C++ occupies is a uniquely stupid one. It wants to have it's cake and eat it too. The pipe-dream behind C++ is that you can write code in an expressive manner and magically have it also be performant. If you want fast code, you have to be explicit about many things. C++ ties itself in knots trying to be implicitly explicit about those things, and the result is just plain harder to reason about. If you want code that's safe and fast, you go with Rust. If you want code that's easy and fast, you go with Zig. If you want code that's easy and safe you go with some GCed lang. Then if you want code that's easy, safe, and fast, you pick C++ and get code which might be fast. You cannot have all three things. Many other langues find an appropriate balance of these three traits to be worthwhile, but C++ does not. It's been 40 years since the birth of C++ and they are only just now trying to figure out how to make it compile well.
Even Cobol code hasn't been ported in it's entirety, and the whole codebase at the peak was probably orders of magnitude smaller than C++. It's also far easier to port Cobol - with it being used mostly for data processing and business logic - than C++ that was used for all manners of strange, esoteric and complicated pieces of software requiring thousand to millions of man-hours to port (for example most of Gecko and Blink).
C++ will be here forever, at least in some manner.
We can all at least appreciate that COBOL is something you try to get rid of where possible. If we took the same attitude to C++ as we do COBOL, then I think the issue would be much less severe.
That in and of itself is a failure. The decision to continually bolt more stuff onto this mess instead of developing a viable alternative is honestly painful. When you look at something like Zig, it gets you much of what C++ offers and in a way that doesn't cause you pain. Is the argument that Zig simply wasn't possible 30 years ago? I doubt it. As best I can tell, Zig comes as the result of a relatively experienced C programmer making the observation that you could improve C in a lot of easy ways. Were it not for the existing mess, he might have called his language C++. Instead a Scandinavian nut-job decided to heap some mess on top of C and everyone just went along with it.
Honestly, I am a happier and more productive developer since left C++ behind for other languages. And it's not just the language, but the lack of ecosystem too. Things like the build system, managing dependencies, etc, all such a pain compared to modern languages with good ecosystem (Rust, Flutter, Kotlin, etc)
Rust doesn't "depend" on LLVM in the sense you seem to imagine, you can instead lower Rust's MIR into Cranelift (which is written in Rust) if you want for example.
LLVM's optimiser is more powerful, and it handles unwinding, so today most people want LLVM but actually I think LLVM's future might involve more Rust.
Ok, but please don't fulminate on Hacker News. We're trying for something different here.
https://news.ycombinator.com/newsguidelines.html
> Between Rust and Zig, the problems of C++ have been solved much more elegantly
Those languages occupy different points in the design space than C++. And thus, in the general sense, neither of them, nor their combination, is "C++ with the problems solved". I know very little Rust and even less Zig. But I do know that there are various complaints about Rust, which are different than the kinds of complaints you get about C++ - not because Rust is bad, just because it's different in significant ways.
> It is so objectively horrible in every capacity
Oh, come now. You do protest too much... yes, it has a lot of warts. And it keeps them, since almost nothing is ever removed from the language. And still, it is not difficult to write very nice, readable, efficient, and safe C++ code.
> it is not difficult to write very nice, readable, efficient, and safe C++ code
That's a fine case of Stockholm Syndrome you've got there. In reality, it is hard. The language fights you every step of the way. That's because the point in the design space C++ occupies is a uniquely stupid one. It wants to have it's cake and eat it too. The pipe-dream behind C++ is that you can write code in an expressive manner and magically have it also be performant. If you want fast code, you have to be explicit about many things. C++ ties itself in knots trying to be implicitly explicit about those things, and the result is just plain harder to reason about. If you want code that's safe and fast, you go with Rust. If you want code that's easy and fast, you go with Zig. If you want code that's easy and safe you go with some GCed lang. Then if you want code that's easy, safe, and fast, you pick C++ and get code which might be fast. You cannot have all three things. Many other langues find an appropriate balance of these three traits to be worthwhile, but C++ does not. It's been 40 years since the birth of C++ and they are only just now trying to figure out how to make it compile well.
Even Cobol code hasn't been ported in it's entirety, and the whole codebase at the peak was probably orders of magnitude smaller than C++. It's also far easier to port Cobol - with it being used mostly for data processing and business logic - than C++ that was used for all manners of strange, esoteric and complicated pieces of software requiring thousand to millions of man-hours to port (for example most of Gecko and Blink).
C++ will be here forever, at least in some manner.
edit: spelling
We can all at least appreciate that COBOL is something you try to get rid of where possible. If we took the same attitude to C++ as we do COBOL, then I think the issue would be much less severe.
> It is so objectively horrible in every capacity,
Total hyperbole and simply not true.
> but it still somehow managed to limp on for all these years
Before Rust became somewhat popular, there was simply no serious alternative to C++ in many domains.
That in and of itself is a failure. The decision to continually bolt more stuff onto this mess instead of developing a viable alternative is honestly painful. When you look at something like Zig, it gets you much of what C++ offers and in a way that doesn't cause you pain. Is the argument that Zig simply wasn't possible 30 years ago? I doubt it. As best I can tell, Zig comes as the result of a relatively experienced C programmer making the observation that you could improve C in a lot of easy ways. Were it not for the existing mess, he might have called his language C++. Instead a Scandinavian nut-job decided to heap some mess on top of C and everyone just went along with it.
I guess someone had to make all these mistakes so that others can now learn from them :)
Honestly, I am a happier and more productive developer since left C++ behind for other languages. And it's not just the language, but the lack of ecosystem too. Things like the build system, managing dependencies, etc, all such a pain compared to modern languages with good ecosystem (Rust, Flutter, Kotlin, etc)
Start by removing Rust's dependency in GCC and LLVM, both written in C++.
Rust doesn't "depend" on LLVM in the sense you seem to imagine, you can instead lower Rust's MIR into Cranelift (which is written in Rust) if you want for example.
LLVM's optimiser is more powerful, and it handles unwinding, so today most people want LLVM but actually I think LLVM's future might involve more Rust.
It can, but until that becomes the reference implementation backend, it hardly matters.
Similar to how much Python folks disregard PyPy's existence.
I doubt LLVM project would start accepting polyglot contributions, beyond what they already do for language specific frontends.
Also, the ongoing GCC support is dependent on C++ as well.