A rebuttal to The success of Go heralds that of Rust

George writes that Rust is superior in every way to Go. Go read it here: https://medium.com/@george3d6/the-success-of-go-heralds-that-of-rust-73cb2e4c0500
This may sound defensive. I apologize for my poor writing. Instead, I want to suggest that the entirety of the OP is written from the wrong mindset and that the below points are specific instances of that wrong mindset.
The article ignores the number one reason that Go was written: SPEED OF COMPILE TIMES! The article also ignores another very important reason that Go was written: It is for programmers, “not capable of understanding a brilliant language but we want to use them to build good software”. The quote is by Rob Pike.
The article places some importance on immutable types, would the average programmer know how to leverage an immutable type to any benefit from it?
“The standard library of Rust is just as rich as that of go” — REALLY? Where is net/http? That absence alone makes this statement an outright lie. Looking for json, xml? Again not in the stdlib. Compression and archiving like tar, zip, bz2, lzw, gzip? Again in the Go stdlib, not in the Rust std. Cryptography including symmetric, asymmetric, and hashes? In the Go stdlib and absent from Rust std. I could go on, but I’d have to refer below the fold of the Go standard lib. Compare https://golang.org/pkg/ to https://doc.rust-lang.org/stable/std/ for yourself.
“The package ecosystem of Rust outmatches…” Maybe, but not in some important aspects, consider https://github.com/search?q=language%3ARust+stars%3A%3E1000&type=Repositories vs. https://github.com/search?l=&p=1&q=language%3AGo+stars%3A%3E1000&ref=advsearch&type=Repositories&utf8=✓
“I think we could call Rust a superior language to Go in, quite literally, every single way possible.” Not in speed of compile time. Not in ease of use for the average and below average developer. When these two points are your most important values, Rust does not look superior at all.
Regarding passing the critical point and being a mainstay, I absolutely agree. Rust is here to stay and I’m glad that it is. Regarding it being a better language than any other for most tasks, I absolutely disagree. Rust’s place is to replace C++. It is a simpler, more sane, language than C++ to be used in the same places, when that level of control is needed. For anything else, a more simple language with less mental load required and faster compile times is better suited to the task.
Finally, on the mindset and point of view, if “superior” does not take the human aspect into consideration at all, this post may have a lot of truth to it, however, code is written by humans. Humans have different needs than a bullet lists of supported features. Keeping in mind the goals of the Go programming language when it was written (from Rob Pikes 2009 Google Tech Talks presentation): type safety, memory safety, good support for concurrency, GC, and speed to compile.
It is easy to forget that as projects grow, compile speeds become non-trivial. Many languages had tackled all of those things, except the last. Go continues to put emphasis on this. When compile speed was greatly slowed with the 1.4 release, it was increased greatly in the next few releases until it was faster than it had been before. This is an important principle in developer productivity. If we stop valuing this, then one of the most important parts of Go isn’t valued. If you aren’t going to value that, then you must say so. It is, after all, one of the most important parts of the language.
Continuing on the mindset and point of view: the article places little value on the simplicity of Go. This is another one of Go’s greatest strengths. There is no doubt that generics, and memory management in Rust make it more complex than Go. Go’s simplicity is such a huge strength that many developers do not want generics in the language. They don’t want that added complexity. To ignore this simplicity as a value is to ignore one of the most important part of the language.
Given these additional things which we must value when comparing things, the conclusions made in the article simply are not that simple. Yes, there is a place for Rust. There is also a place for Go. Should anything being written in Go be written in Rust instead as the article suggest? Absolutely not.