9 ms·

Interesting rant. I found it fairly humorous but I am not sure if the author meant it that way. As I read it, the author's thesis is that all programming langu

Interesting rant. I found it fairly humorous but I am not sure if the author meant it that way. As I read it, the author's thesis is that all programming languages have to talk to the operating system and the operating system is written in C so the operating system uses C calling conventions which leaks C's "ugliness" into the implementation or expression of their beautiful language. I kind of think of this as the "I like computers but don't really understand computation" fallacy. It is fundamental lack of understanding about the nature of computer architectures and what they can and cannot do vis-a-vis how you might express that in a programming language. One of my professors in college was fond of saying that "All programming languages are just syntactic sugar around machine code." Which is fundamentally true, and tries to capture that at the end of the day what ever your language "says" has to be expressed in machine code to actually do what it does. You will spend a lot of time in this space writing a compiler, and code generation is an art all of its own. But you can side step, a bit, by not writing a compiler, and instead writing an interpreter. The series of articles that were posted here gave a good intro, and while you still have to do the "naughty bit" where you write code in some compilable language that can pretend to be a computer of some different form, you can make everything look like your language. I always encourage people who are "learning computers" to actually write a compiler (there are some good starting points for that but online courseware from MIT and other sources can get you the lecture material too). Doing that helps broaden one's perspective of what language designers and implementers are up against with regards to pretty much every computer working the "same" way (Von Neumann or Harvard architecture wise)

dzaima 5y ago
It's less that the OS is written in C, but more that literally every single interface to literally anything is either written in C, or isn't meant to be used by multiple languages. C is the de facto standard for interacting with anything not written in your language. Window management, I/O, graphics, everything has a C interface. There aren't even any alternatives (besides just sending a list of bytes through a pipe or something, which noone wants to do for obvious reasons).
- ChuckMcM 5y ago
  I don't disagree, I see an expectation on the part of driver/API providers that you can write (probably in C) and adapter layer that can talk "glorious language" on the input, and then do the naughty bits and talk to the C API on the output. My position is that this is less of a burden than writing something that goes from the "glorious language" into machine code. Understanding why that is less of a burden is gained by writing a compiler where you go right from "expressing what you want" to "machine code that does that".
  - dzaima 5y ago
    I mean, a C interface is better than a machine code interface. The problem with that is that, unless you include a C compiler (or at least a thing that understands the 176 C ABIs) with your language, you can't use it. (not that machine code would be better at that, but I'm sure that if people actually intentionally attempted to make a global cross-platform ABI, they'd easily make something much better than C)
    - Koshkin 5y ago
      > a C interface is better than a machine code interface The last thing I want when I write code in assembly is to have to call a C library just to invoke a system function.
      - dzaima 5y ago
        You'd obviously prefer calling into things made in your own language than some other. But, from any other language you'd much prefer a C interface over having to explicitly describe which registers & stack slots to put things in and read from.
        mcronce 5y ago
        I did this once trying to mitigate Go's FFI performance cost. It wasn't great but it wasn't awful either. If I had to do it again I'd generate the assembly trampolines.
tester756 5y ago
>I always encourage people who are "learning computers" to actually write a compiler (there are some good starting points for that but online courseware from MIT and other sources can get you the lecture material too). Doing that helps broaden one's perspective of what language designers and implementers are up against with regards to pretty much every computer working the "same" way (Von Neumann or Harvard architecture wise) Isn't it dependent on what IR do you use?
winter_blue 5y ago
> "I like computers but don't really understand computation" You know you could make your point without being condescending and trying to insult the author.
- Brian_K_White 5y ago
  The author invites insult by being insulting themselsves, not to mention comically overweening. They are free to write a new os in rust with superior abis if they want to show us all how it's done. I'm sure it will be in use by the entire world in 50 years the way c is today, and no one from that time will write a blog post like this one because he of course will get it right.
  - LAC-Tech 5y ago
    No software is going to be perfect. But new software can at least try and improve upon the old software. Do you really think that Unix and C are the absolute pinnacle that our field has to offer, we shouldn't bother trying anything else? (Not a unix or C hater, just a bit of a tangent about how it's cool that people make new things even if they won't be perfect).
    - thesuperbigfrog 5y ago
      >> Do you really think that Unix and C are the absolute pinnacle that our field has to offer, we shouldn't bother trying anything else? Unix and C are not the pinnacle of ease of use, but rather the survivors of the past 50 years of programming language and operating system evolution. So many of their parents, relatives, competitors, and even children have died and yet they remain. That means that they are the most adaptive and the most successful in a Darwinian sense, but not necessarily the most ergonomic or user-friendly.
      - scratcheee 5y ago
        That would be more compelling if their success was more directly coupled with their technical design. Unix is not technically incompetent (certainly given the needs of the times it was designed in), but its real success now is largely based on it already being an incombent, and being open enough for projects to work from. Original Unix is dead, it lives on through copy-cats, and they copied it mostly because an experienced user-base makes adoption easier. In other words, the only time Unix was primarly selected for technical reasons was very short lived. Now its technical benefits are little more relevant than the technical benefits of a qwerty keyboard.
