Hacker News Reader

Comment by qalmakka | Hacker News Reader

It's nice to see how GCC developers have worked hard in recent years to keep their compiler up to the most current standard. It's sad the same can't be said about Clang which, despite the fact LLVM has basically EVERYONE behind, still struggles to implement the entirety of C++20 after more than 2 years. And this is without taking libcxx into account, which has been also struggling despite the fact is way newer and cleaner than libstdc++.

It's basically as if Google and Apple don't really give a damn about keeping up with C++ standards, so they always get pushed on the back burner.

View on HN

C++20 is coming into a world with much more competition than C++11 did (the last comparably sized standard). When C++11 came out Rust, Go, Zig, Swift were all either in their infancy or didn’t exist yet. There was a huge desire for C++ to improve and improve fast given its centrality.

That world is not today’s world. Projects that would have been written in C++ in the past are often written in a different language now. This leaves C++ being useful mostly for legacy codebases, of which adopting new standards quickly is not so important.

If you are building high-performance, high-scale systems software (e.g. database engines), modern C++ is by far the preferred choice for new software projects and next generation systems. The notion of C++ being "useful mostly for legacy codebases" is not in evidence. The reality, for better or worse, is that there is no satisfactory replacement currently for C++ for important classes of software even if starting from a completely blank slate. I like some of those other languages, they just can't do the job in a reasonable way.

The reason modern C++ is still the preferred language for some types of software is that it is significantly more expressive in critical ways, which has a substantial impact on software robustness, maintainability, and performance. You could use those other languages, but it would produce a substantially worse product and/or codebase.

To put it another way, there is often no way to translate an existing elegant modern C++ codebase into those other languages without major compromises to either the codebase or performance. And for the kinds of applications where C++ is preferred, those compromises are largely unacceptable. Maybe some of those other languages will approach the practical expressiveness of modern C++ for this kind of software eventually, but not anytime in the near future.

This is not true. Nor is the post you're replying to, for what it's worth.

Rust and C++ are roughly equally expressive for high-performance, high-scale software. The reasons to use one or the other for new code have little to do with whether each language can do the job; clearly, both languages can. Rather, what dominates are factors like whether your build/deployment system is set up to handle one language or another, what your engineers are experienced in, whether you care about memory safety, etc.

Source: I'm one of the maintainers of Rust at a large organization you have heard of that very much cares about high-performance, high-scale systems software.

True. But.

The learning curve of Rust should not be underestimated, IMHO. I do not know except by my own experience and "gossip", and would be interested in hearing from a bigger shop that has to deal with it.

Rust can make an experienced developer feel utterly clueless. The borrow checker is a very harsh mistress. Moving from C++ to Rust for a computer programmer with many years of experience in C++ must be a frustrating and humbling experience. The simplest things become so hard.

I love Rust, but I do not use it professionally (I would love to). I can clearly see that it is a step closer to what we have been waiting for, it may even be the destination. But I can imagine the pain of moving a programmer from 20 years of C++ into Rust. Becoming a novice again

When I started learning Rust after ~25 years of C++, I was quite productive after a couple of months. If C++ teaches you something, it's that you can be productive with a language without being fully familiar with it. After all, 25 years doesn't seem to be enough for learning C++.

