I think a question that must be asked is "what market?" Go is a very niche language in it's application: it is ubiquitous in the Docker/Kubernetes DevOps world. It's also successful as an alternative to Node in the server/micro services world. And there are many CLI tools written in it (but CLI tools can be written in any language whether or not it has critical mass - there are popular ones even in Haskell!).

Excluding CLI, Go's use cases virtually did not exist when Go was created. So Go was "the right language at the right time" to grow up with it's niches (decent performance, easy to learn, easy to reuse library code, easy to deploy, easy concurrency). It is virtually non-existent anywhere else.

On the other hand, Rust competes in exactly the same high-performance/low-overhead space that C++ dominates. Because of Rust's complexity, it is very unlikely that it can compete anywhere else. Rust must displace C++, or at least be a viable alternative to it.

I wrote a BBS in Rust. It need sleep neither high performance nor low overhead, but it was a delight to write. For example, the compiler error messages are so detailed and explanatory that I learned a lot of the language from it telling me what I was doing wrong and offering suggestions.

I would’ve written it in Python a year ago. Now I wrote it in Rust because it was genuinely fun and the results came out nicely.

I have zero interest, none, nada, in C++. (Readers: please don’t try to win me over. I know more about the subject than you might think and it’s an informed opinion.) For me, Rust doesn’t compete with C++ at all. It’s probably replacing my Python coding more than anything else. The output looks and feels quite Pythonic, but with strict types and AOT compilation to native code. I’m loving it.

What do you mean when you say “Go’s usecases did not exist”? It was invented to write concurrent servers in that would have readable, performant implementations suitable for use across teams, to make code review faster and better, to displace C++, and to prove that certain design principles from Dis / Plan9 were superior to those in Java. I’m not really clear how those usecases did not exist at the time. If you mean “Go is for scheduling containers”, you are wrong, but just because one popular application exists that doesn’t imply that is “what it’s for”.

> Because of Rust’s complexity

I would argue there is 2 types of complexities here:

1. Complexities when developing (Rust) 2. Complexities once running in production (C++)

I’d much much prefer to have errors and frustrations developing than users dropping out of the sky at 40,000ft