alt Hacker NewsI program C for my day-job.
I see Rust encroaching in proposed transitions. It may even happen. That said, it is a poor match for it compared to something like Zig (or Odin). It's hard to make the new Rust code use existing allocator abstractions (so now you have two systems doling out memory, how do you reliably free composite objects with memory from both? How do they share?) and you increasingly have to either abandon any actual benefits of the borrow-checker, or invest increasingly heavily into sufficiently fat bindings to wrap your existing C/C++ in a way where the borrow-checker can assist you. That's before we consider the complexity of the language - I'd doubt a seasoned C programmer has much trouble deciphering Zig or Odin FFI bindings, but in the case of Rust? Yes, there is real friction.
Also if you really value predictable- and higher performance, being in more in control of memory allocations and cleanup is preferable. This is the direction both Zig and Odin cater to.
If you asked me what solves the most issues without adding too many new liabilities, I'd say Zig (or Odin). It would simply be much, much easier to transition a C codebase to either, and either would bring a much improved stdlib with pluggable allocators capable of leak-detection etc.
Replies
C++ programmer here. I've looked at transitioning some of my code to Rust; not particularly out of a dissatisfaction with C++ but more just out of curiosity. I've always ended up deciding against it though, I feel like its safety features just come at too high of a price for the kind of work I do. If I was writing something that needs to be super secure like a web server or something I think it would make a lot of sense, but for most of the things I do memory corruption is relatively easy to avoid with good patterns and a crash just kills a local application. YMMV but I think the "safety" of Rust gets a little overhyped.. most the bugs I run into are not memory safety bugs.
If you allow, I’m curious: If you felt familiar with the language just as much as with C/Zig/Odin, would you prefer Rust for a completely greenfield project that requires no C interop (or none more detailed than say providing a general ABI)?
Is there a reason you cannot specify your allocator of choice in Rust? AFAIK, the abstraction exists to do just that.
If you literally want one and only one allocator instead of the Rust's built-in one, that's been supported for years[1]. Almost 8 years, to be precise. It's very easy to implement and works with the entire standard library and all its abstractions, and almost every 3rd party library will support it out of the box too (except the ones that go out of their way not to support it for some reason). Borrow checking and all the other safety features are still fully supported.
Now, mixing different allocators is a different beast, and much less supported. But it sounds like you are very much not interested in this use case, right?
[1] https://doc.rust-lang.org/std/alloc/index.html