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

[1] https://www.stroustrup.com/P0977-remember-the-vasa.pdf

[2] https://old.reddit.com/r/cpp/comments/o94gvz/what_happened_w...

[3] https://github.com/nim-works/nimskull

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.

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.

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.

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.

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.

That's not an hypothetical btw, I had students in France who fell into this

also carbon, which is brand new.

Well, yeah. The reason I didn’t include Carbon in this list is because even the first draft isn’t complete right now.

Aren't you comparing it to C++23

Even if incomplete, one can produce actual binaries that use C++23 features.

We cannot say the same for Carbon.

> 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.

"- 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.

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.

> 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.)

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.

> 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.

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"

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.

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.

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.

* 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.

It has come a few times on Reddit discussions complaing about clang slowdown.

Additionally,

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

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?

Ranges is spotty on clang and source_location is inconsistent between compilers, off the top of my head.

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.

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).

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

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.

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/

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.

Interesting read. It seems to me here that they're trying to shoehorn ranges into coroutines though - yes it technically works, but it's not pretty or performant.

If you have genuine data transformation tasks then I think ranges make a lot of sense. The kind of things that would be a 1-liner in Unix command line:

  cat foo.txt | grep "bar" | cut -d "," -f 3 | sort | unique | wc -l

This can be expressed really nicely with ranges in a way that wasn't possible, or at least readable, before. If you want to use ranges to reimplement coroutines then of course it will be slow and ugly.

As usual with new features, they shouldn't be used everywhere, even if they could. I do agree with the complaints on the massive size though - I feel it could be implemented quite simply if they only wanted 80% of the features.

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

I don't know what motivate you to keep repeating this narrative, Clang currently have good support of C++23 while MSVC have none[1], if your emphasis is on the standard library side, Clang is the only one that is compatible to all three major implementations and do use libstdc++ and MS STL on their respective "main" platforms.

Also, why isn't Microsoft in the "profit from Clang" list? Is Clang-CL not shipped in Visual Studio Installer? Did they find a way to compile Edge with VC++?

https://en.cppreference.com/w/cpp/compiler_support/23

Good to mention Microsoft is also depending on Clang for a lot of things (Microsoft is also quietly pushing devs to use Clang-Cl, as MSVC has really showed its age and is still notorious for bad error messages and subpar compiler optimizations…)

Some console vendors are also depending on it as well (Sony, Nintendo). Clang really is the most important C++ project of all time, because it’s the only compiler that’s truly cross-platform (Windows, Mac, Linux, iOS, Android, game consoles, etc…) And recent failures in it catching up with C++20 should be very alarming.

Where? MSVC is not going anywhere and has been partially rewritten.

> Microsoft is also quietly pushing devs to use Clang-Cl

Source?

Have you tried using ranges with latest clang? That's a pretty central part of C++20 and it doesn't work.

Have you tried converting iterations to SIMD and using vector extension to target x86, ARM, Webassembly and compile for Linux/Windows/MacOS with a simple piece of code? It's a pretty significant speed up and it only work with Clang.

What does that have to do with standards support?

None of that is part of ISO C++ compliance.

How is ISO C++ compliance relevant to actual development?

For many places it is quite relevant when choosing official compiler toolchains.

By the way, nice way of creating a throwaway account for the anti-ISO posts all over the place.

> Ranges [are] pretty central part of C++20 Just shows how distant the committee is from the developers.

I am not the only one, this is a common discussion point on C++ communities.

Clang first should spend it's resources catching up with C++20, instead of spending them on C++23. The standard is yet to be fully finished.

Who exactly cares about C++20? Most (mis)features of the “standard” won’t be used for years anyway, until the codegen stabilizes and performance impact will be known. Most of people in these communities never got a dollar for a line of C++, and people who did rarely express their opinion (but you can still find it online if you try)

It seems pretty obvious to me that you never lived through the bad old days when compilers all did whatever they wanted.

Tell me again how much you care about C++20 when a library with a feature you want uses it but your toolchain doesn't support it.

The ABI vote was C++ being effectively assassinated with a tombstone on top. What a horrible decision to effectively end a powerful and long-standing programming language. Words cannot convey how angry I am that a self-obsessed committee killed the language with a decision of the highest, absolute idiocy.