[pseudony]

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

[Xirdus]

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

[overgard]

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.

[dwattttt]

The safety aspects do get very hyped. It's better to consider the language strict about correctness; memory safety falls out of that, but so does other stuff, like less logic bugs.

[pjmlp]

Thing is, this is from someone that likes Rust, but for various reasons has to reach out to C++ when going outside my daily use of managed languages, while C++ will never be as safer as Rust, there are many tools to get us half way there.

The big problem is that many projects keep ignoring those tools, the way Zig sorts out reporting use after free errors, the same solution exists for C and C++ for about 30 years now.

[plandis]

Is there a reason you cannot specify your allocator of choice in Rust? AFAIK, the abstraction exists to do just that.

[msdz]

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)?

[pseudony]

Sure thing :)

Just my opinion. It really depends. For systems- kind of software (low-level, DBs, file systems (also user-space)) no, I wouldn’t - if you manage memory with arenas and/or can plug in an allocator to tell you if you leaked memory (provided the codepath is triggered), I mostly get what I want with less mental overhead. Also, I very often want to interface with C libraries.

For games, again, I wouldn’t. I again strongly suspect I would and could organize my use of memory better.

I suspect Rust is best when you don’t want to interface with C code (except through bindings others wrote) and you’re maybe more doing applications development where C++ has also stood strong. I completely see how, theoretically, Rust can make a great language for an office suite, browser and so on.

That’s actually also when I tried Rust for a personal project. I wrote a desktop application and while I spoke to C code, I only did so through bindings others had written.

It was/is fine :) I still got a segfault bug though hehe.

Basically I liked Ocaml so I have huge appreciation for all that Rust tries to bring into the mainstream on that front. I am just not thinking that the borrow-checker makes it well placed to interop with C. It becomes much better for relatively isolated applications work.