brundolf 5y ago
> the "I like computers but don't really understand computation" fallacy > I always encourage people who are "learning computers" Buddy, the author is a major contributor to the Rust project
- smegsicle 5y ago
  does that preclude one from making bad points in a rant?
  - brundolf 5y ago
    I think it precludes one from “not really understanding computation”.
  - Barrin92 5y ago
    no but even though this is written in a rant-ish style it isn't isn't really one given that the post is full of specific examples discussing all the things that are wrong with C as an interface. This is probably the most technical post I've seen on HN in a while and accusing someone who goes fairly deep into the implementation details of compilers, and OS libs of 'not understanding computation' is somewhat bizarre.
- jackosdev 5y ago
  > Phantomderp and I have both recently been very aligned on a particular subject: being extremely angry about C ABIs and trying to fix them. Damn beginners!
- kibwen 5y ago
  I think it's been a few years since Gankra has been active, but she was the original mastermind of std::collections as well as the original author of the Rustonomicon, if anyone wants her credentials.
  - brundolf 5y ago
    She’s still on the website under lang-docs, at least: https://www.rust-lang.org/governance/teams/lang#lang-docs%20team https://www.rust-lang.org/governance/teams/lang#lang-docs%20...
leshow 5y ago
> I always encourage people who are "learning computers" to actually write a compiler Does the Rust compiler count? The author has been a long time contributor. > I kind of think of this as the "I like computers but don't really understand computation" fallacy. You couldn't be more wrong about the author
II2II 5y ago
I only made it about 80% through because, yes it was a rant. I'm pretty sure the author knew what they were talking about. The issues discussed were those of someone who knows how computers work with a great deal more depth than many (if not the vast majority) of developers. The point that programming languages are just syntactic sugar around machine code isn't really relevant here since, for better or for worse, C headers are the standard way to codify access to ABI's. A deep understanding may be fine if you aren't accessing many ABI's, but it doesn't scale well. Using C headers does scale well, but the author is pointing out there are many things about C that makes this difficult.
- deleted 5y ago
  [deleted]
- WalterBright 5y ago
  The most difficult part of C-headers-as-interfaces is the use of macros as part of the ABI.
  - notacoward 5y ago
    Agreed. That part is just mind-bogglingly awful, and fairly unique to C/C++. AFAICT all the other problems are common across most alternatives, many of which are actually worse.
saagarjha 5y ago
Putting aside the personal jab, which the other comments have rightfully called you out for (really, this is why people detest “the orange site”) you’ve just fundamentally misunderstood the point of the blog post. C is kind of a horrible way of specifying machine interfaces, because it tries to lift things into being portable when the interface is anything but. The ABI is what ties C to the specific machine interface that it’s exposing, and in doing so dooms the ABI from ever changing. The article has many, many examples: a simple one is that it’s stupid to expose a 32-bit value as an “int” because that means “int” needs to be 32-bit forever. In this sense providing a C API is bad because the interpretation of the API into ABI is dependent and on your tooling and sometimes even that doesn’t agree, with fun™ results. This very much isn’t a request for “please give Rust a nice interface to the kernel” but more a “there ought to be something better than having to run libclang just to talk to the kernel”.
- notacoward 5y ago
  So what do you suggest instead? Express APIs in yet another language (perhaps one with defined-length numeric types) other than the ones people actually use? An IDL? Who's going to do that work, from the definitions themselves to the bazillion language-specific bindings? I'm not saying that you should have to have an answer before you can criticize, but every solution to this particular problem sucks in some way. Some things are just hard. Jumping on a bandwagon to tear down something that already exists, ignoring or trivializing any problems it does solve or that alternatives would need to, is another much-despised Orange Site behavior. Nobody ever turns out to have a real silver bullet in their back pocket.
  - olliej 5y ago
    Fuchsia/zircon uses IDL to define the system API interface and it works for them :D
    - saagarjha 5y ago
      Ok to be fair Fuschia could define their system API using Protobuf and it would work for them
