>>65The thing is if C is even x10 faster(with inlime asm highly likely) the benefits and safety of using high-level language evaporate. Imagine
1.You have software that does task X
2.You can run X in Y time or use Z-language with 10*Y runtime
3.Z is safer and more reliable, but it will need x10 the hardware cost or if its parallelisable x10 servers.
4.It will cost significantly more to use Z in real world, then to test and debug X.
Z-language will remain superior and more reliable, but it won't help in this case, and many cases of performance/memory limits hints hardware decide the software, rather than the opposite.
In Z-language land everyone is blessed with dual-xeon/Titans setups but normal people can't afford that shit, and businesses/companies/etc don't want to waste money too.
The result is lots of C and asm, micro-optimizations that bring 0.1% faster code and save 0.1% of datacenter costs.
The only real alternative to C is ada/spark, which requires much more development time to get the same speed as C programmers gain from a few hours of optimizing a piece of code.
So in summary fast/cheap/unsafe C/C++ code is often the optimal solution in many business and research needs. It would be nice if everyone switched to something safer but there are tradeoffs they don't realize, making languages other than C or C++ less viable, while C deficiencies are fixed by libraries having features from these languages.