5 ms·

No one is using C anymore, except for trivial things like kernels, database systems, and VMs.

• jrockway 18y ago
  Kernels are trivial (straightforward is a better word) and are very close to the hardware, so C works pretty well for them. If you started a new OS kernel today, though, you wouldn't have to pick C. 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.
  • likpok 18y ago
    The bigger issue with kernels is that they are, as you say, close to the hardware. That makes them harder to do in higher level languages (you need something to run on...). However, it is possible to do, for example Singularity. 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.
    • tptacek 18y ago
      I don't think proximity to the hardware is a big issue (we do a lot of hardware work --- at the interrupt-handler, polling-MSRs, hard-timer level --- and we take pains to stay in Ruby, an incredibly slow language. 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.
• tptacek 18y ago
  RDBMS's seem like the next likely C stronghold to fall; they're I/O bound and feature-laden.
  • timf 18y ago
    Isn't there a lot of pointer arithmetic in RDBMS land?
    • jrockway 18y ago
      Well, it's written in C. That's what everything written in C does.
      • timf 18y ago
        My point was that database performance goes far beyond "waiting for the disk." The data is laid out in specific ways with specific widths, there are decades of implementation experience behind making queries and inserts fast because of this. 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.
        • tptacek 18y ago
          What part of laying things out in specific widths prohibits an implementation in a high level language? 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.
          • timf 18y ago
• jamii 18y ago
  Statistically speaking, noone is writing kernels, database systems and VMs. You're a statistical anomaly.