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”.

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.

> 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