3 ms·
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
by bugfix-66 4y ago
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?
- Ar-Curunir 4y ago> Garbage collection becomes almost a necessity when you have enormous concurrency and parallelism. No, you can just use Rust, which provides thread safety without garbage collection.
- sqeaky 4y agoI 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.
- kllrnohj 4y agoPretty 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.
- YetAnotherNick 4y agoI 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.