As someone who works in C, C actually needs less in the standard library. What it actually needs is a proper import/module/build system to make it easier to stitch code and librarys together. The prevalence of header-only librarys attests to what a total mess it all is.

A proper import system would massively reduce the amount of wheel reinventing because then it would not be fiendishly difficult to actually reuse code in a coherent way. Only after that does it make sense to start quibbling about what is included where and by default.

I'll second this. The biggest thing I think C needs (besides what the author of the linked article is saying) is proper namespaces and modules. It holds the language back so much.

Tagged union types would also be really, really nice.

I've come around to the idea that first class types, tagged unions, and boxing and unboxing phat pointers would improve the language immensely.

Also the standard lib and POSIX reminds me of a homeless persons shopping cart full of precious stuff they picked off the street.

It is against the rules to talk about voting, but anyway.

It is almost a meme here, that, on any mention on C and C++, there will be people contributing comments: 'but Rust ..'.

If the mention of word "Rust" for you will invalidate the entire comment, you just have a bias.

> Arguably the needs of the standard library of a language designed in the 70s compared to today are very different.

C supports modularity since the 70s. You do not need a standard library with everything and the kitchen sink. The standard library is not the only component you're able to consume.

If there's a lesson from high level languages such as python and node.js, it's that being able to consume third party libraries is all anyone needs to get stuff done, and standard libraries bring convenience to the table but they aren't critical to get stuff done.

> C supports modularity since the 70s.

I think today we understand more about what a language needs to provide to enable modularity. One issue that comes up over and over with interoperating libraries is confusion around ownership. If you pass a char* to me, do I own it now? Is it my responsibility to free it? Or is it just a short-lived reference to data that's still yours? Garbage collected languages can kinda sorta sidestep these questions, at least with memory-use-after-free, and they're more likely to tolerate the costs of immutable data structures and defensive copies. But in C this question is critical, and we screw it up constantly, especially at the interface boundary between libraries. C++11 does much better, with first class support for moving ownership through a function call, and Rust goes further with lifetimes and the borrow checker.

Another point that's kind of in the weeds is the atomic memory model, which C didn't have until 2011 (and I think C++ gets most of the credit here for formalizing it). I'm still waiting for proper support for C11 atomics in MSVC. Multithreading has been ubiquitous for a while, and while it's possible for an application to decide that everything's going to be single-threaded, that's not an option for a portable library. Without standard atomics, you have to resort to platform-specific extensions to do basic stuff like initializing globals.