You’re confusing standard library naming. Rust has a layered standard library, “core” and then “std” on top of it. They’re using the core library, because that’s what you do in an OS context. But as far as I know they don’t restrict any language features.

They also didn’t have to write a new allocator; they did extend the interface of the “alloc” library (which sits between core and std) which was then also accepted upstream.

So, what software can you make without relying on "std" library?

I think that a lot of complexity in Rust comes from many different ways to handle memory. You have your Arcs, Boxes, Cells, etc. Then you have a core "alloc" library.

Maybe if everyone agreed on a single reliable method to handle heap memory (since using stack is easy), Rust wouldn't be so hard to use.

The syntax also could be improved. Seeing <Box(T)> or whatever nested three or more levels deep hurts my eyes.

You don't have access to the C standard library in the Linux kernel either, so what is your point? Ime., the core library of Rust is much nicer to work with than the absolute bare bones landscape that is C when compiled with -nostd.

Boxes, cells, arcs, etc. exist for different purposes and if you'd take two hours to actually read about them and their uses, you'd understand why they exist.

You can write lots of stuff. The stuff you lose access too is mostly things that rely on the OS to function, so you lose file system stuff, networking stuff, things like that. Of course, people have written their own implementations of these things when it makes sense to do so.

Thank you Steve. There is so much misinformation surrounding rust it's unreal...

It's also kind of normal to you know tweak a language so it integrates with an OS better... Even if they did change their allocator, who cares?