2 ms·

I don't see much value in that kind of sniping. Especially in a world where C is still the most popular language in domains such as spacecraft control software

I don't see much value in that kind of sniping. Especially in a world where C is still the most popular language in domains such as spacecraft control software or operating system kernels where correctness is of the most paramount importance. One doesn't need to meditate on that for very long to realize that choosing a non-memory-safe language is not a decision that correctness is not important, it's simply a decision that the programmer must be personally responsible for yet another aspect of correctness. Also, needing to make a hard choice between "faster than Java" and "memory safe" was a problem for the late 1990s. 20 years later, we have a lot more options.

lmm 6y ago
I've spent a significant proportion of my career working on financial codebases that did serious number crunching in Java and were performance-bounded, and Java was still absolutely the correct choice for those codebases. So the idea that performance is irrelevant for those domains in cases where Java is a reasonable choice is completely wrong. Having the programmer be personally responsible for memory safety doesn't work, we know that now. What spacecraft control software is written in isn't really C any more than typescript is javascript: yes, the final runtime artifact is in C, but the "source code" includes a lot of additional verification material without which it wouldn't be valid. As for operating system kernels, even Linux isn't written in C any more because C is too unsafe; rather it's written in an ad-hoc language that provides stronger safety guarantees (which it compiles by passing special parameters like -fno-delete-null-pointer-checks to GCC).