Why Go is doomed to succeed
It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers.  C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.")<p>Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interface{}" tend to be needed too often.  Other than that, there are few killer problems with the language when doing server-side stuff.<p>The libraries for doing web server type stuff are available and well debugged.  When you use a Go library that came from Google, you're probably using code that's executing a few million times a second on Google servers. (As I mentioned on here a few months back, I recently ported a medium-sized production Python program from Python 2 to Python 3. I found library bugs which would have been found long ago were the code heavily used.)<p>So yes, Go is doomed to succeed.  That's not a bad thing.<p>As for Rust, while I like Rust personally, it may be too complex.  The borrow checker concept is brilliant, and a huge advance in understanding how to avoid a big class of bugs. We'll see that again in future languages. The type and generic system, though, pick up where C++ left off, and seem to lead library developers to develop very complex interfaces.<p>Rust is for people who debate language semantics on Lambda the Ultimate and program in  Haskell for fun. Go is for people who have a job to do.