Someone hands you a waffle head hammer seems like a more apt comparison.
If you can get the hang of it, it’s a safer hammer. You’re still going to be manually managing your memory allocations though. The nailgun people have garbage collection (and yes for the gc folks, I’m aware you can still write allocation free code, or at least take manual control of allocations in a garbage collected language and therefore opt out of garbage collection overhead - but why would you unless there was a performance issue)
I don't manually manage my memory anymore in Rust than I do in garbage collected languages (say Python or Go). (I do have to think about object lifetimes and whats pointing where in all three mentioned languages).
As an aside, I really like not having to manually free locks, close files, release connections back to pools, etc. It's one resource management paradigm that applies to everything - not just memory.
Don’t get me wrong, I really like rust, but you can’t deny that in Java or python you can just put/share this class/object here that changes the lifecycle of a bunch of other components and it will Just WorkTM thanks to the GC. While in Rust such a refactor will be safe in the end, but you will have to manually look into a bunch of uses of said struct(s) and recursively refactor the whole thing while fighting (or being helped) by the compiler.
This is the (in my opinion) insurmountable difference between low and high-level languages. Even though rust is (arguably) probably the best/most readable low-level language that as you note can sometime even beat managed languages (locking/file close), it will loose to major refactor-speed.
>You’re still going to be manually managing your memory allocations though.
I'm writing a 10,000 LoC library and I call drop() manually only 3 times, in exactly one place, and not for memory reasons. I'm not sure what you mean. If you mean thinking about lifetimes, sure. If you mean thinking about drop(), almost never.
If you can get the hang of it, it’s a safer hammer. You’re still going to be manually managing your memory allocations though. The nailgun people have garbage collection (and yes for the gc folks, I’m aware you can still write allocation free code, or at least take manual control of allocations in a garbage collected language and therefore opt out of garbage collection overhead - but why would you unless there was a performance issue)