I think you need to specify what you mean by "without a runtime". Do you mean "without a garbage collector"? "Without memory allocation"? Even C has a runtime, just a very small one.

> Can rust generate usefull machine code without a runtime

Afaik, the only runtime parts of Rust are panic handling, standard library and thread management.

You can disable the standard library with `#![no_std]`, and I'm fairly sure you can also disable the panic handling (but not 100%) and I don't know if you can disable thread management at all. But if you can, I think you can have what you're asking for :) Edit: In fact, the `no_std` might actually disable all of the above, not just the stdlib.

I would call Rust comparable to C when it comes to giving you the ability to have control over memory management and machine code. Which is to say, if you have a problem with how C does it, then I doubt that Rust will make you any happier in this regard. What pain points in C is this referring to specifically?

The smallest binary rustc has ever spit out is like 137 bytes.

It has the exact same amount of runtime requirements as C. The default configurations aren’t optimizing for size, but if you want to strip it down, you can.

You will always have Assembly for driving dangerously fast without either a seatbelt, nor an helmet.

By the way, even C has a runtime, without which several ISO C features aren't available.

That is why there is a freestanding section.

> 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

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

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/ , 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 ) 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 (why write hello world for windows when you can directly boot hello world?)

• https://github.com/MaulingMonkey/rust-opendingux-test (old, linuxy - see Notes.md, consider using -Zbuild-std instead of Xargo these days?)