7 ms·

It’s weird how whiny this post is. Like there’s zero intellectual curiosity about why C got this way, and why C gets to be the foundation for how systems softwa

It’s weird how whiny this post is. Like there’s zero intellectual curiosity about why C got this way, and why C gets to be the foundation for how systems software is written. I could write a whole essay about why, but now isn’t the time. I’m just going to enjoy the fact that TFA and the author don’t get it.

ranger_danger 9mo ago
What is TFA?
- jagged-chisel 9mo ago
  The Fine/Fabulous/Fucking Article Choose your own adjective
  - SoftTalker 9mo ago
    Featured
  - leoc 9mo ago
    To further explain: it comes from 'RTFA' https://en.wiktionary.org/wiki/RTFA https://en.wiktionary.org/wiki/RTFA which was developed on Slashdot as a variation on 'RTFM'.
munificent 9mo ago
> why C gets to be the foundation for how systems software is written. Is there an answer here more interesting than "it's what Unix and Windows were written in, so that's how programs talked to the OS, and once you have an interface, it's impossible to change"?
- pizlonator 9mo ago
  Yes
  - munificent 9mo ago
    Care to share the answer with the rest of the class?
    - uecker 9mo ago
      I am not sure what Filip's view on this is. But like to point out the article from Stephen Kell linked below which explains why C is an incredibly useful tool for systems programming and what distinguishes it from all other languages. https://dl.acm.org/doi/abs/10.1145/3133850.3133867 https://dl.acm.org/doi/abs/10.1145/3133850.3133867
      - rramadass 9mo ago
        That is a nice article! Thanks for the pointer.
- jonjacky 9mo ago
  It wasn't a coincidence, or an accident. C was specifically designed to write Unix, by people who had experience with a lot of other computer languages, and had programmed other operating systems including Multics and some earlier versions of Unix. They knew exactly what they were doing, and exactly what they wanted.
  - munificent 9mo ago
    I'm not sure what you mean by "coincidence" or "accident" here. C is a pretty OK language for writing an OS in the 70s. UNIX got popular for reasons I think largely orthogonal to being written in C. UNIX was one of the first operating systems that was widely licensed to universities. Students were obliged to learn C to work with it. If the Macintosh OS had come out first and taken over the world, we'd probably all be programming in Object Pascal. When everyone wanted to program for the web, we all learned JavaScript regardless of its merits or lack thereof. I don't think there's much very interesting about C beyond the fact that it rode a platform's coattails to popularity. If there is something interesting about it that I'm missing, I'd definitely like to know.
    - heyitsdaad 9mo ago
      First to market is not necessarily the best, case in point: many video sites existed before Youtube, including ones based on Apple Quicktime. But in the end Flash won. To me it looks like there is a better way to do things and the better one eventually wins.
    - AnimalMuppet 9mo ago
      Repeating a previous comment of mine (https://news.ycombinator.com/item?id=32784959 https://news.ycombinator.com/item?id=32784959) about an article in Byte Magazine (August 1983) on the C programming language: From page 52: > Operating systems have to deal with some very unusual objects and events: interrupts; memory maps; apparent locations in memory that really represent devices, hardware traps and faults; and I/O controllers. It is unlikely that even a low-level model can adequately support all of these notions or new ones that come along in the future. So a key idea in C is that the language model be flexible; with escape hatches to allow the programmer to do the right thing, even if the language designer didn't think of it first. This. This is the difference between C and Pascal. This is why C won and Pascal lost - because Pascal prohibited everything but what Wirth thought should be allowed, and Wirth had far too limited a vision of what people might need to do. Ritchie, in contrast, knew he wasn't smart enough to play that game, so he didn't try. As a result, in practice C was considerably more usable than Pascal. The closer you were to the metal, the greater C's advantage. And in those days, you were often pretty close to the metal... Later, on page 60: > Much of the C model relies on the programmer always being right, so the task of the language is to make it easy what is necessary... The converse model, which is the basis of Pascal and Ada, is that the programmer is often wrong, so the language should make it hard to say anything incorrect... Finally, the large amount of freedom provided in the language means that you can make truly spectacular errors, far exceeding the relatively trivial difficulties you encounter misusing, say, BASIC. Also true. And it is true that the "Pascal model" of the programmer has quite a bit of truth to it. But programmers collectively chose freedom over restrictions, even restrictions that were intended to be for their own good.
- drnick1 9mo ago
  Yes and no. Clearly what you said is true, but the more profound reason is that C just minimally reflects how computers work. The rest is just convention.
  - ChrisSD 9mo ago
    It minimally reflects PDP-11 assembly, which is not how modern computers work.
    - uecker 9mo ago
      This is a meme which is repeated often, but not really true. If you disagree, please state specifically what property of PDP-11 you think it different from how modern computers work, and where this affects C but not other languages.
      - pjmlp 9mo ago
        It lacked SIMD instructions.
        tmtvl 9mo ago
        Don't forget about branch prediction (GCC may have __builtin_expect, but that's not standard C).
        direwolf20 9mo ago
        The compiler usually can't do anything about branch prediction. Expect is more about keeping cold paths out of the cache.
        pjmlp 9mo ago
        Actually that was one of the problems with EPIC architectures, where compilers are expected to be the ones doing those kind of optimizations.
