I am not very familiar with Rust, but I thought it permits full control over memory?
I can't think of any. The borrow checker still checks your code but you can forge, twiddle, and cast pointers, there's really nothing you can't do that I can think of.
> In both unsafe functions and unsafe blocks, Rust will let you do three things that you normally can not do. Just three. Here they are:
> Access or update a static mutable variable. Dereference a raw pointer. Call unsafe functions. This is the most powerful ability. That’s it. It’s important that unsafe does not, for example, ‘turn off the borrow checker’. Adding unsafe to some random Rust code doesn’t change its semantics, it won’t start accepting anything. But it will let you write things that do break some of the rules.
Undefined behavior is a completely separate conversation. UB is necessary to output performant code. If dereferencing a null pointer were defined behavior, then the compiler would need to insert a check for every dereference, which would slow down your code.
Hum, no, unless you count inline asm, it simply doesn't.
And for more control over memory than C, Rust allows mapping high-level types into fixed memory, so the compiler can actually use the correct asm primitives and make your access fast. On C you either have to use a general purpose array abstraction or try to map your types over the memory and pray the compiler resolves all the UB the way you want. Most C developers do the later.
For projects where you do need rust, obviously "This is literally impossible to do any other way" takes precedence over "It's best practice to do it this way", but the rest of the time.... I'm not sure I see the tradeoffs unless you're doing some crazy hand optimized low level library, or you just have a strong preference for direct control.
The existence of Redox OS in my mind is enough to prove that Rust can do just about anything and lower level stuff is needed less than people seem to think
Then again, I haven't worked much with Rust, it's only just now supported on any platforms where I'd have a reason to use something lower than JS/Python.
Performance matters in every project, and the way you get performance on modern processors is by using the cache effectively. That requires a certain amount of control over memory layout and access.
It's not so much about what's possible in a given language, it's about what features you're using and what features are getting in the way. Sure, you can write a bunch of unsafe Rust, but at what point are you fighting against the language and adding unnecessary friction?
High level languages are good at enabling high level optimizations like caching and special case handling of things, which might be a bigger gain than anything to do with memory layouts except in a few inner loops.
High performance and reasonably focused low complexity stuff might be a good fit for C, until compilers get even better.
But in a web browser? I guess time will tell, but my guess is the ability to more effectively manage complexity will let people do more high level optimizations with less fear of buffer overflows from more code.
Things like "In this specific case I can fall back to this very simple plaintext rendering for this one section" might save more CPU than "We made all rendering a bit faster" especially if you just keep doing the performance critical stuff in C.