5 ms·

There's a looming feeling that C++17 is really going to be the last version of C++ (practically, in production). The Vasa is now half-sunk [0][1], but the alter

There's a looming feeling that C++17 is really going to be the last version of C++ (practically, in production). The Vasa is now half-sunk [0][1], but the alternatives are yet to be truly born. The current issues surrounding the language standards: - The important but half-baked features of C++20 that has never really been polished enough for actual production usage (modules, coroutines) - Unnecessary "hyper-modern" C++ features which are dead on arrival (ranges) - The dramatic increase in build times due to the STL library (which are accelerated by those hyper-modern C++ features) [2] - The fleeing of LLVM/Clang engineers to other projects (as you've said, Apple engineers shifting work to Swift, and Google abandoning Clang and moving to Carbon). - Implosions in the ISO committee (notably the controversy surrounding the rape convict) It's really not looking good, but there aren't that much alternatives so I think people will just stick to C++17 for the moment. Listing the worthwhile competitors: - Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++. - Zig is still too unstable, they just finished reworking the compiler - Jai is not even released to the public - D might be a candidate but IMO they should really commit 100% fully for GC-less betterC mode... - Nim still has many warts and unbaked features, and also there was a split in the compiler team [3] [0] https://www.aristeia.com/TalkNotes/C++vstheVasa2-ups.pdf https://www.aristeia.com/TalkNotes/C++vstheVasa2-ups.pdf [1] https://www.stroustrup.com/P0977-remember-the-vasa.pdf https://www.stroustrup.com/P0977-remember-the-vasa.pdf [2] https://old.reddit.com/r/cpp/comments/o94gvz/what_happened_with_compilation_times_in_c20/ https://old.reddit.com/r/cpp/comments/o94gvz/what_happened_w... [3] https://github.com/nim-works/nimskull https://github.com/nim-works/nimskull

pjmlp 4y ago
I share the feeling, however I would point out C++23 as the last version, I think the ecosystem will still make it that far, afterwards is as you point out. Still, look at Fortran, Cobol, C, as examples of 50 - 60 old languages that aren't leaving us anytime soon.
- f1shy 4y ago
  The languages do not die in one day. In 30 years, maybe there are some people writing new code in C++38... and of course the immense code base already existing will stay for decades. What happens, is there is a steady descent in the number or people using it. I think it has started. I know even C++ fanboys/lawyers, that are having a lot of trouble to keep up with all features from present and past... And 99% of developers I know, even very good ones, speak of "my 20% C++". So my feeing is 17 is the last version which some people can use 100% of.
  - pjmlp 4y ago
    Not wanting to do public shaming, there are still tutorials being uploaded to YouTube using Turbo C++ for MS-DOS. While on the other hand I also have an issue keeping up with my 20% of JVM, CLR, V8, Azure, AWS,... I guess things eventually implode and we need to start from scratch.
    - Kwpolska 4y ago
      Those Turbo C++ tutorials tend to come out of India, and it’s because their schools are stuck teaching that. But those aren’t really tutorials for modern C++, they’re tutorials for C-with-classes at best.
      - pjmlp 4y ago
        Definitely, however many beginners don't know about it. Imagine a group of teenager, getting interested into C++ via the Arduino or Pi based school projects, they search YouTube for tutorials (as common practice nowadays) and land on such tutorials.
        jcelerier 4y ago
        That's not an hypothetical btw, I had students in France who fell into this
aliqot 4y ago
also carbon, which is brand new.
- cyber_kinetist 4y ago
  Well, yeah. The reason I didn’t include Carbon in this list is because even the first draft isn’t complete right now.
  - aliqot 4y ago
    > even the first draft isn’t complete right now. Aren't you comparing it to C++23
    - pjmlp 4y ago
      Even if incomplete, one can produce actual binaries that use C++23 features. We cannot say the same for Carbon.