- kreco 9mo ago
  I'm not sure I agree with "impossible to change". It's 2026, to this date I cannot use standard library/api, to open a file with utf-8 filename without a null terminating string. When you want to talk to the OS you constantly face the need to had unnecessary overhead (allocation due to string convertion, strlen). The OS itself does not prevent anything from having those standard "no overhead" API. However, it's pretty clear that nobody cares to define some new sane interface and nobody care to deprecate old ones. That would include both API and ABI.
  - phicoh 9mo ago
    Maybe because the performance gain is just not there. Adding support for string with explicit length everywhere is a huge amount of work. And then the question is whether such a string is like a Rust slice or something else. And then the gain is close to zero because most filenames are short enough that there is almost no gain.
    - kreco 9mo ago
      The mental overhead is pretty significant. You need to do weird string operations, you have certainly a class somewhere that needs to append a zero to then end of a buffer, and exclusively use the class for thw filename. You can't just toss a contiguous number of bytes you to convert it first. Every single piece of software that need to interact with the file system needs to deal with this. I'm not asking about a new string type. I'm asking to be able to be free from null terminating string. You only need to provide a length.
      - phicoh 8mo ago
        In practice, with Rust the problem is somewhere else. There is a libc crate that wraps the Unix system calls, so no need to worry about that. What is a lot harder is that Unix filenames are not guaranteed to be UTF-8. So you can't convert to &str or String. At least, not without loss. So you have to keep this around as an OsString.
        8mo ago
yunnpp 9mo ago
The writing is terrible and full of fluff. Maybe the cat logo should have been a warning.
exidy 9mo ago
The author is upfront about their goals and motivations and explicitly acknowledges that other concerns exist. Calling it whiny is ungracious -- the author is letting some very human frustration peek through in their narrative. Not everything has to be written with all the warmth and humanity of a UN subcommittee interim report on widget standardisation.

ranger_danger 9mo ago

What is TFA?

jagged-chisel 9mo ago
The Fine/Fabulous/Fucking Article Choose your own adjective
- SoftTalker 9mo ago
  Featured
- leoc 9mo ago
  To further explain: it comes from 'RTFA' https://en.wiktionary.org/wiki/RTFA https://en.wiktionary.org/wiki/RTFA which was developed on Slashdot as a variation on 'RTFM'.

munificent 9mo ago

> why C gets to be the foundation for how systems software is written. Is there an answer here more interesting than "it's what Unix and Windows were written in, so that's how programs talked to the OS, and once you have an interface, it's impossible to change"?

pizlonator 9mo ago
Yes
- munificent 9mo ago
  Care to share the answer with the rest of the class?
  - uecker 9mo ago
    I am not sure what Filip's view on this is. But like to point out the article from Stephen Kell linked below which explains why C is an incredibly useful tool for systems programming and what distinguishes it from all other languages. https://dl.acm.org/doi/abs/10.1145/3133850.3133867 https://dl.acm.org/doi/abs/10.1145/3133850.3133867
    - rramadass 9mo ago
      That is a nice article! Thanks for the pointer.
