3 ms·

Many other potential systems programming languages are object-oriented (C++, D), which at the very least counts them out because Linus and perhaps the rest of t

Many other potential systems programming languages are object-oriented (C++, D), which at the very least counts them out because Linus and perhaps the rest of the core team dislikes OOP. I can't say one way or the other whether their assessment is objectively correct, but another data point here is that Windows, while mostly written in C++, also sticks to C for the kernel, and even the C++ code sticks to C-compatible APIs at module boundaries, for maintainability reasons. Complexity may only arguably be a shortcoming of object-oriented languages, but compatibility is absolutely a problem. Others, like Go, use garbage collection. That may not be universally unacceptable in OS kernels, but it's certainly not something anyone wants to see happening in the Linux kernel, which sees use in applications with low-memory and real-time constraints. And the rest are dead or dying languages such as Pascal and Ada. I can't speak to Rust's merits, I don't know it well enough, but if some reasonable subset of Rust makes it easy to stick to C-compatible ABIs without sacrificing most of the language's practical differences from C, then I would say that, yeah, it may truly be the first good - or even reasonable - candidate.

nneonneo 5y ago
I wouldn’t say that Linus et al. dislike object orientation - the entire kernel is built on a system of object abstractions which just happen to be written in C rather than C++ or similar. The biggest reason why Rust is, in my mind, a contender for the kernel is that it genuinely adds a new capability that C++ does not: true and guaranteed memory safety, with an unsafe core that is much easier to audit. Drivers written in Rust will be much less likely to contain memory safety problems, and that’s potentially a big win for kernel maintainers and developers. And yeah, it’s also interoperable with C to a large degree, which certainly helps.
- johnisgood 5y ago
  Would it not require lots of unsafe code and whatnot?
  - mumblemumble 5y ago
    I'm no kernel developer, but I would guess that even putting some yellow caution tape around the risky stuff, and knowing everything that isn't taped off is less risky, could be a win for maintainability. The current status quo is presumably that people need to be able to grok 100% of the code deeply enough to be able to evaluate all proposed changes for memory safety implications at all times.
    - johnisgood 5y ago
      The problem is that unsafe blocks affect the code outside it, too. It is a common misconception that it does not.
      - mumblemumble 5y ago
        But can't you at least surmise that, as long as you can independently show that the code in the unsafe blocks only affects safe code in the intended manner, you can reason about the unsafe behavior in a more modular way? Kind of a memory safety equivalent to what structured programming did for control flow.
Tozen 5y ago
TIOBE ranks Delphi/Object Pascal above Go and Rust. I don't quite get this odd behavior of so quickly labeling a language as "dead" and devoid of any evidence to back up the claim. In the case of Pascal and Ada, various commercial interests want them to be "dead", because both represent a threat to their financial interests. Pascal became Object Pascal, which is very much around in the form of Delphi/Embarcadero, Free Pascal/Lazarus, Oxygene/Rem Objects, PascalABC, etc... Ada for sure is not going anywhere for many years to come because of its use in the military and aerospace industries.

nneonneo 5y ago

I wouldn’t say that Linus et al. dislike object orientation - the entire kernel is built on a system of object abstractions which just happen to be written in C rather than C++ or similar. The biggest reason why Rust is, in my mind, a contender for the kernel is that it genuinely adds a new capability that C++ does not: true and guaranteed memory safety, with an unsafe core that is much easier to audit. Drivers written in Rust will be much less likely to contain memory safety problems, and that’s potentially a big win for kernel maintainers and developers. And yeah, it’s also interoperable with C to a large degree, which certainly helps.

johnisgood 5y ago
Would it not require lots of unsafe code and whatnot?
- mumblemumble 5y ago
  I'm no kernel developer, but I would guess that even putting some yellow caution tape around the risky stuff, and knowing everything that isn't taped off is less risky, could be a win for maintainability. The current status quo is presumably that people need to be able to grok 100% of the code deeply enough to be able to evaluate all proposed changes for memory safety implications at all times.
  - johnisgood 5y ago
    The problem is that unsafe blocks affect the code outside it, too. It is a common misconception that it does not.
    - mumblemumble 5y ago
      But can't you at least surmise that, as long as you can independently show that the code in the unsafe blocks only affects safe code in the intended manner, you can reason about the unsafe behavior in a more modular way? Kind of a memory safety equivalent to what structured programming did for control flow.

Tozen 5y ago

TIOBE ranks Delphi/Object Pascal above Go and Rust. I don't quite get this odd behavior of so quickly labeling a language as "dead" and devoid of any evidence to back up the claim. In the case of Pascal and Ada, various commercial interests want them to be "dead", because both represent a threat to their financial interests. Pascal became Object Pascal, which is very much around in the form of Delphi/Embarcadero, Free Pascal/Lazarus, Oxygene/Rem Objects, PascalABC, etc... Ada for sure is not going anywhere for many years to come because of its use in the military and aerospace industries.