> In C the cost of everything is very explicit, in Rust it’s very easy to end up with an inefficient binary. I will admit when I first picked up Rust, I strugg

> In C the cost of everything is very explicit, in Rust it’s very easy to end up with an inefficient binary. I will admit when I first picked up Rust, I struggled with feeling as though the code I was writing was too abstract and I had no idea what the compiled code would look like. But if you actually look at the performance characteristics of things such as Rust's default hashmap you find it's more efficient than most hashmaps in C code (because AVL trees are easier to write correctly in C, but B trees are faster and in Rust users can be sure they're using them safely). > unsafe blocks seem to defeat the purpose of Rust. It’s like building a proof on top of lemmas that are just random guesses. Not really, (using your analogy) unsafe blocks are more like human-checked proofs while everything else is machine-checked proofs. Obviously the humans doing the checking of the unsafe blocks can make mistakes (hence why you should minimise it), but unsafe blocks still must obey Rust's memory model. > Clean builds of my test project are very slow. Yeah that is still a noticeable problem. But to their credit, they have been slowly improving compile times for several years now.