The borrow checker is not such a big deal. You should have learned the basics in undergraduate CS in the context of concurrency and/or databases. If you have done shared data parallelism in modern C++ (let's say with OpenMP), you are probably used to similar reasoning.

Borrow checking and lifetimes do make some design patterns difficult to use, which is a reason you should not use such patterns in Rust. But there are almost always ways of achieving the same goals with idiomatic Rust. It's a bit like having to unlearn gotos when transitioning from BASIC to more serious languages and their fancy "structured programming".

> When I started learning Rust after ~25 years of C++, I was quite productive after a couple of months.

Stating that it takes 25 years of experience in order to become productive with Rust doesn't really sound like a positive note.

Keep in mind that your typical user of high-level programming languages already has a very hard time grasping the basic mechanics of C++, and Rust's memory management paradigm alone is renowned for having quite a steep learning curve when compared to C++.

FWIW I was productive in Rust after a couple of months with a background ~5-10 years of experience in primarily JavaScript and PHP (no prior low level experience). Rust does have a steep learning curve, but I'd argue that it's shallower than that of C++ (which puts shoots up in complexity as soon as you wish to include a dependency).

This is especially true if you are actually intending to write production code. There's no way I'd have comfortable releasing my C++ code to production after only 2 months, but my Rust code was completely solid despite my lack of experience in the language.

> The learning curve of Rust should not be underestimated, IMHO.

Not sure how this is relevant in a conversation about C++, for which the notion of a learning curve is even hard to apply given that practically no one manages to write code that can be trusted to be free of basic defects in the language.

> Rust can make an experienced developer feel utterly clueless. The borrow checker is a very harsh mistress.

And rightly so. Rust is only unique in that you get the hangover before deploying the code in production. It's puzzling that some might see this as a drawback of the language.

I am commenting on the difficulties faced moving a computer programmer from C++ to Rust.

Any conversation about C++ has to consider the costs of abandoning the ship

Sky vs Snowboard, basically.

Sky day one is very easy, yet it takes years to master.

Snowboard day one is going to be mostly about falling, unless you want into xgames, it is much easier to master afterwards.

It depends on which experience one wants to have.

> Moving from C++ to Rust for a computer programmer with many years of experience in C++ must be a frustrating and humbling experience

My experience was the exact opposite.

To write correct and safe C++ code you need to be tracking things like lifetimes and ownerships anyway (even in modern C++). Rust allows you offload all of that cognitive overhead to the compiler, which greatly simplifies things.

There was a short period of time needed to get used to the borrow checker, but coming from C++ I understood why it was complaining about these things so the errors didn't come across as opaque or confusing.

Unless one tries to write GUI software, then it is Rc<RefCell<>> everywhere.

Honestly, if moving from C++ to Rust is frustrating for a developer not because of missing but because of borrowing, lifetimes and move semantics, it probably means that they were writing very "old style" C++. I write my modern C++ following Rust semantics as much as I can, and I think it's the right way to currently use C++ without incurring in slews of preventable issues.

Rust IS modern C++ in a stricter package IMHO. C++ still has some extra magic (constexpr, SFINAE) that in Rust is yet not doable or requires procedural macros, but the core language is definitely designed around concepts such as by-value and move semantics which are crucial concepts to use when writing modern C++ applications.

Rust const is the equivalent to constexpr in C++. As for other compile-time "magic", Rust macros are a much more principled approach to that feature set.

Rust const is still way, WAY more limited than constexpr in C++. You can't do basically anything in const Rust yet, while C++'s constexpr even supports memory allocations.

Learning curve is a temporary problem because Rust is pretty new and a lot of people need to begin ramping up at the same time. Hopefully we’ll get to amortize that across many years of projects, like C++.

> clearly, both languages can.

C++ is not memory safe, which is table stakes these days for any truly "high scale" software. Which is why most large-scale software projects have been written in Java, a memory-safe language, since the late 1990s (taking over from the previously common use of C++). And no, even the C++ Core Guidelines and "modern" coding style do not fully address this issue; they're way too clunky, whether or not legacy code is involved. Rust, even more so than Java in the mid-1990s, is uniquely positioned in offering better performance and safety than C++ and a lower complexity in development.

All big GPU and HPC related companies have ISO C++ people on their payroll, so I doubt they will care to add something else.

And NVidia rather uses Ada/SPARK instead of Rust for high integrity computing.

In regards to Java, while I do agree, there is still enough JNI being used there, hence why Project Panama, to improve such workflows where C++ is part of the story.

Increasingly feeling that Rust is like Elm: a language with novel ideas, teaching valuable lessons (a vocabulary for teaching and checking thread safety, documenting exclusive vs. shared mutability in the type system, arguably a vocabulary for teaching and checking memory safety, though that comes at a steep cost), yet so stubborn the community treats its values (avoiding shared mutability) as moral judgments of code, and the language and deliberately obstructs writing code outside of approved patterns (single ownership tree, exclusive mutability). struct{Cell...}& doesn't need to be harder to use than C++ struct{T...}*, but Rust keeps it difficult because the community views it as bad code design and wants to keep it hard. And *mut T lacks RAII unlike C++'s unique_ptr, and requires unsafe blocks in every dereference. As a result, people turn to unsound patterns like https://github.com/kimundi/owning-ref-rs, https://github.com/mcoblenz/Bronze/, and https://github.com/emu-rs/snes-apu/blob/master/src/smp.rs#L5... (and https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a... raises questions about what exactly is sound or will be redefined as sound).

It's a good language to learn. I hesitate to consider it a replacement for asm/C/C++. Writing rust is hoping that the code you're porting to rust can adapt well to the restrictions, and if not, searching for esoteric and needlessly unsafe/verbose workarounds.

Not to mention that to embark right now on a fancy-language-of-the-week codebase could be a career ending (and/or even company ending) mistake. I mean, I still work regularly on C++ codebases that are >30 years old (no STL!) and are supported and extended and even switch companies from time to time. God knows how many "languages of the future" we've had in these 30 years.

There are literally millions of C++ developers out there. And that number is growing. There are new C++ projects started every single day. It will take a very long time for any other language to compete with C++. I agree that most biz software that doesn’t require high performance should be written in something else. But there are many application areas where C++ still completely dominates. Look at commercial games for example, browsers, JIT compilers etc. Yes Rust might be able to do a good job in those domains but it is hard to compare with the C++ momentum.

I would be very interested in hearing a few concrete examples!

I think a large reason of why Clang lags behind in C++ standards is that Google and Apple don't really use modern C++ at all. Google has strict guidelines that prevent people to use half of the language (look at exceptions, for instance, without which most of the STL is crippled) and they use Abseil anyway, so they don't really care about the STL in the first place.

Apple on the other hand mostly uses C++ in very restricted scopes such as DeviceKit which are very limited and can't safely use the entire language anyway. Xcode-shipped Clang and libcxx are often pretty old, too. They don't really need C++ that much above what C++03 already had, so it's clearly an afterthought for them.

C++ is great to have as much control over memory and performance as possible, while still providing more convenience than C. The C++ Standard Library and exceptions don't improve this control generally.

Possibly an unpopular opinion, but personally I wish the C++ Standard Library was kept separate from the C++ language and have the C++ committee focus on the language features instead.

> Possibly an unpopular opinion, but personally I wish the C++ Standard Library was kept separate from the C++ language and have the C++ committee focus on the language features instead.

This is not an unpopular opinion.

My impression is that this is an opinion about the stdlib that many programmers concerned with performance share.

Chromium finally switched to C++17 this year. The switch to C++20 will happen much sooner given that PNaCL support will be finally removed this summer.

That alone doesn't explain why clang conformance was very good till c++17 and then suddenly fell behind. The major clang contributors decided to focus their attention elsewhere,

One guess is because they didn't get what they wanted within the committee.

Google basically withdraw from clang after they lost the ABI vote, and Intel is now taking care of what used to be mostly Google stuff.

If I remember correctly some discussions on /r/cpp.

As for Apple, OP is right, Metal Shaders are based on C++14 dialect, IOKit/DriverKit use an Embedded C++ dialect, and for everything else there is Objective-C/Swift, and they only need enough C++ to use LLVM to develop them.

The permanent-ABI compatibility decision was effectively the death-knell for C++. Can't improve the standard library performance, making it effectively useless for the real world. Can't correct mistakes - the language and library warts grow and grow as the years pass by, making it impossible for beginners to pick up and learn the language.

Frankly, Google should fork C++ and create a new language without the warts and a new standard library.

> Frankly, Google should fork C++ and create a new language without the warts and a new standard library.

That's how we got golang.

Golang isn't really a C++ replacement, the performance metrics just aren't comparable. It's more of a Python replacement, for those applications where it would be just too slow, forcing you to write C or C++ because that's still the #1 way to accelerate your Python. Sure there are compilers such as Cython or Nuitka, but they just do not suffice when you _really_ need to speed up your code.

In C++‘s heyday there were things such as OKWS[0] web application server. Yes externally C++ was no so popular in such situations, but at Google they had/have many such C++ services and that was the motivation behind Go - a safe language to build mostly-IO-bound-but-a-little-bit-CPU-bound services.

Another example of this shift would be that Bitcoin’s reference impl (2009) is written in C++, whereas Ethereum’s reference impl (2015) is written in Go.

[0] https://okws.org/

They still mostly do, that is where Abseil is used.

Go has more mindshare outside Google than on Google's critical infrastructure.

The golang genesis story is that pike, thompson and company were so dissatisfied after a ISO C++ meeting that they just decided to make a C++ replacement that checked all the boxes they wanted. They got somethings wrong. They got somethings right. But, overall it was their NIH reaction to what would become "Modern C++".

> That's how we got golang.

I meant a language by removing all the warts, not removing all the features. :)

