[Panzerschrek]

In case of such projects like LLVM C++ usage can be tolerated. But for new code or smaller codebases a better alternative should be considered.

Also Fil-C can't be used for LLVM anyway, since performance and memory consumption overhead is way too much. Nobody wants clang/rustc working 4x slower and consuming 2x more memory.

[pjmlp]

Yeah, unfortunately there are plenty of such projects, without alternatives.

GCC, GNOME, KDE, Linux kernel, BSD variants, CUDA, RocM, OpenCL Vulkan, DirectX, Metal, GNM(X), OpenMP, OpenACC, NVN,....

Hence why somehow fixing C and C++ is also quite relevant for the upcoming decades, assuming humans still matter on the planet.

Now it is going to be ARM MTE, SPARC ADI, CHERI, Fil-C, or WG14 and WG21 actually getting their act together, remains to be seen, as it is subject to governments and industry pressure, and we not destroying civilisation.

[Panzerschrek]

> GCC

Isn't needed if we rewriting anything in Rust anyway.

> GNOME, KDE

They aren't that huge. Huge is the overall codebase of applications using them. It's relatively easy to create a native Rust GUI framework and rewrite applications needed such a framework one by one.

> Linux kernel

It's a good opportunity to rewrite it. Not only because modern languages like Rust are better than C, but because such a rewrite allows getting rid of old stuff present only for historical reasons.

> BSD variants

Aren't needed if we writing a new kernel from scratch.

> CUDA, OpenCL

Not a huge problem. There are dozens of GPU-related languages. Adding one more isn't that problematic.

> Vulkan, DirectX, Metal

They are language-agnostic (but still unsafe). One can create an implementation in something other than C.

[pjmlp]

The fallacy starts that Rust depends on GCC and LLVM, and someone will keep adding code to them.

Likewise with all the industry standards based on C and C++.

Looking forward to see how COSMIC ever manages to gain adoption beyond System 76 computers.