C++ tries to make the same guarantees that the Go 1 compatibility promise makes. (Or at least very similar; they are different languages after all.) Basically

C++ tries to make the same guarantees that the Go 1 compatibility promise makes. (Or at least very similar; they are different languages after all.) Basically: old code should keep working possible, but they have the right to invent new features. The real difference is that C++ is feature-philic (new feature: want!), while Go is feature-phobic (new feature: avoid!) Of course, if you want to make specific predictions about which features C++ or Go will adapt, then you need to look at details. For instance, Stroustrup tried hard in the early days to ensure that user-defined types are on equal footing with built-in types, while Go tried hard in the early days to make sure that very common foundational types are built in and have good support. Thus today the C++ standard library has two at least two distinct dictionary types, while Go has one built in to the language. (Someone who actually knows more about Go history than I do, please correct me if I'm wrong.) I tend to favor the C++ approach as more mathematically pleasing, but I can't deny that the Go approach leads to a simpler language. (The real question is: which one leads to better programs, and I suspect the answer is "it depends, on way too much stuff to even list".)