Alexander Monakov
I still think that in C and C++ (additions to) standard libraries should be just for things that cannot be properly implemented without coordination with the compiler.
Likewise, "breadth" of the stdlib is not a strength of the language, nor where the main weak points are.
Martin Uecker
@ignaloidas @wolf480pl @amonakov I wonder what I should think of "C is shit at managing dependencies". C does not manage dependencies. I also happen to think that it is not at all its business to manage dependencies. But somehow the idea came up in recent years that programming languages should become frameworks doing everything....
Ignas Kiela
@amonakov@mastodon.gamedev.place @wolf480pl@mstdn.io With how shit C is at managing dependencies, this route would be bound to end up with 15 different socket libraries in wide use
I see zero reason to duplicate wrapper code over a million different programs besides stdlib maintainers trying to discard responsibility for stuff where a single canonical source helps the entire ecosystem.
Alexander Monakov
@wolf480pl I'd say they can be a part of a normal library, not something the language committee needs to be concerned with. And how easy it's to write and maintain _is_ a strength of the language.
Wolf480pl
@amonakov what about things that cannot be implemented in a portable way (like stdio, file io, sockets, etc) ?
Martin Uecker
@ignaloidas @wolf480pl @amonakov Sure! The whole mess of most coffee places selling bad coffee is just because ISO C does not standardize good coffee. It is all C's fault!
Ignas Kiela
@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place look, the whole mess of 15+ completely different distros each with entirely different package management system is entirely because C is shit at managing dependencies. Every single larger unix package manager is built for managing C dependencies, and they are all different kinds of shit. I'd rather get one singular package manager for a language, even if it's not great, rather than 15 different ones, when all of them are shit.
Haelwenn /элвэн/ :triskell:
Haelwenn /элвэн/ :triskell:
Wolf480pl
@ignaloidas @amonakov
NSS
GnuTSL
OpenSSL
LibreSSL
BoringSSL
WolfSSL
mbedTLS
AWS-LC
did I miss any?
Ignas Kiela
@amonakov@mastodon.gamedev.place @wolf480pl@mstdn.io I mean, sockets are in libc, aren't they?
and TLS is the kind of thing that ends up mostly getting replicated because of how much work it takes - but even then, there are multiple TLS libraries these days, with a couple different interfaces, some more compatible between them than others.
Alexander Monakov
@ignaloidas @wolf480pl Language committees never concerned themselves with sockets, and we didn't end up with such explosion. We also do not have a multitude of libraries for a simple TLS-wrapped socket abstraction.
Martin Uecker
@ignaloidas @wolf480pl @amonakov I am not sure "experience" is the right thing to optimize for and I think the amount of code reuse in C projects is usually fine. I think most other frameworks overdo it. This may be convenient, but leads to fragility and security issues.
Martin Uecker
@ignaloidas @wolf480pl @amonakov Distro package managers were not build for C. I am ok with using libraries and my experience with other languages is not good. But I am also rarely want to use random library X from the internet. But in this case, vendoring it is not worse than what others do. I agree it is much more limited and convenient as there is no widely established automatic way to pull in countless other dependencies in this way. I still tend to believe that this is a good thing.
Ignas Kiela
@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place The system's putpose is what it does. Distro package managers do OK with C and are quite shit with anything else. You can of course try managing non-C things with it, but just like trying to manage non-Python things with Conda, it isn't a good experience.
This fracturing of dependency management has lead to way lower code reuse in C programs compared to other programming languages and is essentially only left for stuff that is "too big to not reuse". I don't think this is good.
Ignas Kiela
@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place Distro package managers fail for other languages because they are only built for C
It's fucking miserable to reuse code in C - you either vendor it (which is shit), or hope to hell that the code you want to reuse is common/simple enough to be included in most distros, or otherwise your program will be a massive pain for end users to install.
There are a good bunch of C libraries that are better packaged as a part of Python libraries than by themselves in distros.
Martin Uecker
@ignaloidas @wolf480pl @amonakov It also not really true that package managers are build for managing C dependencies. They try to manage all kinds of software dependencies. It somewhat works for C but fails miserable for other languages.This is why - in addition to my system python packages - I have five "environments" lying around, all incompatible, all a security risk, ...
Wolf480pl
@uecker @ignaloidas @amonakov
trick question:
how much time does each of you (Martin in C, Ignas in Python) spend checking whether the library authors promise backwards compatibility, security updates, and whether they're likely to still be around 3 years from now?
Martin Uecker
@ignaloidas @wolf480pl @amonakov I write C code every day. The "barrier" to adding a library via a package manager is very small. There are plenty of libraries in any Linux distribution offering data structures. I do not really see a problem here. The cost of adding libraries is higher, but not only in C, but in every language. It takes me maybe 30 second to add a library.
Ignas Kiela
@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place look, I'd rather have security issues all in a few, frequently used pieces of code, rather that sprinkled and copy-pasted around the entire ecosystem of re-written code. One is at least simple to definitively fix, while for the other, you fix the same damn problem in 20 different projects over several years.
Also, "code reuse in C projects is usually fine" is laughable. How many separate linked list implementations have you seen in C. Do they all need to be separate? Is re-writing yet another linked list implementation a good use of time? And this is just a single data structure. There's tons of similar stuff that's re-written time and time again because the barrier of entry for adding a library is massive, and the standard library is laughably small. C the language is not very amenable to code reuse, but add the pain in the ass that is adding some libraries to do said code reuse and you get a language where code reuse is almost the option of last resort.
Like, in Python, pulling in a library to save ~10h of work is "the right thing to do". In C, the breakpoint is somewhere over a 100h in my opinion because of how annoying it is to maintain the whole pulling in stuff.
Haelwenn /элвэн/ :triskell:
@ignaloidas @wolf480pl @amonakov @uecker Well most could also just consider using <sys/queue.h> (4.4+ BSD, GNU, included in libbsd, musl systems typically also have it, …) when it comes to linked-lists.
Ignas Kiela
@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place now try something that isn't a popular library that all package repos have 😉
And like, anecdotally, rougly 1 out of 3 C projects have their own linked list implementations. Sure, you can pull it in from a library, but it seems like few people do and would rather re-implement it themselves.
Martin Uecker
@wolf480pl @ignaloidas @amonakov BTW: I just tried this with glib-2.0. Installing the dev package, adding the config via pkg-config, and using a linked list from that library did take me 30s. The idea that C devs code their linked list because it takes 100h to pull a library is just an absurd idea.
Wolf480pl
@ignaloidas @amonakov @uecker
> node
> long-term maintenance
Cotation needed
Ignas Kiela
@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place and the long term maintenence cost is higher than in other languages because of poor package managers. If long-term maintenece cost of added libraries in Node.js were as high as in C, regular projects wouldn't have hundreds of dependencies.
Martin Uecker
@ignaloidas @wolf480pl @amonakov Your points were that distro package managers are so bad that it is a pain to use a package and that even adding a linked list is difficult. Before going on, let's first agree that both the points are plainly wrong. The reason C projects have their own linked list is that the long-term maintenance cost of adding a library just for this is usually not considered worth it relative to writing something as trivial as a linked list.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.