Seriously, if Go offered manual/arena memory management and real generic programming - stuff like template template parameters, STL algorithms, auto-vectorization, etc - it could effectively replace C++.

Was google pushing for breaking the ABI?

- a WG paper by a google employee regarding breaking the C++ ABI: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p186...

- A post about a C++ ABI break being voted against: https://cor3ntin.github.io/posts/abi/

I would not be surprised if google (or others in favor of breaking the ABI for the c++ standard library) would refocus on their alternate non-std std-replacement-ish library implementations (like abseil) instead given the lack of willingness to fix things in std proper from the committee.

Yeah, I've seen both of those before, but was unsure if it was just the position of a single Google employee or the position of google as a whole, as you made it sound like Google the company had actually taken such a stand

I still see a lot of google contributions to llvm recently. For example the mem* functions.

Yes. For example (there are a lot more) Vittorio's Epochs proposal P1881R1:

https://www.youtube.com/watch?v=PFdKFoQxRqM

Now, one of the things which you may have noticed really annoys C++ proponents here on HN is when people say "What Rust does..." and well, maybe Vittorio should not have done that in his talk. But the reason he's saying it is that although Rust has very few new ideas it popularises lots of existing ideas from PL theory that were not seen in the kind of languages C++ developers had experience with before.

A few slides in, Vittorio explains that he's not offering language fragmentation or dialects, an ABI break, or yet more stuff every programmer needs to learn. Nevertheless, criticisms of Epochs generally say that this is language fragmentation, it introduces dialects, it's an ABI break, and every programmer will have to learn all this extra stuff so it's hopeless...

