But none of that supports the assertion that C makes it hard to use good libraries. You can even use libraries not written in C if you want.
If the argument is really "it's impossible to make a good library in C", that's different. I'd very much disagree with that, but it would be to the point.
I'm saying "it is harder to consume good libraries in C, because it is harder to find them & harder to build them; and once you have done both, you find that good library A and good library B work in very different ways, so you have to do more work to adapt".
And I haven't mentioned the lack of a strong universal string type, the way many libraries typedef their own family of different kinds of integer, the way one library will require you to free() a returned structure and another will require you to call my_library_free()...
It all adds up to additional friction.
You don't have to agree! Maybe I am out of date, I haven't really dealt with this since the mid 2000's. I'd be thrilled to hear this isn't an issue any more.
It's not really a matter of whether or not I agree. I was just trying to understand what the assertion was!
I was baffled by the notion because I couldn't think of anything inherent in the language that made it hard to use good libraries. Now I understand that's not really what the assertion was.
The original assertion was about difficulty of using C libraries in the kernel or bootloader. In the bootloader you're the OS. There's no file system, no dynamic linker, and no processes. There's no guarantee some third party library will work in that environment. It might but it's work to make sure it does or adapt it if it doesn't.
Let's say you want to develop a CLI tool in C for crawling a website's sitemap.xml as advertised by the website's robots.txt.
How would you approach this development in C?
With e.g. Java, Javascript, PHP, and Python it's clear to me.
If the argument is really "it's impossible to make a good library in C", that's different. I'd very much disagree with that, but it would be to the point.