Absolutely bait, and I'm falling for it. The author knows that you can make syscalls from assembly, directly in terms of the ABI those syscalls use, and trying

Absolutely bait, and I'm falling for it. The author knows that you can make syscalls from assembly, directly in terms of the ABI those syscalls use, and trying to frame this as some kind of misunderstanding is absurd. You are willfully misreading the article. Not to mention, your continued obsession with syscalls is itself missing the point: For one thing, this is about more than syscalls. Many interfaces (e.g. userspace shared libraries, VDSO) are documented and implemented purely in terms of C and ABI the platform uses for C, not just as a convenience. For another, many platforms actually do specify their kernel interface purely in terms of C and their C ABI, and do not have a supported way to make syscalls that does not go through such an interface- some kernels will refuse any syscalls that do not come in through their libc; others change their syscall ABI every release and ship wrapper shared libraries for userspace to use. That some platforms do support direct syscalls does not change this. (This also means that libfortran making direct syscalls will break on these platforms, as Go did.) Your behavior here is what is toxic for our industry. It is quite clear that the article is describing a real issue (over-reliance on "C," which is, as typically used, a shorthand for "C plus the platform's C ABI," which is itself poorly specified and poorly followed) but you are twisting it into some weird axe-grinding vendetta against Rust, and completely making things up about the author in the process.