cashsterling 5y ago
Total foot in mouth, here... hope you are having a good day, otherwise!
jyounker 5y ago
> I always encourage people who are "learning computers" to actually write a compiler (there are some good starting points for that but online courseware from MIT and other sources can get you the lecture material too). Doing that helps broaden one's perspective of what language designers and implementers are up against with regards to pretty much every computer working the "same" way (Von Neumann or Harvard architecture wise) I suggest looking up the author's CV.

dzaima 5y ago

It's less that the OS is written in C, but more that literally every single interface to literally anything is either written in C, or isn't meant to be used by multiple languages. C is the de facto standard for interacting with anything not written in your language. Window management, I/O, graphics, everything has a C interface. There aren't even any alternatives (besides just sending a list of bytes through a pipe or something, which noone wants to do for obvious reasons).

ChuckMcM 5y ago
I don't disagree, I see an expectation on the part of driver/API providers that you can write (probably in C) and adapter layer that can talk "glorious language" on the input, and then do the naughty bits and talk to the C API on the output. My position is that this is less of a burden than writing something that goes from the "glorious language" into machine code. Understanding why that is less of a burden is gained by writing a compiler where you go right from "expressing what you want" to "machine code that does that".
- dzaima 5y ago
  I mean, a C interface is better than a machine code interface. The problem with that is that, unless you include a C compiler (or at least a thing that understands the 176 C ABIs) with your language, you can't use it. (not that machine code would be better at that, but I'm sure that if people actually intentionally attempted to make a global cross-platform ABI, they'd easily make something much better than C)
  - Koshkin 5y ago
    > a C interface is better than a machine code interface The last thing I want when I write code in assembly is to have to call a C library just to invoke a system function.
    - dzaima 5y ago
      You'd obviously prefer calling into things made in your own language than some other. But, from any other language you'd much prefer a C interface over having to explicitly describe which registers & stack slots to put things in and read from.
      - mcronce 5y ago
        I did this once trying to mitigate Go's FFI performance cost. It wasn't great but it wasn't awful either. If I had to do it again I'd generate the assembly trampolines.

tester756 5y ago

>I always encourage people who are "learning computers" to actually write a compiler (there are some good starting points for that but online courseware from MIT and other sources can get you the lecture material too). Doing that helps broaden one's perspective of what language designers and implementers are up against with regards to pretty much every computer working the "same" way (Von Neumann or Harvard architecture wise) Isn't it dependent on what IR do you use?

winter_blue 5y ago

> "I like computers but don't really understand computation" You know you could make your point without being condescending and trying to insult the author.

Brian_K_White 5y ago
The author invites insult by being insulting themselsves, not to mention comically overweening. They are free to write a new os in rust with superior abis if they want to show us all how it's done. I'm sure it will be in use by the entire world in 50 years the way c is today, and no one from that time will write a blog post like this one because he of course will get it right.
- LAC-Tech 5y ago
  No software is going to be perfect. But new software can at least try and improve upon the old software. Do you really think that Unix and C are the absolute pinnacle that our field has to offer, we shouldn't bother trying anything else? (Not a unix or C hater, just a bit of a tangent about how it's cool that people make new things even if they won't be perfect).
  - thesuperbigfrog 5y ago
    >> Do you really think that Unix and C are the absolute pinnacle that our field has to offer, we shouldn't bother trying anything else? Unix and C are not the pinnacle of ease of use, but rather the survivors of the past 50 years of programming language and operating system evolution. So many of their parents, relatives, competitors, and even children have died and yet they remain. That means that they are the most adaptive and the most successful in a Darwinian sense, but not necessarily the most ergonomic or user-friendly.
    - scratcheee 5y ago
      That would be more compelling if their success was more directly coupled with their technical design. Unix is not technically incompetent (certainly given the needs of the times it was designed in), but its real success now is largely based on it already being an incombent, and being open enough for projects to work from. Original Unix is dead, it lives on through copy-cats, and they copied it mostly because an experienced user-base makes adoption easier. In other words, the only time Unix was primarly selected for technical reasons was very short lived. Now its technical benefits are little more relevant than the technical benefits of a qwerty keyboard.

