alt Hacker NewsIt's not quite a fully formed argument, but I'm coming to the view that Rust mostly requires less cognitive load than other languages. I'm coming at this from the perspective of "cognitive load" meaning, roughly "the measure of the number of things you need to keep in working memory". Rust is no doubt difficult to learn, there are many concepts and a lot of syntax, but when you grasp it cognitive load is actually lower. Rust encodes so much more about the program in text than peer languages so there are fewer things to keep in your head. One good example of this is pointer lifetimes in Zig and C which you have to keep in your head, whereas in Rust you don't.
My own appreciation for Rust is rooted in humility. I know I'm an overgrown monkey prone to all kinds of mistakes. I appreciate Rust for helping me avoid that side of me
Replies
> Rust is no doubt difficult to learn, there are many concepts and a lot of syntax
People love to say this, but C++ is routinely taught as a first programming language to novice programmers (this used to be even more clearly the case before Java and Python largely took on that role) and Rust is undoubtedly simpler than C++.
>My own appreciation for Rust is rooted in humility. I know I'm an overgrown monkey prone to all kinds of mistakes. I appreciate Rust for helping me avoid that side of me
I think we've heard these arguments ad nauseum at this point, but the longer I use Rust for ensuring long-term maintenance burden is low in large systems that I have to be absolutely, 10,000% correct with the way I manage memory the more it seems to reduce the effort required to make changes to these large systems.
In scenarios where multiple people aren't maintaining a highly robust system over a long period of time, e.g. a small video game, I think I'd absolutely prefer Zig or C++ where I might get faster iteration speed and an easier ability to hit an escape hatch without putting unsafe everywhere.
The mentality around lifetimes is different in Zig if you are using it for the correct types of problems.
For example, a command line utility. In a CLI tool you typically don't free memory. You just allocate and exit and let the OS clean up memory.
Historically compilers were all like this, they didn't free memory, they just compiled a single file and then exited! This ended up being a problem when compilers moved more into a service model (constant compilation in the background, needing to do whole program optimization, loading into memory and being called on demand to compile snippets, etc), but for certain problem classes, not worrying about memory safety is just fine.
Zig makes it easy to create an allocator, use it, then just free up all the memory in that region.
Right tool for the job and all that.