4 ms·

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

by pjmlp 8mo ago

surajrmal 8mo ago
Yes, inertia. If those projects started today, they would likely choose rust.
- pjmlp 8mo ago
  Why isn't rustc using Cranelift then?
  - norman784 8mo ago
    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 8mo ago
      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 8mo ago
        > 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.
        pjmlp 8mo ago
        Where are the LLVM pull requests adding Rust code?
        andriy_koval 8mo ago
        I am not expert in compilers, but in databases space there are multiple prominent projects which gain traction, create ecosystem and making Rust strong contender against C++ dominance.
  - nindalf 8mo ago
    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 8mo ago
      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 8mo ago
        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 8mo ago
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 8mo ago
  CUDA, SYSCL, HLSL evolution roadmap, and Khronos future for Vulkan beg to differ with your opinion.
  - flohofwoe 8mo ago
    > 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 8mo ago
      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 8mo ago
        > 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).

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

by pjmlp 8mo ago

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

surajrmal 8mo ago

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

pjmlp 8mo ago
Why isn't rustc using Cranelift then?
- norman784 8mo ago
  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 8mo ago
    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 8mo ago
      > 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.
      - pjmlp 8mo ago
        Where are the LLVM pull requests adding Rust code?
        andriy_koval 8mo ago
        I am not expert in compilers, but in databases space there are multiple prominent projects which gain traction, create ecosystem and making Rust strong contender against C++ dominance.
- nindalf 8mo ago
  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 8mo ago
    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 8mo ago
      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 8mo ago

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 8mo ago
CUDA, SYSCL, HLSL evolution roadmap, and Khronos future for Vulkan beg to differ with your opinion.
- flohofwoe 8mo ago
  > 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 8mo ago
    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 8mo ago
      > 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).