brundolf 5y ago

> the "I like computers but don't really understand computation" fallacy > I always encourage people who are "learning computers" Buddy, the author is a major contributor to the Rust project

smegsicle 5y ago
does that preclude one from making bad points in a rant?
- brundolf 5y ago
  I think it precludes one from “not really understanding computation”.
- Barrin92 5y ago
  no but even though this is written in a rant-ish style it isn't isn't really one given that the post is full of specific examples discussing all the things that are wrong with C as an interface. This is probably the most technical post I've seen on HN in a while and accusing someone who goes fairly deep into the implementation details of compilers, and OS libs of 'not understanding computation' is somewhat bizarre.
jackosdev 5y ago
> Phantomderp and I have both recently been very aligned on a particular subject: being extremely angry about C ABIs and trying to fix them. Damn beginners!
kibwen 5y ago
I think it's been a few years since Gankra has been active, but she was the original mastermind of std::collections as well as the original author of the Rustonomicon, if anyone wants her credentials.
- brundolf 5y ago
  She’s still on the website under lang-docs, at least: https://www.rust-lang.org/governance/teams/lang#lang-docs%20team https://www.rust-lang.org/governance/teams/lang#lang-docs%20...

leshow 5y ago

> I always encourage people who are "learning computers" to actually write a compiler Does the Rust compiler count? The author has been a long time contributor. > I kind of think of this as the "I like computers but don't really understand computation" fallacy. You couldn't be more wrong about the author

II2II 5y ago

I only made it about 80% through because, yes it was a rant. I'm pretty sure the author knew what they were talking about. The issues discussed were those of someone who knows how computers work with a great deal more depth than many (if not the vast majority) of developers. The point that programming languages are just syntactic sugar around machine code isn't really relevant here since, for better or for worse, C headers are the standard way to codify access to ABI's. A deep understanding may be fine if you aren't accessing many ABI's, but it doesn't scale well. Using C headers does scale well, but the author is pointing out there are many things about C that makes this difficult.

deleted 5y ago
[deleted]
WalterBright 5y ago
The most difficult part of C-headers-as-interfaces is the use of macros as part of the ABI.
- notacoward 5y ago
  Agreed. That part is just mind-bogglingly awful, and fairly unique to C/C++. AFAICT all the other problems are common across most alternatives, many of which are actually worse.

saagarjha 5y ago

Putting aside the personal jab, which the other comments have rightfully called you out for (really, this is why people detest “the orange site”) you’ve just fundamentally misunderstood the point of the blog post. C is kind of a horrible way of specifying machine interfaces, because it tries to lift things into being portable when the interface is anything but. The ABI is what ties C to the specific machine interface that it’s exposing, and in doing so dooms the ABI from ever changing. The article has many, many examples: a simple one is that it’s stupid to expose a 32-bit value as an “int” because that means “int” needs to be 32-bit forever. In this sense providing a C API is bad because the interpretation of the API into ABI is dependent and on your tooling and sometimes even that doesn’t agree, with fun™ results. This very much isn’t a request for “please give Rust a nice interface to the kernel” but more a “there ought to be something better than having to run libclang just to talk to the kernel”.

notacoward 5y ago
So what do you suggest instead? Express APIs in yet another language (perhaps one with defined-length numeric types) other than the ones people actually use? An IDL? Who's going to do that work, from the definitions themselves to the bazillion language-specific bindings? I'm not saying that you should have to have an answer before you can criticize, but every solution to this particular problem sucks in some way. Some things are just hard. Jumping on a bandwagon to tear down something that already exists, ignoring or trivializing any problems it does solve or that alternatives would need to, is another much-despised Orange Site behavior. Nobody ever turns out to have a real silver bullet in their back pocket.
- olliej 5y ago
  Fuchsia/zircon uses IDL to define the system API interface and it works for them :D
  - saagarjha 5y ago
    Ok to be fair Fuschia could define their system API using Protobuf and it would work for them

cashsterling 5y ago

Total foot in mouth, here... hope you are having a good day, otherwise!

jyounker 5y ago

> I always encourage people who are "learning computers" to actually write a compiler (there are some good starting points for that but online courseware from MIT and other sources can get you the lecture material too). Doing that helps broaden one's perspective of what language designers and implementers are up against with regards to pretty much every computer working the "same" way (Von Neumann or Harvard architecture wise) I suggest looking up the author's CV.