[nickysielicki]

The forever backwards compatible promise of C++ was a tremendous design mistake that has resulted in mindshare death as of 2026. It might suck to have to modify your code to continue to get it to work, but it’s the right long term approach.

[wolvesechoes]

> that has resulted in mindshare death as of 2026

I could make a bet that as of 2026 still more C++ projects are being started than Rust + Zig combined.

World is much more vast than ShowHN and GitHub would indicate.

[mcherm]

Being started? I would take that bet.

[pjmlp]

It suffices to use the games industry, HFT and HPC as domains.

[Ygg2]

Pretty sure even games moved to C#.

[fouronnes3]

Mindshare death is a very large overstatement given the massive amount of legacy C++ out there that will be maintained by poor souls for year to come. But you are right, there used to be a great language hiding within C++ if the committee ever dared to break backwards compat. But even if they did it now it would be too late and they'd just end up with a worse Rust or Zig.

[munificent]

The biggest problem with C++ is that while everyone agrees there is a great language hiding in it, everyone also has a remarkably different idea of what that great language actually is.

[tialaramex]

I don't agree there's a great language hiding in C++. My high level objections would be that the type system is garbage and the syntax is terrible, so you'd need a different type system and syntax and that's nothing close to C++ after the changes.

After many years of insisting that "dialects" of C++ are a terrible idea, despite the reality that most C++ users have a specific dialect they use - Bjarne Stroustrup has endorsed essentially the same thing but as "profiles" to address safety issues. So for people who think there is a "great language" in there perhaps in C++ 29 or C++ 32 you will be able to find out for yourselves that you're wrong.

[ChrisGreenHeur]

There are multiple great languages hiding within it

[pjmlp]

As proven a few times, it doesn't matter if committee decides to break something if compiler vendors aren't on board with what is being broken.

There is still this disconnection on how languages under ISO process work in the industry.

[jonstewart]

The C++ standards committee’s antiquated reliance on compiler “vendors” holds it back. They should adopt maintenance of clang and bless it as the reference compiler.

[pjmlp]

And you will be the one telling the losers that their compiler, operating systems and OS doesn't count?

By the way this applies to the C language so beloved on this corner as well.

As it does to COBOL, Fortran, Ada and JS (ECMA is not much different from ISO).

[the_duke]

Rust has managed just fine to remain mostly backwards compatible since 1.0 , while still allowing for evolution of the language through editions.

This puts much more work on the compiler development side, but it's a great boon for the ecosystem.

To be fair, zig is pre 1.0, but Zig is also already 8 years old. Rust turned 1.0 at ~ 5 years, I think.

[melodyogonna]

Rust started in 2006 and reached v1 in 2015, that's 9 years.

[kibwen]

Rust existed nearly entirely on paper until 2009, when Mozilla started funding researchers to work on it full-time. It wasn't announced in any sort of official capacity until 2010, and had no official numbered release until 2012. It was less than three and a half years between 0.1 and 1.0, and in that time, hard as it is to believe, it underwent more overall change than Zig has.

[pjmlp]

There is a reason GCC, LLVM, CUDA, Metal, HPC,.. rely on C++ and will never rewrite to something else, including Zig.

[surajrmal]

Yes, inertia. If those projects started today, they would likely choose rust.

[pjmlp]

Why isn't rustc using Cranelift then?

[norman784]

I can think a few reasons:

- Cranelift applies less optimizations in exchange for faster compilation times, because it was developed to compile WASM (wasmtime), but turns out that is good enough for Rust debug builds.

- Cranelift does not support the wide range of platforms (AFAIK just X86_64 and some ARM targets)

[pjmlp]

So it isn't just a matter of "they would use Rust instead".

There is a whole ecosystem of contributions across the globe and the lingua franca used by those contributors.

[andriy_koval]

> There is a whole ecosystem of contributions across the globe and the lingua franca used by those contributors.

which is slowly changing with wider rust adaptation.

[nindalf]

Same reason Android and Chrome and git and Linux weren't written in Rust when they started. Rust didn't exist. All of these projects integrate Rust now, after being single language projects for the longest time.

It's notable that the projects you mentioned mostly don't need to deal with adversarial user input, while the projects I mentioned do. That's one area that Rust shines in.

[pjmlp]

Rust presence in Android is minimal, and not officially supported for userspace.

Android team is quite clear that Java, Kotlin, C and C++ are the official languages for app developers.

Chrome even has less Rust than Firefox.

Linux has some baby adoption, and it isn't without drama, even with Microsoft and Google pushing for it.

[nindalf]

Rust will never be in Android user space, because it's not competing with Kotlin. Kotlin is already excellent there. Rust will replace the parts of Android written in C++ gradually. That was always the plan. It feels weird and cope-y to move the goalposts to say it's not a big deal unless Rust also replaces Kotlin.

Chrome only needs to replace the parts of their codebase that handle untrusted input with Rust to get substantial benefits. Like codec parsers. They don't need to rewrite everything, just the parts that need rewriting. The parts that are impossible to get right in C++, to the point where Chrome spins up separate processes to run that code.

Rust is the future for Android, and it will become an important of Chrome and Linux and git (starting 3.0). That's just the way it is.

[flohofwoe]

Looking at LLVM build times I seriously believe that C would have been the better choice :/ (it wouldn't be a problem if LLVM wouldn't be the base for so many other projects)

Same for the Metal shading language. C++ adds exactly nothing useful to a shading language over a C dialect that's extended with vector and matrix math types (at least they didn't pick ObjC or Swift though).

[pjmlp]

CUDA, SYSCL, HLSL evolution roadmap, and Khronos future for Vulkan beg to differ with your opinion.

[flohofwoe]

> HLSL evolution roadmap

...that's just because of the traditional-game-dev Stockholm syndrome towards C++ (but not too much C++ please!).

> Khronos future for Vulkan

As far as I'm aware Khronos is not planning to move the Vulkan API to C++ - and the 'modern C++' sample code which adds a C++ RAII wrapper on top of the Vulkan C API does more harm than good (especially since lifetime management for Vulkan object is a bit more involved than just adding a class wrapper with a destructor).

[pjmlp]

See the talks around Vulkan ecosystem, and GPU shading languages from February.

There is more than one sample using C++, now they make use of C++20, including modules if desired.

[flohofwoe]

> now they make use of C++20, including modules if desired.

It's in line with many other shitty design decisions coming out of Khronos, so I'm not even surprised ;)

IMHO it's a pretty big problem when the spec is on an entirely different abstraction level than the sample code (those new samples also move significant code into 'helper classes', which means all the interesting stuff is hidden away).

[whobre]

The forever backwards compatible promise of C++ is pretty much the main reason anyone is using C++.

[quotemstr]

Hilariously, they broke this compatibility. std::auto_ptr was an abomination, but removing it from the language was needless and undermined the long term stability that differentiates C++ from upstarts.

[ChrisGreenHeur]

those that used it were rightly punished by the removal