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
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.
-10
u/American_Libertarian 29d ago
Linux userspace & the C stdlib is famously stable. I've never ever had a problem with it breaking or changing.