Comment by pjmlp

2 days ago

Yeah, but who's going to rewrite LLVM in Rust, which rustc relies on?

Yes there is Cranelift, and?

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.

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

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

      1 reply →