5 ms·

> 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 i

> 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 8mo ago
Yes
- munificent 8mo ago
  Care to share the answer with the rest of the class?
  - uecker 8mo 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 8mo ago
      That is a nice article! Thanks for the pointer.
jonjacky 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo ago
  It minimally reflects PDP-11 assembly, which is not how modern computers work.
  - uecker 8mo 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 8mo ago
      It lacked SIMD instructions.
      - tmtvl 8mo ago
        Don't forget about branch prediction (GCC may have __builtin_expect, but that's not standard C).
        direwolf20 8mo ago
        The compiler usually can't do anything about branch prediction. Expect is more about keeping cold paths out of the cache.
        pjmlp 8mo 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 8mo 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 8mo 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 8mo 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

pizlonator 8mo ago

Yes

munificent 8mo ago
Care to share the answer with the rest of the class?
- uecker 8mo 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 8mo ago
    That is a nice article! Thanks for the pointer.

jonjacky 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo ago
It minimally reflects PDP-11 assembly, which is not how modern computers work.
- uecker 8mo 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 8mo ago
    It lacked SIMD instructions.
    - tmtvl 8mo ago
      Don't forget about branch prediction (GCC may have __builtin_expect, but that's not standard C).
      - direwolf20 8mo ago
        The compiler usually can't do anything about branch prediction. Expect is more about keeping cold paths out of the cache.
        pjmlp 8mo 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 8mo 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 8mo 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 8mo 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