> I want to have fine-grained and full control over memory management. Rust's global allocator is easy enough to replace on stable: https://doc.rust-lang.org/s

> I want to have fine-grained and full control over memory management. Rust's global allocator is easy enough to replace on stable: https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html Per standard container allocators ala C++'s std::allocator haven't been stabilized, but are available on nightly: https://doc.rust-lang.org/std/alloc/trait.Allocator.html https://doc.rust-lang.org/std/alloc/trait.Allocator.html Alternatively, you can roll your own allocator ecosystem easily enough - my limited foray into this is mostly focused on interop with specific 3rd party allocator APIs from C, C++, Win32, etc.: https://docs.rs/ialloc/ https://docs.rs/ialloc/ , there are plenty of crates focusing on arena allocation etc. instead. > Can rust generate usefull machine code without a runtime and having to break one leg like C? Yes. At one extreme, you can create #![no_std] crates ( https://docs.rust-embedded.org/book/intro/no-std.html https://docs.rust-embedded.org/book/intro/no-std.html ) which don't assume you can create threads, write to stdio, or even allocate heap memory. I've gotten Rust static libraries linking into "unsupported" platforms in minutes (when it had an LLVM-compatible linker available.) At the other extreme, I've previously ported Rust's standard library to an unsupported NDAed platform. It's easy to stub out unsupported bits - the code for such stubs already exists to support wasm32-unknown-unknown (arguably a mistake, but it's a useful one!) - and replacing those stubs with real code isn't too onerous in my experience either. Middle grounds of `extern crate alloc;` let you support subsets of "the standard library" as well. Yanking all "runtime" support out of existing platforms might be a bit trickier (e.g. there's a little code to support populating std::env on *nix, a little mucking with default signal handling, and e.g. windows builds will use Win32 APIs for backtracing and unwinding for panics - ripping that all out is more obnoxious, but also pointless IMO.) Some non-NDAed examples of targeting funky stuff: • https://github.com/MaulingMonkey/uefi-hello-world https://github.com/MaulingMonkey/uefi-hello-world (why write hello world for windows when you can directly boot hello world?) • https://github.com/MaulingMonkey/rust-opendingux-test https://github.com/MaulingMonkey/rust-opendingux-test (old, linuxy - see Notes.md, consider using -Zbuild-std instead of Xargo these days?)