4 ms·

Or a demonstration about the poor state of programming languages in 2024. Of course there are others than C. But not many suitable for writing a kernel. And no

Or a demonstration about the poor state of programming languages in 2024. Of course there are others than C. But not many suitable for writing a kernel. And no obvious choice for what Linux could do today. Of course they are starting with Rust, but nobody can predict when that will make the last C macro unnecessary. Unless your prediction is never...

pjmlp 2y ago
Plenty of kernels have been written in other languages, naturally UNIX/POSIX folks can hardly think of something else. Even Linus accepting Rust is kind of interesting, because his C++ rants also apply to plenty of Rust code bases.
- gary_0 2y ago
  Doesn't Rust's `no_std` make it easy to throw out idioms you can't use (or don't like) and just keep the syntax and most of the tooling? I recall that one of Linus's preconditions for inclusion was that Rust's default of panic!ing on allocation failures had to be overrideable. Whereas C++ tends to make you eat the whole enchilada.
  - pjmlp 2y ago
    C++ compilers have similar options, e.g. VC++ has /kernel, and there is the freestanding standard as well. Also see Embedded C++ as used by macOS IO Kit, which thankfully there isn't a Linus at Apple. Regarding Rust, no_std, doesn't change the npm like dependencies, macro festival (with two ways of doing all kinds of stuff), abstraction party with type driven development, the compile times.
    - tialaramex 2y ago
      The C++ "freestanding" even when the current round of work is completed, is nowhere close to Rust's core. Partly this is because Rust thought about this earlier, and partly it's because of the relationship between C++ and the allocator, having operators for a feature which might not even exist on your target, awkward.
      - pjmlp 2y ago
        True, doesn't change the fact that outside Linus hate for C++, other places, with more sensible persons, have chosen otherwise.
        gary_0 2y ago
        It's not just Linus. I use C++ daily for a variety of things, but I understand the hesitance to use it in real-world kernels and embedded code. For instance: The switches to disable features like exceptions are generally considered "not supported, use at own risk"; removing them is not an official part of the language. C++ templates are slow to compile and have many obvious shortcomings — but if you avoid them, you're back to using C macros. The C++ abstract machine puts a lot of weird complications in the way, adding new UB landmines on top of C. This doesn't mean using C++ for kernels and such is impossible, but anyone with a conservative, risk-averse mindset (like Linus) isn't going to want to touch it. Rust, on the other hand, was deliberately designed for such uses, starting from a fresh sheet of paper. Giving systems programmers everything they want without any hidden "gotchas" is its whole raison d'être.
        tialaramex 2y ago
        I don't see how picking C++ counts as "more sensible". Linus chose C 30+ years ago because it was the only practical option. Bjarne (and some other C++ proponents) worked hard to present C++ as somehow a natural upgrade to C and that worked on Microsoft and at some of the defunct proprietary Unix vendors but it didn't work on Linus. My strong impression is that both Apple and Microsoft are moving away from C++ in their core systems.
- j16sdiz 2y ago
  On of the reason is: They have Rust compiler developers on board. This is a "direct line" to any language features or bugs reports. C++, otoh, is run by committee and far removed from the community. (C is not much better, but at least they are stable)
  - pjmlp 2y ago
    Stable? C23 has just been approved.
  - PaulDavisThe1st 2y ago
    > C++, otoh, is run by committee and far removed from the community. It is hard to be close to a community with the size and divergence of the C++ one. It is (relatively) easy to be close to a community the size of the Rust one.
- kbolino 2y ago
  Most kernels not written in low-level languages (C, stripped-down unsafe C++, or assembly) were written for special hardware. Such hardware was built to handle a lot of the low-level details so that the software didn't have to. This particular approach can't be translated by software alone to modern general-purpose microprocessor-based platforms. Even if we were able to transition to such a do-more-work-in-hardware platform somehow, then we would just be trading kernel bugs for hardware bugs, and the latter aren't always fixable (even with firmware and microcode).
  - pjmlp 2y ago
    Outside Bell Labs many other languages came to be.
    - kbolino 2y ago
      The x86 family didn't come out of Bell Labs. It's not a question of where the programming languages came from but of the boundary line between hardware and software.

