I started working with C in 1986 and C++ ever since you could buy a C++ compiler on the PC (Zortech C++ compiler first, then Turbo C++ after that). The C runtime library is lacking compared to modern languages, particularly with regards to string management. Memory management takes a lot of discipline.

Modern C++'s runtime library is much better, but saddled with enough other bloated framework code that it can be very slow (if you don't believe me, time the std::regex library compared to- hell, any other language). But one thing C++ does get correct in my opinion is destructors and smart pointers. I’d like to say that C++ gets strings right, but when you have so many different string implementations and no automatic conversions between them, it becomes a PITA. In fact, working with strings in C++ can be even more of a PITA than C. Need to convert between std::wstring and std::string? It’s not automatic, and it absolutely should be. And wstring is not the same as a u16string or u32string, and unless you use a third party library, it’s going to still be a PITA (no, you shouldn’t be using wstring_convert anymore because it’s been deprecated). In any case, on the topic of memory management, if you aren't making use of RAII concepts when using C++, you're absolutely doing it wrong (and while I hate the term RAII, the concept behind it is very useful).

I've always been anti-garbage collection, even when Java proponents were singing its praises (while still having to track down resource leaks and putting up with services "going on short vacations" in production ). I feel like it is the philosophical equivalent to waiting until the end of the week to clean your entire house (even spilled crumbs on a table) rather than cleaning it after you make a mess. Despite the fact that I absolutely love Go, I dislike the decision by Rob Pike & Co to implement garbage collection. But Go is so highly productive that I've made peace with its Garbage collection (as well as its weird date/time implementation).

I can see why energy efficiency of a language is a concern to someone like Amazon, who probably runs hundreds of thousands (or millions) of servers. But for almost everyone else, the one metric which matters most is time to market. So while I'm not claiming Go is better than Rust (I don't actually know Rust yet), time-to-market is a very difficult metric to ignore.

As a longtime C and C++ developer I will eventually invest the time into learning Rust; I think it has a place in the world, particularly in high-end performance scenarios like operating systems, databases, games, and financial apps. But Go is going to be around for a very long time.