I'm close in age to you but that was one part of the article that resonate w me.
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.
I mean "unwrap()" and "panic!() are right there for "blow up and don't care", if you're really just doing throwaway scripting that should be enough.
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
> code up to error handling in professionally written code
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.
I never understood the pearl clutching going on when people hear that Rust has different constructs for handling errors and control flow and if/else stuff is kinda an antipattern.
Same kind of people that would hold dear GOTO statements in my opinion.
Learning curve is straight up for many with the borrow checker, but once you are over that hump, and it comes pretty quick for most, Rust is no harder than any other language.
Easier than C or C++ for sure. But I definitely wouldn't say that Rust as easy as a GC'd language like Java or Go.
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?
In my experience, it depends heavily on the kind of thing you're writing. I could write some small programs in it, no problem: a rather complex, text-based calculator was easy and elegant to write with function arguments, a game server monitor, some tools for a cryptography course, an FFT analyzer that reads from WAV or AIFF, etc. Then I tried to port my rather efficient Earley parser (https://en.wikipedia.org/wiki/Earley_parser) from C. Constructing the item set efficiently wasn't that hard, but constructing the forest (set of syntactic trees) was. In C, it was basically free by using some pointer sharing, but I couldn't get that done in Rust. Perhaps there's some clever trick I couldn't think of, but I couldn't get it anywhere near C's speed. And since the ultimate goal of that parser includes further memory shenanigans (unification of results yielded by the rules), I dropped the project.
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.
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.