Apple’s public/external-facing uses of C++ are restricted and odd (MSL, IOKit), but internally it seems pretty common in the OSes. Dyld, font rendering, and lower-level event handling (the remains of Carbon/HIToolbox) are all things I’ve seen in stack traces.

And of course there’s also WebKit and LLVM.

WebKit standard requires C++17, while LLVM still on C++14, so no pressure from Apple side to move forward,

https://webkit.org/languages-staged-08192020

https://llvm.org/docs/CodingStandards.html#c-standard-versio...

The Google style guide is public: https://google.github.io/styleguide/cppguide.html

I think reading it would convince you that the statement Google doesn't use modern C++ at all is false. It talks about modern features like CTAD.

I think you’re blissfully unaware of just how many developers are still being trained in C/C++ this day. I agree with you that in the long run, Rust has everything going for it to replace C++, but these types of things happen in a span of several decades, not years.

I think Rust has the potential to coexist with C++. As for replacement - here is my shallow outlook (I only care about how new tech affects my own business).

The safety offered by Rust is not a thing to ignore. However modern C++ and the tooling has made enough progress in the area. It is extremely rare for me to allocate explicitly and in the couple cases where I do I always write deallocator first. It is ingrained in my nature along with some other related habits. Invalid memory access is also less likely with modern constructs. Along with memory sanitizers and practical experience with my own products I feel that Rust memory safety at this point does not offer much from my practical point of view.

I value very much time spent on compiling / building. From few experiments I made Rust is not any faster in this department. Rather the opposite.

As for C++ being a monster impossible to comprehend in its entirety. Agree and do not give a flying fuck. I am not there to explore language to its utmost depths. It is just a tool for me and nothing more. I do not get hung up on tools. As long as the tool lets me do my job with the reasonable ease (and subset of modern C++ definitely does) the rest does not matter. I do not feel inferior for not willing to spend the rest of my life trying to become Alexandrescu.

I write C++ for a living and I admit I do like to push it to its limits (SFINAE, constexpr/type traits shenanigans, the more the merrier), but it must be acknowledged that it tends to become too much akin to magic the more you push the envelope. Stuff like having 10 kinds of initialization and name resolution being incredibly complex and convoluted is a bit more confusing than what should be considered acceptable in a programming language.

Still I love the utter madness that there's behind C++, and the fact you can basically do everything you set yourself to, no matter how crazy and weird it is, as long as you accept to put up with the madness. You can emulate a good 90% of what Rust does with traits if you really want to.

>"I write C++ for a living and I admit I do like to push it to its limits (SFINAE, constexpr/type traits shenanigans, the more the merrier),"

