Administered by:
@ipg nah fuck c lmfao, there's absolutely no reason to cling to it other than sentimentality
asm makes sense as a direct representation of machine code, it's not like there's any other way to do it, but C is just another high level language (albeit a very old and influential one)
@lanodan@queer.hacktivis.meWhich is why the core of your favorite Java/Go/Rust/… stuff is still C, and ffmpeg is pretty much a core library.
Linux has a stable ABI for userspace (mostly), so it is possible to even do the whole thing from scratch and communicating directly with the system that way, skipping C entirely. In general instead such languages deem it simpler to make a C wrapper which can communicate with their own ABI instead.
@lanodan@queer.hacktivis.meBut if you want portability… nope.
https://utcc.utoronto.ca/~cks/space/blog/programming/GoCLibraryAPIIssues
https://utcc.utoronto.ca/~cks/space/blog/unix/CLibraryAPIRequiresC
And sadly the Linux kernel isn't the only ABI you need to care about, like if you do OpenGL/Vulkan/… you'll end up with having to deal with C.
(And there's core system libraries that are very security-sensitive like the nsswitch.conf stuff and pam where it's stuck to C)
@lanodan @halva @ipg What do you mean by core here? Neither Rust nor Go have a C core as I would understand it. Not like the typical Java runtimes do (or Haskell).
Rust will link to libc et a on Linux, but that’s an artifact of how “std” support is added, an alternate “std” could target the Linux ABI directly, and x86_64-unknown-none (which does not have the std crate) links in no C.
Go produces static binaries by default, with no C code linked in at all.
If you’re talking about applications and libraries written in those languages… both have cultures of implementing as much as practical in the language itself. For example, the fuse library for rust [lib.rs] only calls to C for mount/unmount (which requires system specific elevated privileges).
@halva writing in assembly does not make sense in a cross-architecture world - C acts as a higher abstraction onto that without abstracting core behaviours away from you as a programmer
it's not high level by any means, for any given C code you can fairly trivially understand what it gets compiled down to when you build it and you don't have to guess at what it could be doing in the background
what you write is what you get, it hides nothing from you
@ipg @halva The other day, I stumbled upon an article which nuances the idea of C compiling down to something obvious:
C Is Not a Low-level Language
https://queue.acm.org/detail.cfm?id=3212479