Buffer overflows in the hash reference implementations have zero relevance on the algorithm's hashing effectiveness. Fortify posted the results of their static analysis tool to the web as an academic exercise and PR stunt.
That it continues to propagate the web is merely amplifying the FUD.
(Anything I would use C for, I now use Haskell for. Everything runs as fast, and the language and libraries are much better.)
The other things are just going on momentum. C is not a good choice for those applications. (For example, look at SBCL and GHC. Two of the fastest language runtimes, and both are self-hosting. Yeah, you need a little bit of C to interface with the underlying OS, but the critical parts are not C.)
Anyway, nice attempt at snark. It earned you an upmod.
Personally, I think that the "kernel" will begin to be a smaller and smaller part of the OS. More like L4 et al, as the performance costs become smaller (L4 is already pretty good).
Eventually, C might become the old assembly; you need a small amount of it to get started, but once you've boostrapped, you can live in higher-level code.
I think the issue is first performance (you can't context switch fast enough in a high-level language, and more importantly the concept of a context switch in most OSs is kind of tuned to the C language), and the second is universality; you want the lowest common denominator in the kernel.
Among many other things, controlling which part of the disk based data to mmap in. These are things that a higher level language's runtime can't just optimize for you.
From 2001-2005, at Arbor Networks, I worked on a codebase that basically had to bucket the entire Internet, as seen from (say) the core routers at British Telecom, on varying timescales. Obviously, we wrote it in C. It was not optimal. What's worse, changing it was a huge nightmare. Most of the performance improvements we came up with (at least in my first year) were design issues (like messing with precision, storing runs of zeroes, things like that). Most of the bugs we has were textbook C issues, like failing to address shared memory properly.
I'm totally not sold that high speed disk I/O demands C.
Nothing, mechanically. I was more referring to the efficiency of doing it (OK, one thing I'm learning on HN is that I can't just think of it as a casual chatroom, need to flesh comments out more). And note the original question was an actual question and also I'm sympathetic to what you're saying.
I was taught that with raw pointers and memory control, the database implementation would chunk all the right stuff efficiently in and out from the disk and it could get directly to any row/column naturally with pointer arithmetic. I thought DBs even managed the disk directly and had their own buffer cache like in the kernel.
This part of things doesn't look like a high level language task to me, especially because of garbage collection. And I'm sure, like with most things where I lack implementation experience, this is only the most cursory view of the field.
My preferred mode of work is to use Python and if there's a true bottleneck/limitation from the language features then break it out into a C module. Maybe something like this would be more appropriate here instead.
You will notice, though, that the Haskell crypto libraries are generally "pure Haskell", since there is not much of a speed hit for not using C. This is the Future.