https://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
Discussion
Loading...
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
@mjg59
Any examples around of good, language-interoperable ABIs around? Or has C sucked all the oxygen out of that room?
@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.
@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
1+ more replies (not shown)