12 ms·

If you're starting a new project and can afford it, please for the love of the children, use a different systems language. In so many ways Odin, Rust, Zig, what

If you're starting a new project and can afford it, please for the love of the children, use a different systems language. In so many ways Odin, Rust, Zig, whatever are better. There will be growing pains with respect to collective knowledge and performance, but they are surmountable. Context: I am a programmer and educator. I am so tired of informing people of these minutiae.

feverzsj 3mo ago
Only if you don't code for living.
deleted 3mo ago
[deleted]
jjmarr 3mo ago
Unfortunately I'm a GPU programmer. C++-based CUDA/HIP is still the standard regardless of how much people would rather use Rust to program GPUs.
- tadfisher 3mo ago
  Who is stopping you? Is it an employment concern?
  - t0mpr1c3 3mo ago
    This question strikes me as somewhat obtuse, but I will attempt an answer: NVIDIA and AMD. These are only two GPU manufacturers of any significance. (Intel is also a player, but not a major one.) They supply SDKs (drivers and libraries required for software development) for their products that support C and C++ and precious little else. There have been attempts to reverse engineer the toolchains in Rust but as I understand it they are not yet mature.
    - edoceo 3mo ago
      The Zig group claims that Zig can interop with C based libraries w/o too much work. It's one of the reasons I'm digging into it now. But I don't know anything about CUDA and have only done trivial Zig<=>C tests (like my Zig code working with libpng) so far. Are their claims BS? Is Zig just not mature enough? Something else?
      - t0mpr1c3 3mo ago
        I don't know really. My guess is that Zig cannot be considered mature until someone has written an application in it that contains a Lisp interpreter. I'm banking on Ghostty. Your move MH ;)
      - jjmarr 3mo ago
        The CUDA/HIP APIs are mostly C-like APIs but are really C++ language extensions. e.g. you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it. The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based. HIP is better because it's an open-source llvm backend/frontend but you'd still need to add GPU-specific support to zig/rust/whatever.
        zzyxy 3mo ago
        > you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it. It all boils down to calling CUDA runtime or driver APIs. Compiler just sprinkles fairly trivial amount of syntactic sugar, and under-the-hood glue code. One can launch GPU kernel from a pure C source file compiled with gcc. > The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based. nvcc is not the only option. Clang itself can compile most of existing CUDA code just fine, and the rest usually needs minimal porting. Also, nvcc is not based on clang. It may use it as the host compiler, but that's the extent of its involvement with clang. IIRC, their front-end used to be based on EDG. > HIP is better because it's an open-source llvm backend/frontend CUDA and HIP share most of the front-end code in clang, so CUDA compilation with clang shares the same benefits. What's missing is PTX to SASS assembler, which creates the actual GPU binary, and that part is proprietary to NVIDIA.
tsimionescu 3mo ago
Systems programming is very much about minutiae, to a great extent. And this particular detail will affect any systems language, one way or another. Every language has to decide if the calling convention is part of the function signature or not, and every systems language then has to decide whether it allows C functions with the same name as native functions or not. The C++ standard decided to allow this, which actual C++ compiler implementers decided to ignore for whatever reason, but that's just a bug, of which, again, you'll find many others if you actually do systems programming. I'll also note that "Odin, Rust, Zig" is a weird enumeration - neither Zig nor Odin are anywhere near being a realistic option for a new complete system. Odin is so obscure it doesn't even have a Wikipedia page. Zig is still pre-1.0 and often makes breaking changes to core libraries.
- jstimpfle 3mo ago
  To be fair, Odin _had_ a Wikipedia page and it has been removed because of... people with whatever interests. But I'm still agreeing with your general point. I use C/C++ because it seems to be the least friction option to me overall, and I don't want to deal with language but simply focus on my actual compute problem. (Given that, I spend an unreasonable amount of time in silly fights about language).
  - tsimionescu 3mo ago
    I've read about some drama with Odin's Wikipedia page - but I don't think that contradicts my point. If your language community can't even defend a Wikipedia page, you're an obscure language that people can't be expected to choose that easily. That doesn't automatically mean it's a bad language, but it does make it weird to recommend it in the same breath as Rust. It's like saying "choose a language like APL or C or Java" - one of these is not like the others.
- leecommamichael 3mo ago
  I'm talking about design flaws, not engineering details. I would appreciate if you would respond in spirit. I do think the list I gave is odd, and it is so because it's kind of a mashup of recent pop-culture things. I'm literally just appealing to people to attempt to use something designed with the benefit of 50 years of hindsight. Why am I being downvoted?
