3 ms·

I think what a lot of people don't realize is that, at least if you're writing Unix userspace code that mostly interacts with POSIX and/or kernel-specific inter

I think what a lot of people don't realize is that, at least if you're writing Unix userspace code that mostly interacts with POSIX and/or kernel-specific interfaces, C remains the most convenient because the API/ABI standards are all designed with C semantics in mind, and a lot of wrapper/binding libraries in other languages are either too clunky or too abstracted, unless you decide to roll your own... and depending on the language, FFIs can be quite a nuisance. The only languages so far that seem to have really gotten this are Go... and OCaml, to some extent (see the "Unix system programming in OCaml" document). Go in particular bypasses libc entirely by directly using the syscall interface, from what I recall.

jjoonathan 12y ago
> FFIs can be quite a nuisance Understatement. Every time I've tried to use a FFI I ran into either a show-stopping bug or a show-stopping feature limitation. My first few open-source contributions were patches for these bugs, as it happens, but the whole process was a massive slog that ended in repeated failure. I now loathe them with a passion. Still, this all happened before LLVM-languages came around. Maybe things are better now. I look forward to the next time I have to use a FFI with both hope and fear. > Go in particular bypasses libc entirely by directly using the syscall interface That's nifty, but a big chunk of the reason for having C compatibility is that many higher-level libraries are written in it. How easy is it to talk to, e.g., the window manager using raw syscalls?