4 ms·
TBH, most of the C stdlib is quite useless anyway because the APIs are firmly stuck in the 80's and never had been updated for the new C99 language features and
by flohofwoe 2y ago
TBH, most of the C stdlib is quite useless anyway because the APIs are firmly stuck in the 80's and never had been updated for the new C99 language features and more recent common OS features (like non-blocking IO) - and that's coming from a C die hard ;)
- ryandrake 2y agoI don't think everything has to be "modernized" and "updated." When I look at software from the 80s that is still with us, I think: "This is robust, keeps working, and has withstood the test of time" not "This must be changed." I still use C and the standard C library because I know how it worked in the past, I know it works today, and I know it will work for decades to come. (minus the known foot-guns like strcpy() that we learned long ago were not great)
- turndown 2y agoThis is all well and good, but just because something came from before doesn’t mean it was a good idea then, or especially now. You’re basically citing survivorship bias. Of course something still used from the 80s is well made, otherwise it would have been replaced 30 years ago.
- epcoa 2y agoMost of the networking stuff from the 80s at least wasn’t particularly well made, it’s just been maintained and significantly reworked to not have massive security vulnerabilities.
- fluoridation 2y agoI don't think any of the networking stuff from the '80s dealt with security in any way. We're talking transport layer stuff.
- epcoa 2y agoIn contrast when I see software from the 80s that is not a security and performance disaster it’s because of continued investment and most of the basics like string handling have been replaced with bespoke or third party libraries and IO heavy lifting is done with OS specific interfaces anyway.
- pjmlp 2y agoI on the other hand, as a 1970's child, using computers since the 1980's, see people stuck in the past and old ways.
- jandrese 2y agoYou can do nonblocking IO using the C std library. Poll and select have been in there for decades. They are even in POSIX.
- ryandrake 2y agopoll() and select() are POSIX-isms that are not necessarily going to be present in every system's C standard library. The only reason they happen to be available on Windows is that Microsoft, in an uncharacteristicly freak stroke of respect for existing standards, decided to make WinSock (mostly) function-for-function compatible with BSD sockets.
- jandrese 2y agoIn practice poll and select exist everywhere it makes sense. There aren't a ton of independent Unix vendors each with their own expensive and broken C implementation running around anymore. Both are available if you use --std=c89 on gcc and clang. At this point it is safe to assume they are available unless you're doing something weird like writing C for some tiny microcontroller. Practically speaking this has been true for at least 20 years.
- flohofwoe 2y agoUNIX isn't the only operating system in the world though, a lot of C programming happens on Windows with MSVC (or embedded platforms, or WASM).
- whiterknight 2y agoBlocking IO is usually good though. The entire Unix kernel is designed to manage complexity so you can write “if then else”. What is grep going to do while it waits for data?
- flohofwoe 2y agoYou are right in that the C stdlib is mostly useful as an SDK for writing simple UNIX command line tools. But for other things it's better to go down to OS-specific APIs or up to POSIX (if a POSIX environment is available) - which isn't a great deal to be honest. One of the greatest features of C is that it doesn't depend too much on its stdlib.
- whiterknight 2y agoThat’s not what I said. Everyone benefits from being able to read and write blocking code.
- pjmlp 2y agoSince C11 not depending too much on its stdlib is kind of relative.
- comex 2y ago> What is grep going to do while it waits for data? Two things: - Search the data it’s already read in. If data is coming in fast enough, it’s better to read and search in parallel rather than alternating. - If this is a recursive grep, then list, open, or read from additional files. Even so, thread pools work fine for this kind of thing. An optimized grep already wants to use threads to split the CPU work into parallelizable chunks (where helpful), so using threads for syscalls too shouldn’t make much difference. However, for recursive grep, you might need to open large numbers of small files, in which case syscall latency might be a big enough factor that something like io_uring would be significantly faster. Disclaimer: I’m mostly thinking about tools like ripgrep that are only grep-like. I’m not aware of any actual grep implementations that use parallelism to the same extent. But there’s no reason a grep implementation couldn’t do that; it’s just that most grep implementations were written in the age of single-core processors. Also note that I don’t actually know much about ripgrep’s implementation, so this post is mostly speculative.
- chipdart 2y ago> TBH, most of the C stdlib is quite useless anyway because the APIs are firmly stuck in the 80's (...) This. A big reason behind Rust managing to get some traction from the onset was how Rust presented itself as an alternative to C for system's programming that offered a modern set of libraries designed with the benefit of having decades of usability research.
- LawnGnome 2y agoCompletely agreed. My Rust origin story wasn't about memory safety, fearless concurrency, a modern type system, or anything else like that. Not that I didn't care about those things — I did — but none of them were what convinced me to start learning Rust. What did convince me was being able to prototype things for the C project I was working on while having access to a standard library that included basic data structures, synchronisation primitives, and I/O handling in a way that used best practices from recent decades. Everything else was just a bonus that I got to learn and use as I went.
- nxobject 2y agoTruth be told, I wouldn't mind crowdfunding an alternate stdlib for C for that reason. Everyone has a wishlist of patterns discovered after K&R bestowed upon us System V, that mesh perfectly well with C's philosophy and very minimal environments, and make modern programming much easier when you're dealing with lots of dependencies. (e.g. bounded strings/small strings, arena allocation, error chaining/coalescing, etc..).
- pjmlp 2y agoAlmost many of those benefits were already present in Modula-2, Ada, Object Pascal, among others. Unfortunely they came up when UNIX and C were the cool kids on the block, and who cares about a buffer overflow or a few miscompilations due to UB, any good coder is going to get them right anyway, no need for straighjaket programming languages.
- fsckboy 2y agoC became big not because of unix, but because starting in the 1980's the personal computer with small memory and impoverished operating systems quickly became the biggest market to write software for. Then the biggest player, Microsoft, was more interested in being proprietary and uncompatible which stood in the way of standard libraries. Unix became big when the web became big because of servers.