Putting aside the personal jab, which the other comments have rightfully called you out for (really, this is why people detest “the orange site”) you’ve just fundamentally misunderstood the point of the blog post.
C is kind of a horrible way of specifying machine interfaces, because it tries to lift things into being portable when the interface is anything but. The ABI is what ties C to the specific machine interface that it’s exposing, and in doing so dooms the ABI from ever changing. The article has many, many examples: a simple one is that it’s stupid to expose a 32-bit value as an “int” because that means “int” needs to be 32-bit forever. In this sense providing a C API is bad because the interpretation of the API into ABI is dependent and on your tooling and sometimes even that doesn’t agree, with fun™ results. This very much isn’t a request for “please give Rust a nice interface to the kernel” but more a “there ought to be something better than having to run libclang just to talk to the kernel”.
So what do you suggest instead? Express APIs in yet another language (perhaps one with defined-length numeric types) other than the ones people actually use? An IDL? Who's going to do that work, from the definitions themselves to the bazillion language-specific bindings? I'm not saying that you should have to have an answer before you can criticize, but every solution to this particular problem sucks in some way. Some things are just hard. Jumping on a bandwagon to tear down something that already exists, ignoring or trivializing any problems it does solve or that alternatives would need to, is another much-despised Orange Site behavior. Nobody ever turns out to have a real silver bullet in their back pocket.
Well, you can tell why the orange site put it on the homepage, right ;) But to respond in seriousness: yes, the blog post exists to mostly highlight a problem, and it doesn’t have an easy solution. But there’s a couple things you can do to help: one is to define a sort of “restricted C” that is easy to parse and designed to be ABI stable, which I think Microsoft actually tries to do. You could use some sort of IDL, yes: web browsers do this for their “system interface”, and as ‘olliej mentions so does Fuchia. But the main point is to shed some light on the issue to start a discussion, because until now people have mostly been OK with defining everything using C and it’s been causing problems that nobody’s really thought about trying to solve, and I think the post does a pretty decent job of that.
C is kind of a horrible way of specifying machine interfaces, because it tries to lift things into being portable when the interface is anything but. The ABI is what ties C to the specific machine interface that it’s exposing, and in doing so dooms the ABI from ever changing. The article has many, many examples: a simple one is that it’s stupid to expose a 32-bit value as an “int” because that means “int” needs to be 32-bit forever. In this sense providing a C API is bad because the interpretation of the API into ABI is dependent and on your tooling and sometimes even that doesn’t agree, with fun™ results. This very much isn’t a request for “please give Rust a nice interface to the kernel” but more a “there ought to be something better than having to run libclang just to talk to the kernel”.