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 :)
I will say that playing around with Rust was an enjoyable experience, but it still has some warts where I think it's not quite ready for serious work yet (even though serious work is being done with it).
These days I find myself leaning heavily on either Haskell or Elixir/Erlang's ecosystem (with a preference for the latter). Or JavaScript (there's just an order of magnitude more jobs)...
I can install a working Haskell toolchain with my package manager instead of the farcical `curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh`.
If you're an automation-oriented kind of person like it's my job to be, setting up repeatable toolchians based around the above is a total crock of shit.
Rust/rustup is in every package manager like ever. As someone who is "automation-oriented" you sound like you don't have the faintest idea what you are talking about.
Every non-Rustacean who has suddenly had Rust forced into their workflows asks for this to be solved, specifically, and the Rust community keeps digging its heels in.
Haskell has its warts but it's not 101-level shit like this.
"Getting this right" is a matter of opinion, and either way, rust can be installed a variety of ways. Your argument is literally nonsensical and demonstrates a seriously arrogance and lack of familiarity with what you're talking about.
What is your threat model that isn't solved by some combination of a rust-toolchain file and using your package manager (nix or whatever) to install rustup?
If you want to isolate your build machines from the internet entirely, you're either going to use a hermetic build system and have some equivalent of vendoring your compiler, or manage your own internal package repository in which case you can just add your own Rust + Cargo build to it.
If you're paranoid about building the Rust compiler from source, you can even put in the effort into bootstrapping your own lineage. But given that you're ok relying on your package manager for Haskell, it seems like this isn't a huge problem for you.
I use Rust for just about everything and I can definitely think of plenty of warts, but none of them make it "not quite ready for serious work" for my definitions of "serious work". I guess my point is that I'm curious what serious work this user is doing that Rust is unsuitable for - that kind of information is useful for language evolution, among other things.
> 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 :)
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 :)