I've used Go and Rust professionally and in side projects, and I had used Go first before Rust. When I first used Go, I was like "oh wow, this is so simple and easy", and I didn't realize that I was putting up with the language. Learning Rust was relatively harder, but once I did and wrote some non trivial programs in Rust, it was like a pathway in my brain opened up and was previously blocked, and then when I went back to Go, I was painfully aware of issues that I the programmer had to keep in mind (or write a LOT of boilerplate code to keep track of). Issues that Rust's type system just solves.

The way `nil` can seep into your codebase in Go and how bad the FFI is in Go will prevent me from ever choosing it for a project going forward. And I personally would not feel confident modifying Go code written by someone else, and would not feel confident accepting PRs into my Go codebase unless I understood every line inside and out.

Rust is a breath of fresh air in that regard.

All that said, I think the author here is idealistic in a certain sense. In the scale of "solving a problem by hand (or using Excel/a proprietary tool etc)" to "writing a computer program to automate it", both Go and Rust are very close to each other. And once someone learns Go and knows it well enough, the incremental cost of learning Rust or even thinking about the problems Rust solves for you becomes not worth it. I think that it's sad that this is the way it works, but that's just how it is. It's easy for settle for a local optima like Go when taking into consideration family, pets, salary, time, effort etc.

I do think on a long enough timescale, programmers will eventually move to a "better" language. But in my opinion, that time scale exceeds the lifespan of a human :)