Rust also hides allocation, and both the standard library and community best practices encourage many smaller allocations, which makes it much harder to reason about performance characteristics of your code.

So what you say is definitely true if you do an allocation heavy, heap fragmenting, RAII style of programming. Which is the context Rust was born in, right? A kind of C++ app dev context where that was (is?) the prevailing meta.

You're also completely glossing over the incredible complexity you get in all thee weird intersection of rust features. And there are a LOT of features. Reasoning about those are not free from a mental overhead stand point.

> Rust also hides allocation.

Does it? In Rust you allocate by calling a function. That's exactly the same as C. Are there any langauges that don't allow you to hide allocation behind a function call?

> So what you say is definitely true if you do an allocation heavy, heap fragmenting, RAII style of programming.

I don't think Rust encourages lots of small allocations. Most of the Rust code I work with does a lot of arena allocation (using crates like https://github.com/orlp/slotmap) and reusing of allocations. And for that matter a lot of stack allocation avoiding the heap entirely. And it's borrowing system is fantastic for working with shared pointers to data without having to worry that something might accidentally overwrite it.

> You're also completely glossing over the incredible complexity you get in all thee weird intersection of rust features.

I don't really buy that Rust is complex. More complex than C I suppose (but C just pushes all the complexity into making you write 5x more application code), but closer to something like Java than something like C++.