pjmlp 2y ago

Plenty of kernels have been written in other languages, naturally UNIX/POSIX folks can hardly think of something else. Even Linus accepting Rust is kind of interesting, because his C++ rants also apply to plenty of Rust code bases.

gary_0 2y ago
Doesn't Rust's `no_std` make it easy to throw out idioms you can't use (or don't like) and just keep the syntax and most of the tooling? I recall that one of Linus's preconditions for inclusion was that Rust's default of panic!ing on allocation failures had to be overrideable. Whereas C++ tends to make you eat the whole enchilada.
- pjmlp 2y ago
  C++ compilers have similar options, e.g. VC++ has /kernel, and there is the freestanding standard as well. Also see Embedded C++ as used by macOS IO Kit, which thankfully there isn't a Linus at Apple. Regarding Rust, no_std, doesn't change the npm like dependencies, macro festival (with two ways of doing all kinds of stuff), abstraction party with type driven development, the compile times.
  - tialaramex 2y ago
    The C++ "freestanding" even when the current round of work is completed, is nowhere close to Rust's core. Partly this is because Rust thought about this earlier, and partly it's because of the relationship between C++ and the allocator, having operators for a feature which might not even exist on your target, awkward.
    - pjmlp 2y ago
      True, doesn't change the fact that outside Linus hate for C++, other places, with more sensible persons, have chosen otherwise.
      - gary_0 2y ago
        It's not just Linus. I use C++ daily for a variety of things, but I understand the hesitance to use it in real-world kernels and embedded code. For instance: The switches to disable features like exceptions are generally considered "not supported, use at own risk"; removing them is not an official part of the language. C++ templates are slow to compile and have many obvious shortcomings — but if you avoid them, you're back to using C macros. The C++ abstract machine puts a lot of weird complications in the way, adding new UB landmines on top of C. This doesn't mean using C++ for kernels and such is impossible, but anyone with a conservative, risk-averse mindset (like Linus) isn't going to want to touch it. Rust, on the other hand, was deliberately designed for such uses, starting from a fresh sheet of paper. Giving systems programmers everything they want without any hidden "gotchas" is its whole raison d'être.
      - tialaramex 2y ago
        I don't see how picking C++ counts as "more sensible". Linus chose C 30+ years ago because it was the only practical option. Bjarne (and some other C++ proponents) worked hard to present C++ as somehow a natural upgrade to C and that worked on Microsoft and at some of the defunct proprietary Unix vendors but it didn't work on Linus. My strong impression is that both Apple and Microsoft are moving away from C++ in their core systems.
j16sdiz 2y ago
On of the reason is: They have Rust compiler developers on board. This is a "direct line" to any language features or bugs reports. C++, otoh, is run by committee and far removed from the community. (C is not much better, but at least they are stable)
- pjmlp 2y ago
  Stable? C23 has just been approved.
- PaulDavisThe1st 2y ago
  > C++, otoh, is run by committee and far removed from the community. It is hard to be close to a community with the size and divergence of the C++ one. It is (relatively) easy to be close to a community the size of the Rust one.
kbolino 2y ago
Most kernels not written in low-level languages (C, stripped-down unsafe C++, or assembly) were written for special hardware. Such hardware was built to handle a lot of the low-level details so that the software didn't have to. This particular approach can't be translated by software alone to modern general-purpose microprocessor-based platforms. Even if we were able to transition to such a do-more-work-in-hardware platform somehow, then we would just be trading kernel bugs for hardware bugs, and the latter aren't always fixable (even with firmware and microcode).
- pjmlp 2y ago
  Outside Bell Labs many other languages came to be.
  - kbolino 2y ago
    The x86 family didn't come out of Bell Labs. It's not a question of where the programming languages came from but of the boundary line between hardware and software.