t0mpr1c3 3mo ago
Lindy's Law says C will be around longer than any of that lot. Although I wouldn't bet against Rust now that it's used for Linux drivers.
- bee_rider 3mo ago
  C will outlive all of us. C++… I don’t know it well. But I’ve heard there are a lot of different dialects, to the point where it is possible that two C++ programmers might be writing in essentially different languages. How “old” is the language, in that case?
  - AlotOfReading 3mo ago
    The dialects issue is why I avoid interviewing in C++, because inevitably it turns out the interviewer has some weird view of what "C++" is and doesn't realize it. Years ago I had an interview in "C++14" that required std::optional (C++17) as implemented by a C++14 compiler with only experimental, nonstandard support. In another case, an interviewer on the LLVM team vehemently disagreed with me that you could legally implement std::atomic types with mutexes, as I was going over a story about fixing issues in an awful stdlib that implemented them with mutexes. This kind of thing doesn't happen when I interview in other languages.
    - t0mpr1c3 3mo ago
      It seems like the history of programming languages since the 1980s has mostly been people trying to avoid C++. First languages with run-times and dynamic types, and more recently lower levels of abstraction (Go, Rust).
      - pjmlp 3mo ago
        I was there, and C++ was all over the place on Windows, OS/2, Mac OS, UNIX/CORBA. It was FOSS with its set of coding guidelines, that gave C a new wind. Languages with runtimes and dynamic types go all the way back to Lisp and Smalltalk.
wyattblue 3mo ago
Consider Nim too!
lallysingh 3mo ago
I've tried it, and no. Honestly C++ gets so many complaints partially because so many people use it. It deserves a lot of it. I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC's DMA/TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator? What's nice about C++ is that your fight isn't against the language and runtime. They don't care what your situation is. They'll work. You do have to assemble it, and other languages make some assemblies a lot easier to do. Yes Rust and its libraries are getting better. But so's C++.
- leecommamichael 3mo ago
  These are legitimate complaints, and I meant for "if you can afford it" to do a lot of lifting in my first comment.
- 112233 3mo ago
  On embedded, your fight totally is against language and runtime. Since you cannot gave conformant freestanding C++ without exceptions, rtti and most of STL, "using c++" on embedded always turns into "using gcc" or "using clang" — their mutually compatible, but completely standards non-conformant extensions that make writing for embedded reasonable to even attempt. At that point, is the language still c++? Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.

feverzsj 3mo ago

Only if you don't code for living.

deleted 3mo ago

[deleted]

jjmarr 3mo ago

Unfortunately I'm a GPU programmer. C++-based CUDA/HIP is still the standard regardless of how much people would rather use Rust to program GPUs.

tadfisher 3mo ago
Who is stopping you? Is it an employment concern?
- t0mpr1c3 3mo ago
  This question strikes me as somewhat obtuse, but I will attempt an answer: NVIDIA and AMD. These are only two GPU manufacturers of any significance. (Intel is also a player, but not a major one.) They supply SDKs (drivers and libraries required for software development) for their products that support C and C++ and precious little else. There have been attempts to reverse engineer the toolchains in Rust but as I understand it they are not yet mature.
  - edoceo 3mo ago
    The Zig group claims that Zig can interop with C based libraries w/o too much work. It's one of the reasons I'm digging into it now. But I don't know anything about CUDA and have only done trivial Zig<=>C tests (like my Zig code working with libpng) so far. Are their claims BS? Is Zig just not mature enough? Something else?
    - t0mpr1c3 3mo ago
      I don't know really. My guess is that Zig cannot be considered mature until someone has written an application in it that contains a Lisp interpreter. I'm banking on Ghostty. Your move MH ;)
    - jjmarr 3mo ago
      The CUDA/HIP APIs are mostly C-like APIs but are really C++ language extensions. e.g. you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it. The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based. HIP is better because it's an open-source llvm backend/frontend but you'd still need to add GPU-specific support to zig/rust/whatever.
      - zzyxy 3mo ago
        > you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it. It all boils down to calling CUDA runtime or driver APIs. Compiler just sprinkles fairly trivial amount of syntactic sugar, and under-the-hood glue code. One can launch GPU kernel from a pure C source file compiled with gcc. > The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based. nvcc is not the only option. Clang itself can compile most of existing CUDA code just fine, and the rest usually needs minimal porting. Also, nvcc is not based on clang. It may use it as the host compiler, but that's the extent of its involvement with clang. IIRC, their front-end used to be based on EDG. > HIP is better because it's an open-source llvm backend/frontend CUDA and HIP share most of the front-end code in clang, so CUDA compilation with clang shares the same benefits. What's missing is PTX to SASS assembler, which creates the actual GPU binary, and that part is proprietary to NVIDIA.