jonjacky 9mo ago
It wasn't a coincidence, or an accident. C was specifically designed to write Unix, by people who had experience with a lot of other computer languages, and had programmed other operating systems including Multics and some earlier versions of Unix. They knew exactly what they were doing, and exactly what they wanted.
- munificent 9mo ago
  I'm not sure what you mean by "coincidence" or "accident" here. C is a pretty OK language for writing an OS in the 70s. UNIX got popular for reasons I think largely orthogonal to being written in C. UNIX was one of the first operating systems that was widely licensed to universities. Students were obliged to learn C to work with it. If the Macintosh OS had come out first and taken over the world, we'd probably all be programming in Object Pascal. When everyone wanted to program for the web, we all learned JavaScript regardless of its merits or lack thereof. I don't think there's much very interesting about C beyond the fact that it rode a platform's coattails to popularity. If there is something interesting about it that I'm missing, I'd definitely like to know.
  - heyitsdaad 9mo ago
    First to market is not necessarily the best, case in point: many video sites existed before Youtube, including ones based on Apple Quicktime. But in the end Flash won. To me it looks like there is a better way to do things and the better one eventually wins.
  - AnimalMuppet 9mo ago
    Repeating a previous comment of mine (https://news.ycombinator.com/item?id=32784959 https://news.ycombinator.com/item?id=32784959) about an article in Byte Magazine (August 1983) on the C programming language: From page 52: > Operating systems have to deal with some very unusual objects and events: interrupts; memory maps; apparent locations in memory that really represent devices, hardware traps and faults; and I/O controllers. It is unlikely that even a low-level model can adequately support all of these notions or new ones that come along in the future. So a key idea in C is that the language model be flexible; with escape hatches to allow the programmer to do the right thing, even if the language designer didn't think of it first. This. This is the difference between C and Pascal. This is why C won and Pascal lost - because Pascal prohibited everything but what Wirth thought should be allowed, and Wirth had far too limited a vision of what people might need to do. Ritchie, in contrast, knew he wasn't smart enough to play that game, so he didn't try. As a result, in practice C was considerably more usable than Pascal. The closer you were to the metal, the greater C's advantage. And in those days, you were often pretty close to the metal... Later, on page 60: > Much of the C model relies on the programmer always being right, so the task of the language is to make it easy what is necessary... The converse model, which is the basis of Pascal and Ada, is that the programmer is often wrong, so the language should make it hard to say anything incorrect... Finally, the large amount of freedom provided in the language means that you can make truly spectacular errors, far exceeding the relatively trivial difficulties you encounter misusing, say, BASIC. Also true. And it is true that the "Pascal model" of the programmer has quite a bit of truth to it. But programmers collectively chose freedom over restrictions, even restrictions that were intended to be for their own good.
drnick1 9mo ago
Yes and no. Clearly what you said is true, but the more profound reason is that C just minimally reflects how computers work. The rest is just convention.
- ChrisSD 9mo ago
  It minimally reflects PDP-11 assembly, which is not how modern computers work.
  - uecker 9mo ago
    This is a meme which is repeated often, but not really true. If you disagree, please state specifically what property of PDP-11 you think it different from how modern computers work, and where this affects C but not other languages.
    - pjmlp 9mo ago
      It lacked SIMD instructions.
      - tmtvl 9mo ago
        Don't forget about branch prediction (GCC may have __builtin_expect, but that's not standard C).
        direwolf20 9mo ago
        The compiler usually can't do anything about branch prediction. Expect is more about keeping cold paths out of the cache.
        pjmlp 9mo ago
        Actually that was one of the problems with EPIC architectures, where compilers are expected to be the ones doing those kind of optimizations.
kreco 9mo ago
I'm not sure I agree with "impossible to change". It's 2026, to this date I cannot use standard library/api, to open a file with utf-8 filename without a null terminating string. When you want to talk to the OS you constantly face the need to had unnecessary overhead (allocation due to string convertion, strlen). The OS itself does not prevent anything from having those standard "no overhead" API. However, it's pretty clear that nobody cares to define some new sane interface and nobody care to deprecate old ones. That would include both API and ABI.
- phicoh 9mo ago
  Maybe because the performance gain is just not there. Adding support for string with explicit length everywhere is a huge amount of work. And then the question is whether such a string is like a Rust slice or something else. And then the gain is close to zero because most filenames are short enough that there is almost no gain.
  - kreco 9mo ago
    The mental overhead is pretty significant. You need to do weird string operations, you have certainly a class somewhere that needs to append a zero to then end of a buffer, and exclusively use the class for thw filename. You can't just toss a contiguous number of bytes you to convert it first. Every single piece of software that need to interact with the file system needs to deal with this. I'm not asking about a new string type. I'm asking to be able to be free from null terminating string. You only need to provide a length.
    - phicoh 8mo ago
      In practice, with Rust the problem is somewhere else. There is a libc crate that wraps the Unix system calls, so no need to worry about that. What is a lot harder is that Unix filenames are not guaranteed to be UTF-8. So you can't convert to &str or String. At least, not without loss. So you have to keep this around as an OsString.
      - 8mo ago

yunnpp 9mo ago

The writing is terrible and full of fluff. Maybe the cat logo should have been a warning.

exidy 9mo ago

The author is upfront about their goals and motivations and explicitly acknowledges that other concerns exist. Calling it whiny is ungracious -- the author is letting some very human frustration peek through in their narrative. Not everything has to be written with all the warmth and humanity of a UN subcommittee interim report on widget standardisation.