zozbot234 4y ago
> Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++. Rust has a sensible model for language evolution, so its overly complex warts can be fixed over time. I do agree that unsafe Rust is not yet on par with the usability of C++ (given the huge pitfalls inherent in interfacing Safe and Unsafe Rust) but this is improving quickly.
vardump 4y ago
"- Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++." Isn't unsafe usage very low in most Rust codebases, with maybe about ten of unsafe LoCs if any? Sounds weird someone would attack Rust based on unsafe.
- 3a2d29 4y ago
  That’s not an attack. I think they are just trying to make the point that once you enter unsafe rust, you can use any unsafe language since the biggest benefit of rust is gone. Unsafe rust is not used often, they never argued that.
  - oconnor663 4y ago
    > since the biggest benefit of rust is gone I think it's more of a spectrum than this makes it sound. For example, an unsafe function that takes a &[u8] argument can still assume that that argument isn't null, isn't dangling, etc. Just because a function is unsafe, or uses unsafe, doesn't mean other functions are allowed to feed it garbage. (Other unsafe code could do that, but that's per se UB, and the other code is unambiguously at fault.) All the "safe types" are still there in the mix, and the compiler is still catching the usual mistakes you make with the usual safe APIs, even in an unsafe block. (Though this has downsides as well as upsides, because there are more ways that producing garbage/invalid values with unsafe code can lead to UB.)
- the__alchemist 4y ago
  Depends on the use case, and how deep into abstractions you're counting. Unsafe is very common in embedded (which is IMO one of the prime use cases for Rust), since you're doing reg writes, interacting with DMA etc.
tialaramex 4y ago
> Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++. Unsafe Rust is harder to write than C++, or at very least, writing correct unsafe Rust is mandatory whereas it seems like C++ programmers are very sloppy and the same attitude will not deliver in unsafe Rust. But the vast majority of software you're writing should be safe Rust, which is a much easier - the purpose of unsafe is to establish safe abstractions for your system and for a lot of use cases appropriate safe abstractions are already provided. > Unnecessary "hyper-modern" C++ features which are dead on arrival (ranges) Ranges is C++ catching up to where the rest of the world had already gone with ideas like "iterators" meanwhile. It's about as "hyper-modern" as the string_view or modules, both of which C++ was also very slow to get to.
einpoklum 4y ago
Can you elaborate regarding: * Google supposedly ditching from C++ to Carbon. Isn't Carbon some experimental initiative? i.e. wouldn't such a choice be considered in 5-10 years minimum, if ever? Has Google announced a move away from C++? * The "controversy surrounding the rape convict"
- pjmlp 4y ago
  The main Carbon contributors are those that ramped down their activities in clang after Google lost the ABI vote, so they decided to create their own toy away from ISO processes.
  - tialaramex 4y ago
    It's not so much about "the ABI vote", it's the larger direction summarised in P2137 ("Goals and priorities for C++"") As I understand it, P2137 was written to explicitly spell out the requirements so that there's an actual document saying C++ should prioritise safety and performance over compatibility, which WG21 voted against - making firm the fact that's not what C++ is about. Left to its own devices, WG21 prefers ambiguity. This is infuriating if you need X, and you tell people "I need X, I can't get that from C++" and they will tell you "No, I'm sure you can have X, maybe the committee just doesn't understand your need" and wasting your time. It needed writing down on paper to ensure there's no room for that ambiguity. Kate Gregory is one of the key Carbon people and if she had any "activities in clang" I'm not aware of them.
    - pjmlp 4y ago
      And in Rust one needs to write a RFC, and also not without going through endless discussion threads until a moderator locks them, in some more hot topics. True for Kate Gregory, but not for many others.
  - einpoklum 4y ago
    * Where do we know about this ramp-down from? * In the ISO C++ committee, people lose important votes all the time, again and again. Good features often take years before they gain enough support to be accepted. The committee - despite what the external perception might be - is actually quite hesitant and conservative, at least where it comes to affecting the behavior of existing code. In other words, there isn't such a thing as _the_ ABI vote, it's _an_ ABI vote. So it seems questionable that Google's whole C++ strategy would hinge on that one vote.
jcelerier 4y ago
I've been using c++20 in prod for a few years with concepts and coroutines and consteval from the things I have off my head, and things work fine in msvc/GCC/clang, what even are you talking about?
- snovv_crash 4y ago
  Ranges is spotty on clang and source_location is inconsistent between compilers, off the top of my head.
  - Kranar 4y ago
    Spotty is an understatement, concepts and coroutines are still very buggy and inconsistent between compilers as well. GCC and MSVC released an initial version of concepts two years ago that was far from complete. It's much better today but still no implementation is remotely good enough for production apart from some limited aspects.
grogenaut 4y ago
I was doing game dev in 2010-2013, and we had very partial support for C++11 features, depending on which platform we were on (playstation vs windows). We had fear that C++11 features would never be there, then saw the proposals for 2017 and were like "well that will NEVER happen"... Then the PS4 came out with good 2011 support and I think making progress on 2017. I believe the studio is full on 2017 support now. They're always purposefully 5 years behind so they don't fight insidious compiler bugs. A lot of these features are great and so they'll come in most compiles, maybe just not as fast as you want them. But the development happening for the PS2, PS3, PS4 and PS5, as well as windows and linux is massively different in the last 20 years. And it always seems like you're never going to get to use those new standards. And then one day they're just in your compiler and you are using them. If clang doesn't keep up, people will stop using clang. Just like they starting using it and LLVM everywhere somewhere in 08-14 after it came out in 2007. It's both a huge switch (short time frame) and also natural for a product major release (long time frame).
en4bz 4y ago
100% agree with this. There's nothing in the new standards past 17 that actually helps me in real life day to day work. Most of the new features are solely for code-golfers (see ranges). Mean while co-routines and other concurrency extensions have languished for years as TSs with only partial support. Here's the full list of TSs [1], half of which only have partial or no support despite being 5+ years old. [1] https://en.cppreference.com/w/cpp/experimental https://en.cppreference.com/w/cpp/experimental
- snovv_crash 4y ago
  Ranges is one of the few things in 20 that I really like - not having to do begin()/end() madness for stuff like sort, transform etc means you aren't thinking about the _how_ and can spend more time focusing on the _why_. It starts to feel like Unix command line with pipes, finally I can chain together the components I want without making tons of unreadable of intermediaries, and potentially without even any allocations if I play my cards right. I can also safely do transforms on vectors where intermediaries would require lots of memory, which would have meant "one big stonking for-loop" before. Ranges are amazing and I'm really annoyed clang is dragging its heels with proper support.
  - cyber_kinetist 4y ago
    It’s all fun and games until you actually use it in a non-trivial scale and you experience compilation times go through the roof. (Your Debug builds will also be really slow.) It’s just not a good feature to use in the current state of C++. https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/ https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
    - usefulcat 4y ago
      Just wanted to add that the linked piece is a really well articulated criticism of c++. I say that as someone who has been using c++ for about 30 years.
    - snovv_crash 4y ago
greatNespresso 4y ago
Was wondering what other competitors does C++ has beyond Rust and Zig, thank you for the list and detailed opinion

pjmlp 4y ago

I share the feeling, however I would point out C++23 as the last version, I think the ecosystem will still make it that far, afterwards is as you point out. Still, look at Fortran, Cobol, C, as examples of 50 - 60 old languages that aren't leaving us anytime soon.

f1shy 4y ago
The languages do not die in one day. In 30 years, maybe there are some people writing new code in C++38... and of course the immense code base already existing will stay for decades. What happens, is there is a steady descent in the number or people using it. I think it has started. I know even C++ fanboys/lawyers, that are having a lot of trouble to keep up with all features from present and past... And 99% of developers I know, even very good ones, speak of "my 20% C++". So my feeing is 17 is the last version which some people can use 100% of.
- pjmlp 4y ago
  Not wanting to do public shaming, there are still tutorials being uploaded to YouTube using Turbo C++ for MS-DOS. While on the other hand I also have an issue keeping up with my 20% of JVM, CLR, V8, Azure, AWS,... I guess things eventually implode and we need to start from scratch.
  - Kwpolska 4y ago
    Those Turbo C++ tutorials tend to come out of India, and it’s because their schools are stuck teaching that. But those aren’t really tutorials for modern C++, they’re tutorials for C-with-classes at best.
    - pjmlp 4y ago
      Definitely, however many beginners don't know about it. Imagine a group of teenager, getting interested into C++ via the Arduino or Pi based school projects, they search YouTube for tutorials (as common practice nowadays) and land on such tutorials.
      - jcelerier 4y ago
        That's not an hypothetical btw, I had students in France who fell into this

aliqot 4y ago

also carbon, which is brand new.

cyber_kinetist 4y ago
Well, yeah. The reason I didn’t include Carbon in this list is because even the first draft isn’t complete right now.
- aliqot 4y ago
  > even the first draft isn’t complete right now. Aren't you comparing it to C++23
  - pjmlp 4y ago
    Even if incomplete, one can produce actual binaries that use C++23 features. We cannot say the same for Carbon.

zozbot234 4y ago

> Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++. Rust has a sensible model for language evolution, so its overly complex warts can be fixed over time. I do agree that unsafe Rust is not yet on par with the usability of C++ (given the huge pitfalls inherent in interfacing Safe and Unsafe Rust) but this is improving quickly.

vardump 4y ago

"- Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++." Isn't unsafe usage very low in most Rust codebases, with maybe about ten of unsafe LoCs if any? Sounds weird someone would attack Rust based on unsafe.

3a2d29 4y ago
That’s not an attack. I think they are just trying to make the point that once you enter unsafe rust, you can use any unsafe language since the biggest benefit of rust is gone. Unsafe rust is not used often, they never argued that.
- oconnor663 4y ago
  > since the biggest benefit of rust is gone I think it's more of a spectrum than this makes it sound. For example, an unsafe function that takes a &[u8] argument can still assume that that argument isn't null, isn't dangling, etc. Just because a function is unsafe, or uses unsafe, doesn't mean other functions are allowed to feed it garbage. (Other unsafe code could do that, but that's per se UB, and the other code is unambiguously at fault.) All the "safe types" are still there in the mix, and the compiler is still catching the usual mistakes you make with the usual safe APIs, even in an unsafe block. (Though this has downsides as well as upsides, because there are more ways that producing garbage/invalid values with unsafe code can lead to UB.)
the__alchemist 4y ago
Depends on the use case, and how deep into abstractions you're counting. Unsafe is very common in embedded (which is IMO one of the prime use cases for Rust), since you're doing reg writes, interacting with DMA etc.

tialaramex 4y ago

> Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++. Unsafe Rust is harder to write than C++, or at very least, writing correct unsafe Rust is mandatory whereas it seems like C++ programmers are very sloppy and the same attitude will not deliver in unsafe Rust. But the vast majority of software you're writing should be safe Rust, which is a much easier - the purpose of unsafe is to establish safe abstractions for your system and for a lot of use cases appropriate safe abstractions are already provided. > Unnecessary "hyper-modern" C++ features which are dead on arrival (ranges) Ranges is C++ catching up to where the rest of the world had already gone with ideas like "iterators" meanwhile. It's about as "hyper-modern" as the string_view or modules, both of which C++ was also very slow to get to.

einpoklum 4y ago

Can you elaborate regarding: * Google supposedly ditching from C++ to Carbon. Isn't Carbon some experimental initiative? i.e. wouldn't such a choice be considered in 5-10 years minimum, if ever? Has Google announced a move away from C++? * The "controversy surrounding the rape convict"

pjmlp 4y ago
The main Carbon contributors are those that ramped down their activities in clang after Google lost the ABI vote, so they decided to create their own toy away from ISO processes.
- tialaramex 4y ago
  It's not so much about "the ABI vote", it's the larger direction summarised in P2137 ("Goals and priorities for C++"") As I understand it, P2137 was written to explicitly spell out the requirements so that there's an actual document saying C++ should prioritise safety and performance over compatibility, which WG21 voted against - making firm the fact that's not what C++ is about. Left to its own devices, WG21 prefers ambiguity. This is infuriating if you need X, and you tell people "I need X, I can't get that from C++" and they will tell you "No, I'm sure you can have X, maybe the committee just doesn't understand your need" and wasting your time. It needed writing down on paper to ensure there's no room for that ambiguity. Kate Gregory is one of the key Carbon people and if she had any "activities in clang" I'm not aware of them.
  - pjmlp 4y ago
    And in Rust one needs to write a RFC, and also not without going through endless discussion threads until a moderator locks them, in some more hot topics. True for Kate Gregory, but not for many others.
- einpoklum 4y ago
  * Where do we know about this ramp-down from? * In the ISO C++ committee, people lose important votes all the time, again and again. Good features often take years before they gain enough support to be accepted. The committee - despite what the external perception might be - is actually quite hesitant and conservative, at least where it comes to affecting the behavior of existing code. In other words, there isn't such a thing as _the_ ABI vote, it's _an_ ABI vote. So it seems questionable that Google's whole C++ strategy would hinge on that one vote.

jcelerier 4y ago

I've been using c++20 in prod for a few years with concepts and coroutines and consteval from the things I have off my head, and things work fine in msvc/GCC/clang, what even are you talking about?

snovv_crash 4y ago
Ranges is spotty on clang and source_location is inconsistent between compilers, off the top of my head.
- Kranar 4y ago
  Spotty is an understatement, concepts and coroutines are still very buggy and inconsistent between compilers as well. GCC and MSVC released an initial version of concepts two years ago that was far from complete. It's much better today but still no implementation is remotely good enough for production apart from some limited aspects.

grogenaut 4y ago

I was doing game dev in 2010-2013, and we had very partial support for C++11 features, depending on which platform we were on (playstation vs windows). We had fear that C++11 features would never be there, then saw the proposals for 2017 and were like "well that will NEVER happen"... Then the PS4 came out with good 2011 support and I think making progress on 2017. I believe the studio is full on 2017 support now. They're always purposefully 5 years behind so they don't fight insidious compiler bugs. A lot of these features are great and so they'll come in most compiles, maybe just not as fast as you want them. But the development happening for the PS2, PS3, PS4 and PS5, as well as windows and linux is massively different in the last 20 years. And it always seems like you're never going to get to use those new standards. And then one day they're just in your compiler and you are using them. If clang doesn't keep up, people will stop using clang. Just like they starting using it and LLVM everywhere somewhere in 08-14 after it came out in 2007. It's both a huge switch (short time frame) and also natural for a product major release (long time frame).

en4bz 4y ago

100% agree with this. There's nothing in the new standards past 17 that actually helps me in real life day to day work. Most of the new features are solely for code-golfers (see ranges). Mean while co-routines and other concurrency extensions have languished for years as TSs with only partial support. Here's the full list of TSs [1], half of which only have partial or no support despite being 5+ years old. [1] https://en.cppreference.com/w/cpp/experimental https://en.cppreference.com/w/cpp/experimental

snovv_crash 4y ago
Ranges is one of the few things in 20 that I really like - not having to do begin()/end() madness for stuff like sort, transform etc means you aren't thinking about the _how_ and can spend more time focusing on the _why_. It starts to feel like Unix command line with pipes, finally I can chain together the components I want without making tons of unreadable of intermediaries, and potentially without even any allocations if I play my cards right. I can also safely do transforms on vectors where intermediaries would require lots of memory, which would have meant "one big stonking for-loop" before. Ranges are amazing and I'm really annoyed clang is dragging its heels with proper support.
- cyber_kinetist 4y ago
  It’s all fun and games until you actually use it in a non-trivial scale and you experience compilation times go through the roof. (Your Debug builds will also be really slow.) It’s just not a good feature to use in the current state of C++. https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/ https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
  - usefulcat 4y ago
    Just wanted to add that the linked piece is a really well articulated criticism of c++. I say that as someone who has been using c++ for about 30 years.
  - snovv_crash 4y ago

greatNespresso 4y ago

Was wondering what other competitors does C++ has beyond Rust and Zig, thank you for the list and detailed opinion