So this is obvious bait, but the author's argument is the same regardless of which language you want to use. (Like I said above, it even applies to C itself.) Rust happens to be one she has actually worked on, but its hodge podge of features and package manager are unrelated to the ABI issue, which it's pretty clear she does understand.
It isn't any kind of bait. And libfortran makes direct syscalls, making the author's argument flawed and lack of insight obvious, at least to me. The syscall interface is not C, if you look at the generated assembler code, the only artefact remotely related to C is pushing the arguments on the stack before making a jsr or a call instruction (and some languages, like for instance C, have the reg directive, which puts the arguments into processor registers, making the system call nothing more than a jsr, call, or trap instruction). That somebody actually believes it's C tells me that they don't know what's happening under the hood; it would certainly not be prudent to take what someone like that says for granted. It's the blind leading the blind again, as is often the case here. She did not grasp that the system calls are only documented in terms of C for convenience and that the generated assembler code has nothing to do with the documentation convenience. She would have known that and would therefore not have made the argument if she understood how the underlying hardware works and how to program it in assembler...
If she had had the requisite insight, she would have for instance known about programming the Commodore Amiga or the ATARI ST (among other platforms): if she had looked at the API's there, they are documented not only in terms of C (and explicitly for convenience), but primarily in terms of assembler. The Amiga System Programmer's Guide is an excellent example.
So again: this is all about arguing for Rust, in bad faith, due to lack of breadth and width of insight. Toxic for our industry at large. If she (or anyone else) is going to argue such subject matter, she (or anyone else) needs far more knowledge, experience and insight than she currently possesses...
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.
What you claim is technically impossible: there is no way to stop someone coding in assembler from making a kernel system call.
I am absolutely arguing against Rust because it’s a horrible language and even if it weren’t it’s not as ubiquitous as C or Fortran. Rust is absolutely toxic for the industry but especially so are the people who promote it.
If you make syscalls against a backwards-compatible kernel API, nothing will break. One just needs to know how.
> there is no way to stop someone coding in assembler from making a kernel system call.
Take a look at OpenBSD, then- if you make a syscall from any language at all, but it's not from within libc, the kernel will simply kill the process: https://lwn.net/Articles/806776/