tsimionescu 3mo ago

Systems programming is very much about minutiae, to a great extent. And this particular detail will affect any systems language, one way or another. Every language has to decide if the calling convention is part of the function signature or not, and every systems language then has to decide whether it allows C functions with the same name as native functions or not. The C++ standard decided to allow this, which actual C++ compiler implementers decided to ignore for whatever reason, but that's just a bug, of which, again, you'll find many others if you actually do systems programming. I'll also note that "Odin, Rust, Zig" is a weird enumeration - neither Zig nor Odin are anywhere near being a realistic option for a new complete system. Odin is so obscure it doesn't even have a Wikipedia page. Zig is still pre-1.0 and often makes breaking changes to core libraries.

jstimpfle 3mo ago
To be fair, Odin _had_ a Wikipedia page and it has been removed because of... people with whatever interests. But I'm still agreeing with your general point. I use C/C++ because it seems to be the least friction option to me overall, and I don't want to deal with language but simply focus on my actual compute problem. (Given that, I spend an unreasonable amount of time in silly fights about language).
- tsimionescu 3mo ago
  I've read about some drama with Odin's Wikipedia page - but I don't think that contradicts my point. If your language community can't even defend a Wikipedia page, you're an obscure language that people can't be expected to choose that easily. That doesn't automatically mean it's a bad language, but it does make it weird to recommend it in the same breath as Rust. It's like saying "choose a language like APL or C or Java" - one of these is not like the others.
leecommamichael 3mo ago
I'm talking about design flaws, not engineering details. I would appreciate if you would respond in spirit. I do think the list I gave is odd, and it is so because it's kind of a mashup of recent pop-culture things. I'm literally just appealing to people to attempt to use something designed with the benefit of 50 years of hindsight. Why am I being downvoted?

t0mpr1c3 3mo ago

Lindy's Law says C will be around longer than any of that lot. Although I wouldn't bet against Rust now that it's used for Linux drivers.

bee_rider 3mo ago
C will outlive all of us. C++… I don’t know it well. But I’ve heard there are a lot of different dialects, to the point where it is possible that two C++ programmers might be writing in essentially different languages. How “old” is the language, in that case?
- AlotOfReading 3mo ago
  The dialects issue is why I avoid interviewing in C++, because inevitably it turns out the interviewer has some weird view of what "C++" is and doesn't realize it. Years ago I had an interview in "C++14" that required std::optional (C++17) as implemented by a C++14 compiler with only experimental, nonstandard support. In another case, an interviewer on the LLVM team vehemently disagreed with me that you could legally implement std::atomic types with mutexes, as I was going over a story about fixing issues in an awful stdlib that implemented them with mutexes. This kind of thing doesn't happen when I interview in other languages.
  - t0mpr1c3 3mo ago
    It seems like the history of programming languages since the 1980s has mostly been people trying to avoid C++. First languages with run-times and dynamic types, and more recently lower levels of abstraction (Go, Rust).
    - pjmlp 3mo ago
      I was there, and C++ was all over the place on Windows, OS/2, Mac OS, UNIX/CORBA. It was FOSS with its set of coding guidelines, that gave C a new wind. Languages with runtimes and dynamic types go all the way back to Lisp and Smalltalk.

wyattblue 3mo ago

Consider Nim too!

lallysingh 3mo ago

I've tried it, and no. Honestly C++ gets so many complaints partially because so many people use it. It deserves a lot of it. I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC's DMA/TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator? What's nice about C++ is that your fight isn't against the language and runtime. They don't care what your situation is. They'll work. You do have to assemble it, and other languages make some assemblies a lot easier to do. Yes Rust and its libraries are getting better. But so's C++.

leecommamichael 3mo ago
These are legitimate complaints, and I meant for "if you can afford it" to do a lot of lifting in my first comment.
112233 3mo ago
On embedded, your fight totally is against language and runtime. Since you cannot gave conformant freestanding C++ without exceptions, rtti and most of STL, "using c++" on embedded always turns into "using gcc" or "using clang" — their mutually compatible, but completely standards non-conformant extensions that make writing for embedded reasonable to even attempt. At that point, is the language still c++? Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.