Matthew Garretthttps://faultlore.com/blah/c-isnt-a-language/ deserves a fucking record for managing to trigger people into being extremely upset while also demonstrating that they don't understand the actual point being made
Chris 🇺🇸🇦🇺🏴It doesn't matter whether C is good or not. It matters that if I write code in two languages that aren't C, and I want it to all be part of the same process, I need to care about C. C pervades all. You cannot escape it. C will outlive all of us. The language will die and the ABI will persist. The far future will involve students learning about C just to explain their present day. Our robot overlords will use null terminated strings. C will outlive fungi.
"But C++ libraries" motherfucker I did not live through the C++ ABI wars of the 2000s to have people tell me with a straight face that C++ will be interoperable 1500 years from now, but I would wager a lot of money that whatever software they're building then will be able to call into libglib.so
Janne Moren@mjg59
Any examples around of good, language-interoperable ABIs around? Or has C sucked all the oxygen out of that room?
Any examples around of good, language-interoperable ABIs around? Or has C sucked all the oxygen out of that room?
Florian Gilcher@jannem @mjg59 One of my employees actually wrote her masters thesis on the subject and ended up at "it's the lowest common denominator we can express in each language, so a replacement will be hard or very language-pair specific". She ended up at concluding that it's okay right now and there's bigger fish to fry.
Michał Fita
Ype Kingma@michalfita @skade @jannem @mjg59
Move semantics, elephant in the room, ...
Federico Mena Quintero@skade I'd love to read this... do you have a reference?
Ruchira S. Datta
ArneBab@jannem @mjg59 that’s a good read. Thank you for sharing!
Also: I now hope much more that C stays around.
Because xcb tried to establish a different path. A machine-readable protocol definition that Guile actually used directly to create bindings¹. But xcb hadn’t even reached widespread adoption when Wayland broke it.
So one reason why C is around is that C stayed around. And seeing the lifetime of xcb, attempts to replace C bindings give me more worry than hope.
Jamey Sharp@ArneBab @jannem @mjg59 As the author of XCB, I'm a lot more optimistic about that particular story. I do wish more people had migrated Xlib-based code to use XCB directly, and it's unlikely to happen now since most new development is going into Wayland; that's all true. But:
- Wayland adopted machine-readable protocol definitions directly from XCB's example, and can do it better because it doesn't have to be compatible with a protocol from the 1980s. The idea lives on.
- Back when people were still working on X, XCB's declarative protocol descriptions allowed people to prototype new extensions more quickly, making it easier to respond to new requirements. Wayland developers are still making excellent use of this advantage.
- While Xlib has had a steady stream of CVEs, XCB has had only one CVE in its entire 25-year history (last I checked), and it was in the couple thousand lines of hand-written code. Mechanically generating all the protocol bindings turned out to be fantastic for security and reliability.
- Those descriptions are useful for so much more than just client-side language bindings: Wireshark protocol dissectors, documentation, etc.
In the context of FFI, there are lots of examples of equivalent ideas. I like IDLs in general, and the WebAssembly Component Model as a specific case study. We have alternatives to relying on C as the least common denominator for cross-language interop, if we choose to use them.
@jamey It’s not the approach of xcb I dislike, it’s the volatility of the infrastructure.
xcb solved the latency problem of X11 and the protocol description made it possible to build a solid API in Guile by creating a language parser that uses the description directly as code.
But Wayland broke tools using it by not preserving compatibility, so now that API can’t be used anymore.
While one idea lived on, they broke the most important concept from C: don’t break other programs.
@jannem @mjg59
@jamey Any new format that wants to challenge C headers must provide stability.
Otherwise programs using it will die frequently when the API they use changes and the original dev no longer has as much time as during original development.
I like the idea xcb championed, but as long as those using it embrace volatility (just one more breakage, promised!), sticking to C bindings will be a more future-proof strategy.
@ArneBab @jannem @mjg59 I'm not going to disagree with your general conclusion: I agree that if you want cross-language function calls, you need a way to do it that's going to stay pretty stable over time. (Although, as the original essay points out, C headers do not provide complete stability either.)
But I will say that invoking XCB is not an argument that supports your conclusion. If you hand-write Guile X-protocol bindings that use C FFI to call libXCB, what you get will not be better than what you could produce by using the XCB protocol descriptions. You'll still have an X protocol client, and that still won't let you talk directly to a Wayland compositor!
@jamey My point is: I loved how XCB did it.
The problem that causes newer approaches to actually bring more problems than benefit is not that they aren’t better. (sorry for the double negation)
It’s that they aren’t given the time to get sufficient adoption because the time between breaking infrastructure changes is shorter than the time needed to get wide adoption, so every new approach will worsen the fragmentation.
(I need to find a clearer way to make that point)
1/2
@jannem @mjg59
@jamey As long as a philosophy of breaking stuff pervades free software infrastructure, a new communication description can’t spread widely, because the new tools using it get broken again before the new way is established, so C remains the one that works for most tasks.
So: I loved how XCB did it. But the ones who committed to it (guile-xcb) got the short end of the stick, because their work was destroyed by infrastructure changes that didn’t come from xcb but still hit.
Demi Marie Obenour
prozacchiwawa
sarah tonin 
Steve Syfuhs@mjg59 I briefly thought this was ridiculous and then I remembered the apocryphal story about missiles being the diameter they are because that's how wide trains are which are that wide because track gages because that's how wide cart wheel bases are because the Roman road network.
mittelgeek@SteveSyfuhs @mjg59 An Electrical Engineer I used to work with told me that the reason why lanes are that big is because that is the width of two horses' asses. 😄
jandi@mittelgeek @SteveSyfuhs @mjg59 Curious. Here's a link: https://www.tastesofhistory.co.uk/post/dispelling-some-myths-romans-railways-and-nasa-rockets
Dispelling Some Myths: Romans, Railways and NASA rockets
Yet another urban myth re-appeared on social media the other day, one which regularly does the rounds and has done so for many years since about 1937. In essence a series of connections are made to establish that the huge solid rocket boosters used by NASA had to be transported by rail whose rails were set a certain distance apart, a standard width first determined by the ancient Romans. The historical connections espoused are tenuous at best and do not really stand up to critical thinking. So,
Jens Finkhäuser@mjg59 /me fondly recalls that paper from Drepper from 20 years ago.
Aaaanyway the point that C is a protocol is very true.
But the flip side to that is: there are no pervasive cross-platform, multi-language protocols other than it.
If you e.g. see WASI as an attempt to rectify this, for one it's basically XKCD 927 (https://xkcd.com/927/).
But even if it catches on, an IDL based approach basically concedes that some underlying protocol is *forever*.
Might still be the practical way "out".
Kyle@jens @mjg59 I suppose the reason nothing else is as multiplatform is because C shapes platforms around it's features. If you come up with a radically different OS concept but then want to use C on it, your new OS is going to start looking a lot more like UNIX again. It's a great limit on people's imaginations
Mike Spooner@kyle_pegasus @jens @mjg59 And hardware too. Several new ISA architectures (and microarchitectures) developed since the mid-80s were deliberately structured to be amenable to efficiently hosting the C abstract logical machine. MIPS, SPARC, Alpha (to an extent), PPC, and plenty of others. Even some x86 microarchitectures have made several accomodations.
@alwayscurious @kyle_pegasus @jens @mjg59 A lack of stack-indexed addressing, no register-windows, only limited-range indexing offsets, mixed-size addresses, insufficient number of registers, single-purpose/special-purpose data registers, seperate address-spaces for different areas of memory, and so on, and so on, and so on.
LP still can't spell Ainmhícon@jens @mjg59 @kyle_pegasus something something that old paper about how fork() is terrible but shapes OS design if you need to support POSIX
(ah, https://www.microsoft.com/en-us/research/wp-content/uploads/2019/04/fork-hotos19.pdf )
@mjg59 I have a bunch of thoughts about that, half formed.
But I reference WASI also because it's one of those things with some potential on the one hand, but it fails for much the same reason other tech does: how it's actually supposed to work is well hidden.
The best I've gotten out of it is that it implies WASM is the new protocol to replace C, and for that specific purpose, it's a pretty flawed choice.
All they seem to write about it is the sugar on top.
Iris@iris_meredith Well sure but if you want anyone else to call them you're smashing on a shim to translate C strings because how else do I call you from Go
Gabriel Adrian Samfira@mjg59 @iris_meredith unless we also create a cffi alternative for Fortran (fffi?) and ftypes.
(I am old and lack a proper sense of humor. Going back under my rock now)
🐈⬛David Sommerseth@mjg59 @iris_meredith @gabriel
If you write all the needed functions the libc library provides into a language specific system library, you can escape a lot of C APIs, until you need to communicate with kernel ABIs. Then you're back at wrapping the language native APIs into a C ABI to be able to the syscalls.
And what will make it even more fun ... You'll need to do that for each single OS platform you want to support, to have something being portable.
This kind of stunts is something you only can afford to do on specialised embedded single purpose systems where you need to have as little code running as possible, to be able to fully audit all possible call chains - like in criticial secure systems for aviation or nuclear power plant systems and such like. It won't ever happen on general purpose systems at all.
We're basically stuck with C ABIs until the day someone is successful replacing it something new and better AND provide all the applications people need and want to use at the same time. It will be a revolutionary paradigm shift if someone is capable of pulling that one off. And I'm not holding my breath.
@dazo @iris_meredith @gabriel This is a great explanation of why we have ended up in this situation, but is not an assertion that it's the best outcome we could have had if different decisions had been made in the past.
@dazo @iris_meredith @gabriel And yeah I agree that given where we are it's what we're going to be stuck with forever, but sometimes it's nice to think about alternative futures
Fluchtkapsel@mjg59 @dazo @iris_meredith @gabriel I have an idea! Let's wrap all this ABI stuff in XML!
*runs away veeeerrrry fast*
@fluchtkapsel no no no it's 2026. you make your kernel requests over json+https
mxk@fluchtkapsel @sop you might be joking, but asm.js is the closest to an alternative interoperable ecosystem to native-c-abi 🫣
Mateusz 🏳️🌈@sop @fluchtkapsel C’mon, why would you have any of these cryptic languages/protocols/interfaces. All you need are AI agents talking to each other in natural language 😏
@dazo @mjg59 @iris_meredith I am a fan of cffi and ctypes. Saved my behind lots of times. The effort needed to replace it is untenable in my view and not sure it is worth someone spending the next 20 years to do it just for the sake of replacing things. At least not if it doesn't become some fundamentally limiting factor in software evolution.
Pardon the social awkwardness on full display in my previous comment.
Else, Someone
Mikalai@gabriel @mjg59 @iris_meredith
Is it just me? They say C FFI. I thought there would be other ones. Where are these XYZ FFFI's? If you need to FFI, your attention is on doing something, hence, you reach for existing one, ... C inspired/formed FFI.
Is it just me? They say C FFI. I thought there would be other ones. Where are these XYZ FFFI's? If you need to FFI, your attention is on doing something, hence, you reach for existing one, ... C inspired/formed FFI.
Je ne suis pas goth@mjg59 @iris_meredith not sure I understand the joke. If I write a subroutine called "f" in Fortran, I can call it from C using the name "f_" so the C ABI will still be obeyed. What did I miss? 😬
Ben AvelingTo call C from Fortran, Fortran needs to look a lot like C internally. And that's no big deal for Fortran, because Fortran does naturally look at the universe in a way that is a lot like the way C looks at the universe.
For other languages, languages that are less C-like, it becomes unnatural.
If I understand things, which is uncertain.
@jenesuispasgoth @mjg59 @iris_meredith
For other languages, languages that are less C-like, it becomes unnatural.
If I understand things, which is uncertain.
@jenesuispasgoth @mjg59 @iris_meredith
Jeff Grigg@BenAveling @jenesuispasgoth @mjg59 @iris_meredith
… aside from multidimensional arrays being in the opposite order between C and FORTRAN. 🙄
@BenAveling @mjg59 @iris_meredith @JeffGrigg
That one isn't that hard to adapt to. Just use linearized arrays! 😁
jwz@mjg59 Dooming us all to inhuman toil for The One whose name cannot be expressed in signed char.
Trammell Hudson
Albert CardonaHow I imagine the Fortran gods in their slumber:
https://www.scientificamerican.com/article/how-do-whales-and-dolphin/
Julien Goodwin
RevK 
@LapTop006 @mjg59 @jwz that sounds scary, can you summarise?
The only modification I had in any of my code was an two byte sequence that makes a null, which is technically not utf8 valid but works as a way to code a null in a C style utf8 string when needed.
@LapTop006 @mjg59 @jwz Wow, well I guessed the null, and in some ways it is a shame that is not valid UTF8 as putting a null in a string is hard, but it would mess sorting to do it that way. The lack of longer sequences, and hence using surrogates is, err, interesting.
But as @jwz says, Oh my god! (or someone's god)...