I suspect maybe because you love programming as a process. I write C++ (other languages as well) for living but I am my own company, so my primary concern is to deliver more while spending less. The language on it's own means zilch to me as long as it adequate.

Well, by pushing C++ you can enforce a lot of constraints at compile time, just like you do with Rust. For instance, by extensively using concepts or SFINAE (enable_if and friends) you can make type safe code that works well and (almost) never breaks. I rarely if ever need to fix runtime issues with my C++ (or Rust), because it almost always works at the first attempt. That's due to all the "fighting against the compiler" you need to do beforehand in order to get the code to compile in the first place, but it's generally worth the effort IMHO.

> From few experiments I made Rust is not any faster in this department. Rather the opposite.

Rust uses more generics in its idiomatic code than C++. If you're careful to split out your generic type impls to avoid excess code monomorphization, compile times can be manageable. Macro use brings similar concerns, but it's probably rarer unless you're relying on popular crates that need it such as serde.

You sound like you work in a wonderful environment.

"where I do I always write deallocator first" that sounds like good practise.

But software development is driven by marketers. Having the time to properly add in the features required for safety is important.

From a marketing perspective it is a waste of money. When a change needs to be made, some feature that once lived under the hood and needs to be "surfaced", using some pointer into a structure in an unsafe manner will take five minutes, properly assembling the structures, rearranging the code etcetera takes two days - those days come off the profit of the company (from the marketing perspective)

As a computer programmer it is fabulous to have the resources to do it safely. It is not the conditions that a lot of us (most of us?) work in.

User visible features. All that matters. Memory safety? What is that!

>"You sound like you work in a wonderful environment."

For the last 20+ years I sit in the basement of my house where I design and build my products. Some for my company. Some for clients. Every once in a while I would get out and meet with perspective clients / subcontractors or for some meeting with existing ones. But it gets increasingly more rare and everything is done using Zoom/Skype/Remote Deployments/Couriers. The only reason I get out is mostly for fun - meeting friends, cycling, swimming etc.

Time will come for the software version of health inspections and construction work safety visits, and then business will have to care.

One example, https://iclg.com/practice-areas/cybersecurity-laws-and-regul...

Sure, but the difficulty is being able to understand and modify other people code which can be all over the place.

I/my company personally did not ever encounter this particular issue so not a problem in my world. I understand it is still valid concern but I'd let the actual victims worry about it.

> C++20 is coming into a world with much more competition

I question whether those are actually competing in this same realm, for large organizations. Language adopotion is not just about the language, but also tooling, libraries, standard, etc which organizations have built up and rely on.

