I wrote lots of C++ before learning Rust, and I enjoyed it. Since learning Rust, I write no more C++. I found no place in which C++ is a better fit than Rust, and so it's my "new C++".

For example, high performance servers (voltlane.net), programming languages (https://github.com/HF-Foundation, https://github.com/lionkor/mcl-rs, and one private one), webservers (beampaint.com) and lots of other domains.

Rust is close to C++ in that it is a systems language that allows a reasonable level of zero-cost abstractions.

> found no place in which C++ is a better fit than Rust, and so it's my "new C++".

Writing the compiler toolchains that Rust depends on, industry standards like CUDA, SYSCL, Metal, Unreal or the VFX Reference Platform.

There are places a language could be a better fit, but which haven't adopted it. E.g. most languages over typescript on the backend, most systems programming languages over Java for games.

The fallacy is to discuss programming languages in isolation without taking the whole ecosystem into consideration.

Rust uses LLVM because it's pretty great, not because you couldn't implement LLVM in Rust.

Maybe cranelift will eventually surpass LLVM, but there isn't currently much reason to push for that.

If anything, making cranelift an LLVM replacement would likely go counter to its stated goals of being a simple and fast code generator.

Thus Rust cannot really replace C++ when its reference toolchain depends on it.

If you define success for Rust as "everything is written in Rust", then Rust will never be successful. The project also doesn't pursue success in those terms, so it is like complaining about how bad a salmon is at climbing trees.

That is however how the Rust Evangelism Strike Force does it all the time, hence these kind of remarks I tend to do.

C++ is good for some things regardless of its warts due to ecosystem, and Rust is better in some other ones, like being much safer by default.

Both will have to coexist in decades to come, but we have this culture that doesn't accept matches that end in a draw, it is all about being in the right tribe.

I assert there is no reason to rewrite LLVM in Rust.

And I also assert that the speech that Rust is going to take over the C++, misses on that as long as Rust depends on LLVM for its existence.

Or ignoring that for the time being NVidia, Intel, AMD, XBox, PlayStation, Nintendo, CERN, Argonne National Laboratory and similar, hardly bother with Rust based software for what they do day to day.

They have employees on WG14, WG21, contribute to GCC/clang upstream, and so far have shown no interest in having Rust around on their SDKs or research papers.

> I assert there is no reason to rewrite LLVM in Rust.

Everybody agrees with that, though? Including the people writing rustc.

There's a space for a different thing that does codegen differently (e.g. Cranelift), but that's neither here nor there.

> And I also assert that the speech that Rust is going to take over the C++, misses on that as long as Rust depends on LLVM for its existence.

There's a huge difference between "Rust depends on LLVM because you couldn't write LLVM in Rust [so we still need C++]" and then "Rust depends on LLVM because LLVM is pretty good". The former is false, the latter is true. Rust is perfectly suited for writing LLVM's eventual replacement, but that's a massive undertaking with very little real value right now.

Rust is young and arguably incomplete for certain use cases, and it'll take a while to mature enough too meet all use cases of C++, but that will happen long before very large institutions are also able to migrate their very large C++ code bases and expertise. This is a multi-decade process.

> Rust is close to C++ in that it is a systems language that allows a reasonable level of zero-cost abstractions.

That's like saying php is close to haskell because they both have garbage collection.