Fil-C now has support for inline assembly, so it's not needed anymore, and I believe indeed the intention is to remove it, since Fil-C is not supposed to have any unsafe hatches.
Fil-C is not Linux only by design, that's completely false.
By the way, if you don't want a culture war, you gotta stop warring.
I find it hard to understand how could steveklabnik's comment be seen as warring.
See, this is nuance! Nuance is good! But you can't go around saying "fil-c has no escape hatches" when it has one, even if that one is planned on being removed.
> Fil-C is not Linux only by design, that's completely false.
Can you explain to me how it would work on other platforms? It currently does not, and I don't see how it can. Or at least, not without more "escape hatches."
This is one reason why Rust has unsafe: you have to interact with inherently unsafe APIs in order to do anything meaningful with the operating system. fil-c needs an equivalent of some kind, and so isn't better or worse here, it's just the reality of how these systems work.
Just to add to this, on Windows for example you're really only supposed to invoke syscalls via ntdll as the syscall table is not stable so their numbering changes over time. You cannot guarantee forward or backward compat if you do not use the library.
If you look at some of the syscalls in https://github.com/j00ru/windows-syscalls, you can see they clearly do change over time too.