For example, at Apple C++ is used more internally than is exposed in public APIS. (I can't imagine the swift compilers performance scaling up to large code bases at this point.)

Can you speculate on other reasons, besides competition for the slower rate of adoption? Is it not as helpful as previous standards? Is it more difficult to implement?

> (I can't imagine the swift compilers performance scaling up to large code bases at this point.)

It struggles on medium sized code bases.

And Xcode becomes flaky too, on medium code bases.

Works absolutely brilliantly on the small examples that are used to market it.

I have been using it for two years, and fundamental bugs in the system have not been fixed in that time. (The code inspection tools in the debugger are close to useless)

The last time I updated it my computer spent over three hours with the installer running at 100%. What on Earth was it doing? Mining bitcoin?

A whole lot of things are clearly going very wrong behind the scenes

I have had the same experience. This is one factor that leads me to believe Apple is mostly using C++ internally.

Nah, C++ is mostly frowned upon inside Apple. The open source projects (clang and Darwin) contain most of the C++ in the OS. Objective-C is the ubiquitous implementation language in Apple's macOS/iOS/tvOS/watchOS userspace code. It will eventually be superseded by Swift as the Swift runtime improves. All userspace projects and some kernel projects are built in Xcode, and most developers internally use Xcode to edit the sources.

The particular frameworks I use which often have a lot of C++ stack traces must be outliers. I appreciate the info.

C++0x is one of the reasons Go was created. C++ was getting far too complex:

"For me, the reason I was enthusiastic about Go was just about the same time we were starting on Go, I read (or tried to read) the C++0x proposed standard. And that was the convincer for me." - Ken Thompson

17:45 mark here: https://www.youtube.com/watch?v=sln-gJaURzk

And then most C++ developers didn't care, as Go isn't was they were looking for,

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

While I agree with the underlying point, I doubt that the statement “This leaves C++ being useful mostly for legacy codebases” is true. I see new projects started in C++ all the time in my industry ( automotive video essentially ). In the Open Source world, I see it a lot too. SerenityOS comes to mind. You can hardly call that a legacy code base. In Microsoft land, C++ still seems like the go-to language everywhere outside of .NET with new APIs still being created. There is some interest in Rust but it still seems early and it is not at all obvious that Rust will push C++ aside ( though I would love it to ).

Microsoft tried to convince all C++ developers to switch to C# and completely and utterly failed. It was amusing to see how quickly they switched back to supporting C++ after years of pretending that C++ had no future.

> This leaves C++ being useful mostly for legacy codebases

I'm pretty sure people said that about C++ when Java became popular.

Rust seems like a fine language, Zig sounds interesting, and Go and Swift I'm not familiar with. But I don't really buy your argument.

Java could never fill all of the spaces that C++ is used for because of the JVM and garbage collection. Rust certainly could, and should, in my opinion as a long time C++ developer.

> Rust certainly could, and should, in my opinion as a long time C++ developer.

I'm not a Rust dev, but I am curious how things like epoll would work in Rust. In C (or C++) I place a pointer to a structure in the epoll `event.data.ptr` field. When an event is returned by epoll_wait() all the caller has to do is run a function on that instance in `event.data.ptr`.

It seems to me, that even with `unsafe`, you're not going to be able to do this in Rust unless all the code is unsafe. You cannot transfer ownership of the instance to `event.data.ptr`, can you mark the pointer or event structure itself as `unsafe`?

I don't see why that would require making all code unsafe? You might want to take a look at mio's source code [1], which uses epoll on Linux [2], and which encapsulates epoll in a safe way.

[1] https://github.com/tokio-rs/mio

[2] https://tokio-rs.github.io/mio/doc/mio/struct.Poll.html#impl...

After looking at the examples, it looks to me that it uses a hashmap (with a generated token to identify the connection structure).

It gets around putting a ptr into the event structure (that epoll will then return) by putting a tokenID into it instead (that epoll returns), that the connection_handler function will then use to retrieve the connection instance that it needs to work with.

IOW, in `C` I'd create an instance of a `struct connection_t` and `epoll_wait()` returns the pointer to the instance.

This way, it appears that an ID is placed into the event structure and the { ID : corresponding instance } tuple is stored in a hashmap. `epoll_wait()` returns the ID, the caller uses that ID to get an instance to work with.

Although, I could be wrong - I'm not a Rust dev.

> you're not going to be able to do this in Rust unless all the code is unsafe.

Why wouldn't std::mem::transmute (plus a little bit of hand-managed lifetime emulation) work here? It is unsafe, but doesn't require the unsafe modifier to be present on code beyond where the transmute happens. Unless by "all the code is unsafe" you mean related code is conceptually at risk of unsafety due to bugs caused by erroneous reinterpret-casts, then I think transmute should work here.

> Rust certainly could ... in my opinion as a long time C++ developer.

Can you link to an explanation of, or an argument for, that claim?

Yep, and some projects failed hard on that regard, because the JIT infrastructure still wasn't good enough.

I was part of one, whose goal was to replace a CORBA infrastructure based in HP-UX, with Websphere running on Solaris/Linux.

None of those languages have the ecosystems that make C++ still relevant today.

>> When C++11 came out Rust, Go, Zig, Swift were all either in their infancy or didn’t exist yet

I don't see Go as a natural C++ competitor. Go primarily competes with Java and C#.

I'm still waiting for Clang to support capturing structured bindings in lambdas, which was partly legal in C++17 and fully legal in C++20.

Same here: this one will be a game changer for me.

For reference, here are the C++ support pages for GCC and Clang:

https://gcc.gnu.org/projects/cxx-status.html

https://clang.llvm.org/cxx_status.html

Thanks license, that is why.

Most of those people behind, care about the LLVM infrastructure and not so much about upstreaming clang stuff or improving ISO C++ compliance.

I don't see how the license is relevant here. It's not like companies have already implemented full C++20 support in their local forks and just haven't bothered upstreaming it.

But yes, a lot of LLVM users don't care about C++ standard compliance at all, for example because they don't use C++.

Not C++20 per se, but certainly language features.

Reply on news.ycombinator.com