> Rust and Go are not readily comparable. Rust is a systems language aimed at the same domain as C++ and, to an extent, C. Go is more akin to Java and Python.

> Rust and Go are not readily comparable. Rust is a systems language aimed at the same domain as C++ and, to an extent, C. Go is more akin to Java and Python. In a sense yes, although Go compiles to native code and offers completely different performance compared to an interpreted language like Python, and no JIT warmup periods of JIT compiled languages, and no dependencies on runtime environments or virtual machines, and from the outside runs confusingly similar to a native C application. Also, C/C++ is such huge languages that they are in use in _far_ more scenarios than low level systems programming. Maybe that was the intention when they were designed, but usage exploded on e.g. Windows before the days of .NET and many still prefer it over .NET due to performance. Even if these are then desktop applications using Win32, Qt, or even MFC. C is also heavily used in development of e.g. GNOME applications with GTK+. Also a huge field of non-system level desktop applications. C / C++ is also usually preferred for games development. This is why I think there's room for Go even in the context as a C/C++ successor simply because of the field where C/C++ is used is just so darned huge, although I do agree that if the application here is a close-to-metal application where you don't have time to wait more than a millisecond on a garbage collector or need complete control over memory use, Rust may be more useful and in this sense yes, be more like a spiritual successor to C as well.