I'm nearly 51 and currently learning Rust.
The first 10 hours of it were horribly slow, but it isn't as steep of a learning curve as Optimal Control Theory.
I'm often writing little scripts for my computer or things that a dozen people will use, if I'm lucky. If the program 'crashes' it barely matters.
It feels like, in Rust, I have to carefully choose my data type and use the applicable methods (not always intuitive), whereas in Nim or Go, I can basically just slap something together and then have an error condition which is like 'if you die, just print that you died and quit.' And that pretty much meets my needs. The extra safety isn't actually protecting anything valuable, in my case.
And the "?" operator is way more ergonomic for throwing actual errors up a level than all the boilerplate in Go.
The pattern matching with `match` `if let` and `let else` are pretty easy to use to unwrap Result and Option enums.
And then the "anyhow" or "thiserror" crates make it all more ergonomic.
The end result is something is much more readable than all the error handling in Go, while still being at least as safe if not more safe.
Plus you wind up playing with Monads without needing to know what the hell an endofunctor is.
And there's no null/nil, while Options have to be explicit and if you squint (because of the presbyopia) they look kinda like the nillable stuff in C# 8.0
To reiterate, for throw away code (or tests) unwrap() and panic!() will work just fine.
Lol, if you knew how much python code runs the world without even checking for exceptions, or with a try/except/pass ... and the world keeps on spinning.
"professionally written code" made me chuckle
Same kind of people that would hold dear GOTO statements in my opinion.
They have strictly less constraints to deal with, they can let you use the simplest pattern for the situation, and (in my experience) they have less superfluous refactoring sessions due to the overly conservative nature of the borrow checker. I like how Matt Welsh put it in https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...:
> What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again.
Perhaps you're instead speaking of a specific situation or kind of program where the borrow checker happens to be no harder than any other language?
At my job, I'm writing in Go. I fairly sure I could easily port the C code to that. It would probably run a bit slower, but the algorithm and data structures would be readable, and extendable.
So: it depends.