This article presents as a language flaw what is really an operating system flaw. Exposing system functionality through dynamically-linked C libraries, and using C features that do not guarantee ABI compatibility, results in an OS interface that does not provide backwards compatibility.

When I ran into similar problems trying to distribute a binary for Linux users, I thought "Screw it, I'll just statically link everything." But the older statically linked C libraries would crash on newer kernels, and the newer static C libraries would refuse to run on older kernels. (Or do I have that backwards? Anyway, I ended up concluding that Linux doesn't really have a stable ABI.)

Now, if you think "operating system" == "kernel", then, yes this is a language problem. And yes, people who write in x86 assembly and directly invoke the Linux kernel don't have all of these worries. They have much more manageable backwards compatibility issues. But for most of us, "programming to Linux" means using the APIs defined in man pages.

Perhaps the actual "OS API" should be more completely divorced from C library issues. The kernel should define its own contract in some kind of IDL from which one can generate APIs for any language (including all of the variants of C that differ by implementation choices). Yes, it should map to C without any impedance mismatch, and the C folks can deal with how exactly it maps to different implementations of C, but other language runtimes shouldn't have to go through C and re-live all its problems.