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

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

I like my PCs like I like my cars--rust free.

I like my datacenters like I like my railway infrastructure - covered in enough protective layer of rust that it will never suffer structural damage even when running for years under extremely heavy load.

In that case I recommend using C language. I heard Zig is a good alternative.

Why do you recommend the living definition of not having any protections whatsoever for protection?

Why do you make up nonsense and believe it?

Is it nonsense to say C doesn't have any protections?

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.

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.

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.

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.

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