The successor to C must be designed for a world where it's typical for an application to use dozens of CPU cores. This is the main reason we need a successor to C.
Garbage collection becomes almost a necessity when you have enormous concurrency and parallelism. I wonder whether you have experience writing such programs with pthread and malloc/free?
Pretty much any malloc/free worth even considering using has thread-local arenas. On top of that, you can always go with custom allocators (such as bump pointer arenas) with C/C++. There's no issue scaling across dozens or hundreds of CPU cores here. Heck, the most parallel of all parallelization in computing, GPU compute, regularly uses C/C++ as the source language.
Go, on the other hand, does have scaling issues. So do most GC'd languages in fact, as the GCs want to periodically park all threads to walk their stacks. Even the latest & greatest GCs, like Shenandoah, still gotta park all them threads periodically for milliseconds at a time.
I am not going to call the problem solved, but there are other options too.
C++ has libraries threadsafe shared pointers, interthread message passing, transactional memory, futures/promises, work stealing queues, and access to all the OS primitives to build anything else.
I have the opposite experience. It is considerably easier to write performant and scalable parallel program in unsafe language like C or C++, with libraries for parallel containers, than in Rust or even Go. Of course the price we pay is that it is much more probable to have bugs.
Exactly. High performance applications with zero cost abstractions are required to truly be a successor. Go or Java will never replace C++ for high performance applications like Game engines. Rust might replace it though.
