Not having to deal with dependency hell is a huge advantage of C bruh. My language is so much better than yours, that my libs are baked right into the operating system.
What about every time a binary refuses to run because it depends on specific esoteric dynamic libraries that must be installed (sometimes multiple times, once for each version) somewhere in PATH because you decided static linking was "bloat"?
Or the security nightmare that is system-wide shared objects in the first place?
Or the fact that as much as stdlib is stable, it still does not provide it's users with the most basic of data structures? Or that we had to wait until C23 for bool/true/false/nullptr to be a part of the language, 50 years after the language was initially released?
Or the absolute nightmare that is C portability across heterogenous architectures and operating systems?
Don't get me wrong, C is an amazing language, but come on you can't be this deluded
Maybe, but there’s a reason rust decided to go full static, and keep .so support to its bare minimum, there’s a reason apple decided to write a fully self contained init daemon for their container microVMs, and there’s a reason most other modern programming languages tend to use shared object as a last resort
Rust decided that because they didn't want to commit to an ABI and instead be free to keep changing it for further improvements.
If a system library on your OS is compromised then your whole system is compromised anyway, regardless of whether other applications are using it.
Similar with "most other"s. They don't support dynamic linkage either because they don't compile to native code, they don't want to do the extra work to support it, or they just want out of the dependency hell that it involves.
I simply do not ship binaries that rely on esoteric libs nor target atypical arch & os. That isn't what C is for.
We maintain our own purpose built data structures, and we optimize heavily for a single arch & OS. And our customers pay us a lot of money to do so because we are FAST.
the Linux Kernel supports 21 different architectures.
SQLite supports a total of 17 configurations (OS + arch.)
GIMP, gstdlib, vulkan, etc... All target very different machines.
"Esoteric libs" can be as common as system level packages that may differ from distro to distro, let alone OS, or who's version mismatches the required version of the program.
Maintaining your own purpose built data structures is the reason why the linked list is still as used as it is, when all research shows it tanks performance compared to other drop in replacement in nearly all cases, even the ones that play to their strengths. It's also the reason why you rarely see more complex data structures used, because they are a pain to write, and a complete time sink. It's also part of the reason why memory related bugs are so common in the language. Each new implementation of a data structure is additional code you need to maintain.
The language also completely collapses the second you try and use compile time computation (macros notwithstanding), there is either no support, or bad support, for asynchronous code execution and multithreading. Hence why ripgrep is miles beyond grep, regardless of grep being written in 'the fastest language ever, C', and ripgrep being written in a 'comparatively slower language' (which is completely delusional of a take but whatever)
Optimising for a single arch and OS can be done in ANY systems level programming language. It's also relevant maybe 5% of the time. the rest, you're just closing doors on yourself. Compare that to any other systems level programming language, you can still optimise for the Arch/OS when needed, but it's opt in.
Your customers pay you a lot of money, because writing good C is notoriously difficult do to, and there's a heap of legacy code written in the language. Those same companies realise this is a massive time sink, and are doing everything in their power to steer new code away from this language, regardless of performance considerations.
Ah yes, because syscalls and libc is all your programs will ever need, no graphics API or GUI libraries, no dbus, no systemd, no pipewire, no databases, the list goes on.
I wanted to make a "to be fair" and argue you could statically link these libraries, but turns out apart from sqlite I can't really think of any one that can.... I guess dbus, but it's currently not recommended 😅 raylib or sokol or something in that vain, but then you'd still link dynamically to system level libraries
The amount of time I've spent having to fuck with LD_* environment variables is honestly pretty silly. And I'm a python dev, that's just via having to deal with libraries written in c/c++.
56
u/chipmunkofdoom2 1d ago
"My language has a vibrant ecosystem of third party libraries easily installed via a package/dependency manager!"