16 ms·

Is Rust truly the first good candidate for Linux's second language? Why didn't older languages get this far?

by oDot 5y ago

goalieca 5y ago
We have to rule out any language with a garbage collector. C++ adds about as much negative as positive to be worth while. That doesn’t leave many other options.
- sanxiyn 5y ago
  C++ would be a clear win on net. Anyone thinking otherwise, even if they are Linux developers, are wrong.
  - loeg 5y ago
    It’s fine to have opinions, but you’re stating them as if they’re fact. The Linux kernel maintainers disagree with you. They’re experienced engineers, and ultimately, they make the rules.
    - sanxiyn 5y ago
      C++ is the industry standard, C is a retrocomputing language. Everyone is using C++, except for legacy codebases and some recalcitrant FOSS maintainers. Of course Linux is maintained by Linux maintainers, I am just pointing out they are against industry consensus.
      - adgjlsfhk1 5y ago
        The industry isn't typically writing kernels.
        sanxiyn 5y ago
        Well, Google is writing a new kernel (for Fuchsia), and it is written in C++.
        vlovich123 5y ago
        Fuchsia is a micro kernel. The core kernel bit is written in C + ASM as Rust wasn't ready at the time. The various ancillary pieces that make up the OS (e.g. filesystem, drivers, etc) are written primarily in Rust. C++ I believe had been used but as Rust has matured and evolved that's gone away for the most part.
        sanxiyn 5y ago
        > The core kernel bit is written in C This is untrue. Where did you get it? Have a look at kernel scheduler written in C++ here: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/zircon/kernel/kernel/scheduler.cc https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/z.... constexpr! namespace!
        vlovich123 5y ago
        Oh huh. It must have moved on significantly from when I last looked at it years ago. It started of based largely on LK work. If you look at the old code [1], it has a C++ extension & is likely compiled with a C++ compiler but the code itself is really just C. That's why cloc sometimes isn't an accurate tool for these. I don't have a sense of what the policy is but they could still be sticking with the C convention w/ C++ only utilizing things like constexpr & various other compiler pieces. They do seem to be making use of templates so it looks like there's been a lot more modernization done there. [1] https://fuchsia.googlesource.com/fuchsia/+/9c7855e320662ad909903d2bef6a8e7c23dd5d90/zircon/kernel/kernel/sched.cc https://fuchsia.googlesource.com/fuchsia/+/9c7855e320662ad90...
        jyounker 5y ago
        It would be wise not to confuse C++ at Google with C++. Google has extremely strong internal coding standards. Those standards restrict which C++ features can be used, and how and where those C++ features can be used. Without compliance based upon paycheck and performance reviews, I'm not sure that I'd want to try to make that kind of selective enforcement work.
      - czynskee 5y ago
        Mac and Windows kernels are also written (predominantly) in C. So not sure what industry you're referring to. If anyone's interested - here's Linus on C++ in the linux kernel: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
        secondcoming 5y ago
        That was written in 2007
        pjmlp 5y ago
        Mac drivers (which run on kernel space) are written on a C++ subset. Windows has been slowly migrating to C++ since Vista, when VC++ got kernel support for C++ code, naturally one just doesn't move something like Windows to C++ just like that. https://community.osr.com/discussion/291326/the-new-wil-library-for-c-code-in-drivers https://community.osr.com/discussion/291326/the-new-wil-libr... > First off, let me point out that this library is used to implement large parts of the OS. There are hundreds of developers here who use it. So unlike, uh, some other things that get tossed onto github, this project is not likely to wither and die tomorrow.
        kaba0 5y ago
        That website is the stupidest shit though. They should be playing with rocks with that stupid ultra-minimalistic bullshit they spew. Also, both windows and mac has considerable and growing amount of C++.
      - fault1 5y ago
        I would say for lower level code, when C++ is used, it's a C-like dialect of C++ that is used. This is even true with something like clang and llvm. Certainly the /more/ low level you go, the less C++-isms you see. These days, sure you can use a highly restricted form of C++ in systems close to HW, but you might as well be using the industry standard in those environments, which is C, compiled with a C/C++ compiler.
        pjmlp 5y ago
        AUTOSAR is an industry standard that requires C++14, in the process of being ratified for C++17.
      - mlindner 5y ago
        > C++ is the industry standard, C is a retrocomputing language. You'd be surprised how many fortune 500 software companies have thousands of programmers who are writing new C code every day. Even Apple writes new C every day.
  - yakubin 5y ago
    Ok, now it's my turn: C++ would be a clear loss on net. Anyone thinking otherwise, even if they are Linux developers, are wrong. Now that was productive.
  - rhinoceraptor 5y ago
    I think the main issue with C++ is just that C++ is not one thing. Everyone has a different idea of which of the incredible number of features added over the years are good, and which are footguns. Obviously many of the features of C++ are incompatible with kernel development, since C++ is designed to be used for applications, not kernels.
    - jll29 5y ago
      Exactly. Very well said - in other words: C++ is NOT ORTHOGONAL, whereas C is. C++ is also an evolving monster that everyone uses different subsets of, and many developers only know or use subsets of, either for lack of expertise or out of conviction (see how polarised the discussion of exceptions in C++ is here). And every five years, even more complexity gets added, making the C++ story a modern PL/1-like story. For many decades, there were also substantial differences in compiler maturity, forcing many to rely on subsets artificially.
      - kaba0 5y ago
        But C is so small that every project will use their own under-specified conventions with no documentation, no tooling, etc. At least C++ language features will have proper documentation, not this “if we place a struct inside this one at a specific place, we can use it as a linked list for no added memory cost” shit that one must know for each and every project (and is error prone).
bombcar 5y ago
The benefits of other languages didn't outweigh the costs associated. The only major one I know of was some push for C++ which Linus wasn't a fan of: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
- sanxiyn 5y ago
  The article is outdated: it is pre-C++11. For example, constexpr would be valuable for kernel and is unavailable in C. Maybe "STL is stable and portable" wasn't entirely true in 2007, but it is true in 2021.
  - mumblemumble 5y ago
    I think that his comment about "inefficient abstracted programming models" is probably the more pertinent one here. One important factor to consider there, and for which Linux is wholly unlike the vast majority of other projects, even system projects, is that the userbase is just massive, and includes a lot of the world's infrastructure. That results in a rather different cost/benefit calculus around abstraction/performance tradeoffs than the ones for which object-oriented and functional programming were designed. For example, I think that it's probably good for all of us that there's not really a whole lot of dynamic dispatch happening in the Linux kernel. I would generally prefer that my syscalls keep pointer chasing to an absolute minimum. But I'm hard pressed to imagine how a C++ style that avoids vtables like the plague could really have that much to offer over straight C. And it would simultaneously put extra code review pressure on the kernel team, since they would have to carefully watch to make sure contributors aren't introducing such things. Similar concerns apply to Rust, mind. But it's much easier for me to see how Rust without trait objects could still bring something of value to the table.
    - jeffbee 5y ago
      The linux kernel is crawling with dynamic dispatch, but because it is in C they are the most inefficient dynamic dispatch mechanisms possible, with arrays of function pointers populated at runtime that 1) the compiler can never optimize, because they aren't visible at build time, and 2) that have been the causes of numerous vulnerabilities, because it's not always obvious at commit/review time that the author has screwed up the assignment of function pointers to dispatch slots. C++ would be a huge win all over the kernel, the only barrier to it is Linus' ignorance.
fxtentacle 5y ago
Less religious missionaries. Also, less funding by FAANG.
- rvz 5y ago
  You know that the Rust hype squad will do everything they can to get the Linux maintainers to shove Rust into the Linux kernel even if it the excuse is: "You'll get used to it" or "It will take time to learn." or "It's not that hard at first but it will be worth it!" I'm sure the Rust hype squad are now coming out of the woodwork to prepare the coronation of the Linux kernel project using Rust.
  - sophacles 5y ago
    I understand you don't like rust. That's fair it's got pros and cons and some cool stuff and warts. What i don't understand is the sheer level of anger it brings out in people. As one of those angry folks: what makes you so upset?
    - detaro 5y ago
      not OP, but: Presumably the impression that there is a Rust hype squad that's pushing it everywhere and swipes away any counter arguments. I'm not that opposed to Rust and think its an interesting language, but the more annoying parts of its fanbase really haven't done it any favors. The sort that comments on every new project not in Rust "why is this not in Rust" (this specific thing seems to have died down somewhat), ignores any progress in other languages or Rusts weaknesses when making comparisons and thinks "Everyone still writing C++ should be tried in Den Haag" is a perfectly fine contribution (yes, that's a real example. sadly)
      - Guvante 5y ago
        C++ has nearly as many rabid fanboys as Rust. I am curious why the community reacts differently to them. I am not saying "just write it in Rust" is a good thing, I think anyone claiming someone else needs to rewrite their program is automatically wrong. This thread is full of "Linus hates C++" as if "the subset of C++ that can be used in the kernel is basically C" is an outright fabrication. I may be oversampling on the fact that nearly every article about programming languages here is filled with people wondering what the point is though shrug.
gjsman-1000 5y ago
It’s truly the only low-level language that could actually be used for systems programming. C#, Java? Managed code with JITs, not supported on a kernel level no-way no-how. Ditto for Python, PHP, JavaScript, and other high-level languages without pointers and all that jazz. Go would be close… but it requires bundling a bunch of libraries in with each binary and wasn’t designed for low-level development. Again unsuitable. C++? Linus Torvalds and the kernel developers hate it for being unnecessarily complicated and only making things harder to maintain while bringing little to the table at this point (they’ve made it this far without classes, and C++ doesn’t bring anything new like memory safety).
- vips7L 5y ago
  D and Zig could work.
  - gjsman-1000 5y ago
    Nobody really proposed these in earnest. Also, it’s a kernel, where diversity of programming languages is a nightmare. It’s not the kernel’s job to support every language people want - it’s just that Rust has enough going for it that it’s finally being considered worthwhile after years of investigation.
  - infogulch 5y ago
    Insofar as they don't bundle a runtime (unlike the languages mentioned by GP), yes. But they don't really offer much above C in the area of resource tracking / safety that rust's novel ownership+lifetimes system provides.
    - floatboth 5y ago
      Heh, there were plans to add ownership&borrowing to D: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... but of course bolting something on as an option is not the same as having the whole language designed strictly around it.
    - 5y ago
henpa 5y ago
I guess it's because Rust is a "safe programming language" and the world needs that.
deleted 5y ago
[deleted]
johnisgood 5y ago
Because no one bothered. I would rather prefer the drivers be written in Ada/SPARK.
skywal_l 5y ago
Probably because the older languages did not bring enough to the table versus C. I've notice that the trend of new compiled language is fairly recent with Nim (2006)/Go (2009)/Rust (2010). The previous trend was more oriented toward interpreted languages Python (1991)/Ruby (1995)/Javascript (1995). So maybe, 10 years is the maturity age and we will see more of those language used for Linux kernel development.
- loeg 5y ago
  And the older compiled languages were often GC languages, which is unsuitable for the kernel (eg Java — arguably compiled, or AoT C#).
pjmlp 5y ago
Mostly because Linus hates C++, basically. Other candidates like Modula-2 or Ada, never had big sucess in UNIX space. Objective-C never went beyond NeXT and Apple (yes NeXTSTEP drivers were written in Objective-C).
- Guvante 5y ago
  I think that isn't fair to Linus. C++ with minimal use of templates, nearly no dynamic allocations and never calling any function that could possibly throw an exception is pretty dang close to C.
  - pjmlp 5y ago
    It is quite fair to Linus, “I will not use C++ and programmers who develop projects instead of C are kicked out, lest they mess up the projects I’m involved in”, “C++ ended up with a bunch of terrible, unmaintainable garbage” So how could C++ ever be possible in the Linux kernel? The problem isn't technical, and to come back to your C++ example, there are plenty of OSes using C++ at the kernel level. macOS being one of them via IO Kit, Windows since Vista, or that maker board loved by everyone, named Arduino. Probably to Linus dismay, all Project Treble drivers (which run in userspace) on Android, are mix of C++ and Java, classical Linux drivers are considered "legacy" in what concerns AOSP project.
    - formerly_proven 5y ago
      On the other hand, subsurface is now mostly C++ (mostly due to a GUI framework written in C).
      - pjmlp 5y ago
        Except Linus doesn't touch that C++ code at all.
  - spacechild1 5y ago
    You would still get RAII, generic programming and compile time evaluation - which I think is a big deal.
matheusmoreira 5y ago
Rust actually has support for freestanding programming without any standard library.
fnord77 5y ago
popularity, safety guarantees, no GC, modern features There might be objectively better languages for kernel development out there, but it doesn't do any good if nobody uses or knows them.
mumblemumble 5y ago
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.
summerlight 5y ago
There are not many older languages that specifically targeted low level programming and gained some level of traction, which I cannot think out of C++ (and perhaps D? but it's not really popular).
the__alchemist 5y ago
The list of appropriate languages is short. Here's what I have, for non-GC, systems languages, other than C: - C++ - Rust - Zig - Ada
- nathancahill 5y ago
  I'd add Nim with `--gc:arc` or `--gc:none`
- floatboth 5y ago
  Also D in 'betterC' mode
jokoon 5y ago
Because c is simple. Rust has many qualities, but it's not a simple language. The problem with complex languages is that they are ill suited for low level stuff. Sometimes it's better to not have high level language features, because it allows everybody to understand the code without having to know every feature of the language. Simple is better. There are too many developers who prefer complexity.
- pornel 5y ago
  Simplicity is not that simple :) Brainfuck is an objectively smaller and simpler language than C, but it's not any better. Certain problems have an inherent irreducible complexity. This complexity has to go somewhere. If the language doesn't tackle it, then users of the language will have to. This is especially clear in the case of memory errors in C. C is too basic to express ownership of memory, valid scopes of pointers, and thread-safety of their usage. This doesn't make these problems disappear, only requires users to handle it manually and get it right without compiler's help. In Rust you have to specify ownership and thread-safety of everything. It is complex, but not because Rust is complex, but because safe low-level memory management and thread safety are difficult problems.
  - raxxorrax 5y ago
    Not that difficult problems most of the time, but in practice the problems are more or less ignored and it often works, in most cases anyway. Not good obviously. Problem I have with Rust is that it uses certain patterns to make it work against the unforgiving borrow checker. I am not convinced that we will stay at this point. Rust disallows some operations where the developer can know the operation to be safe, but the borrow checker does not. So you need to accommodate the language.
    - pornel 5y ago
      Yes indeed, in Rust you have to do things the Rust way. But that's not much different than pains of trying to write imperative code in an OOP language, or mutable code in a pure functional language. Rust is closer to ML than the C family of languages, and the differences become apparent if you try to use it like C/C++. It's not a blocker in practice, because you can fudge things with `unsafe` if you know you're smarter than the borrow checker.
ksec 5y ago
>Why didn't older languages get this far? It is the "first language" that Linus didn't object to. He hated both C++ and Ada. I am not entirely sure if he really likes rust, sees borrow checker as something important worth trying, or lost to the pressure from RESF ( Rust Evangelism Strike Force ) within the linux kernel dev community. He is a proponent of C because he can imagine, or envision the generated assembly from C compiler. Something like a High Level of assembly. And something along the line of people who can write good C code tends to have all the scar tissue to prove it.
- dureuill 5y ago
  Would you happen to have some links about Linus hating Ada? While his stance on C++ is well-known, this is the first time that I hear he has public opinions about Ada. Thank you
  - ksec 5y ago
    >https://www.infoworld.com/article/3109150/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux-at-25-linus-... >What do you think of the projects currently underway to develop OS kernels in languages like Rust (touted for having built-in safeties that C does not)? >That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters. >I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations. And I asked him once I think in a private email a few years back and he manage to gave me a long detailed reply that was like an essay ( Still very very grateful for his time ). May be he doesn't hate Ada as he did to C++, but it certainly feels he doesn't like it. I would be interested to see his opinion on Zig, which I think really fits his liking. But may be after 1.0, which is still some way off.
    - dureuill 5y ago
      Thank you!
shmerl 5y ago
Rust seems to be the first decent alternative to C that works for Linux and has momentum to invest in it. I think Linus also commented that it has to be exciting and interesting for developers besides being useful obviously.
rodgerd 5y ago
> Why didn't older languages get this far? People are talking about Linus' opinions of some other languages, but more importantly the Rust folks have been prepared to put in a lot of work to meet Linus' concerns. You're now seeing all sorts of other language advocates pop up with D, Zig, and so on, but they've not put in the same work to convince Linus that anything else are real options.

Is Rust truly the first good candidate for Linux's second language? Why didn't older languages get this far?

by oDot 5y ago

Is Rust truly the first good candidate for Linux's second language? Why didn't older languages get this far?

We have to rule out any language with a garbage collector. C++ adds about as much negative as positive to be worth while. That doesn’t leave many other options.

sanxiyn 5y ago
C++ would be a clear win on net. Anyone thinking otherwise, even if they are Linux developers, are wrong.
- loeg 5y ago
  It’s fine to have opinions, but you’re stating them as if they’re fact. The Linux kernel maintainers disagree with you. They’re experienced engineers, and ultimately, they make the rules.
  - sanxiyn 5y ago
    C++ is the industry standard, C is a retrocomputing language. Everyone is using C++, except for legacy codebases and some recalcitrant FOSS maintainers. Of course Linux is maintained by Linux maintainers, I am just pointing out they are against industry consensus.
    - adgjlsfhk1 5y ago
      The industry isn't typically writing kernels.
      - sanxiyn 5y ago
        Well, Google is writing a new kernel (for Fuchsia), and it is written in C++.
        vlovich123 5y ago
        Fuchsia is a micro kernel. The core kernel bit is written in C + ASM as Rust wasn't ready at the time. The various ancillary pieces that make up the OS (e.g. filesystem, drivers, etc) are written primarily in Rust. C++ I believe had been used but as Rust has matured and evolved that's gone away for the most part.
        sanxiyn 5y ago
        > The core kernel bit is written in C This is untrue. Where did you get it? Have a look at kernel scheduler written in C++ here: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/zircon/kernel/kernel/scheduler.cc https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/z.... constexpr! namespace!
        vlovich123 5y ago
        Oh huh. It must have moved on significantly from when I last looked at it years ago. It started of based largely on LK work. If you look at the old code [1], it has a C++ extension & is likely compiled with a C++ compiler but the code itself is really just C. That's why cloc sometimes isn't an accurate tool for these. I don't have a sense of what the policy is but they could still be sticking with the C convention w/ C++ only utilizing things like constexpr & various other compiler pieces. They do seem to be making use of templates so it looks like there's been a lot more modernization done there. [1] https://fuchsia.googlesource.com/fuchsia/+/9c7855e320662ad909903d2bef6a8e7c23dd5d90/zircon/kernel/kernel/sched.cc https://fuchsia.googlesource.com/fuchsia/+/9c7855e320662ad90...
        jyounker 5y ago
        It would be wise not to confuse C++ at Google with C++. Google has extremely strong internal coding standards. Those standards restrict which C++ features can be used, and how and where those C++ features can be used. Without compliance based upon paycheck and performance reviews, I'm not sure that I'd want to try to make that kind of selective enforcement work.
    - czynskee 5y ago
      Mac and Windows kernels are also written (predominantly) in C. So not sure what industry you're referring to. If anyone's interested - here's Linus on C++ in the linux kernel: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
      - secondcoming 5y ago
        That was written in 2007
      - pjmlp 5y ago
        Mac drivers (which run on kernel space) are written on a C++ subset. Windows has been slowly migrating to C++ since Vista, when VC++ got kernel support for C++ code, naturally one just doesn't move something like Windows to C++ just like that. https://community.osr.com/discussion/291326/the-new-wil-library-for-c-code-in-drivers https://community.osr.com/discussion/291326/the-new-wil-libr... > First off, let me point out that this library is used to implement large parts of the OS. There are hundreds of developers here who use it. So unlike, uh, some other things that get tossed onto github, this project is not likely to wither and die tomorrow.
      - kaba0 5y ago
        That website is the stupidest shit though. They should be playing with rocks with that stupid ultra-minimalistic bullshit they spew. Also, both windows and mac has considerable and growing amount of C++.
    - fault1 5y ago
      I would say for lower level code, when C++ is used, it's a C-like dialect of C++ that is used. This is even true with something like clang and llvm. Certainly the /more/ low level you go, the less C++-isms you see. These days, sure you can use a highly restricted form of C++ in systems close to HW, but you might as well be using the industry standard in those environments, which is C, compiled with a C/C++ compiler.
      - pjmlp 5y ago
        AUTOSAR is an industry standard that requires C++14, in the process of being ratified for C++17.
    - mlindner 5y ago
      > C++ is the industry standard, C is a retrocomputing language. You'd be surprised how many fortune 500 software companies have thousands of programmers who are writing new C code every day. Even Apple writes new C every day.
- yakubin 5y ago
  Ok, now it's my turn: C++ would be a clear loss on net. Anyone thinking otherwise, even if they are Linux developers, are wrong. Now that was productive.
- rhinoceraptor 5y ago
  I think the main issue with C++ is just that C++ is not one thing. Everyone has a different idea of which of the incredible number of features added over the years are good, and which are footguns. Obviously many of the features of C++ are incompatible with kernel development, since C++ is designed to be used for applications, not kernels.
  - jll29 5y ago
    Exactly. Very well said - in other words: C++ is NOT ORTHOGONAL, whereas C is. C++ is also an evolving monster that everyone uses different subsets of, and many developers only know or use subsets of, either for lack of expertise or out of conviction (see how polarised the discussion of exceptions in C++ is here). And every five years, even more complexity gets added, making the C++ story a modern PL/1-like story. For many decades, there were also substantial differences in compiler maturity, forcing many to rely on subsets artificially.
    - kaba0 5y ago
      But C is so small that every project will use their own under-specified conventions with no documentation, no tooling, etc. At least C++ language features will have proper documentation, not this “if we place a struct inside this one at a specific place, we can use it as a linked list for no added memory cost” shit that one must know for each and every project (and is error prone).

bombcar 5y ago

The benefits of other languages didn't outweigh the costs associated. The only major one I know of was some push for C++ which Linus wasn't a fan of: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus

sanxiyn 5y ago
The article is outdated: it is pre-C++11. For example, constexpr would be valuable for kernel and is unavailable in C. Maybe "STL is stable and portable" wasn't entirely true in 2007, but it is true in 2021.
- mumblemumble 5y ago
  I think that his comment about "inefficient abstracted programming models" is probably the more pertinent one here. One important factor to consider there, and for which Linux is wholly unlike the vast majority of other projects, even system projects, is that the userbase is just massive, and includes a lot of the world's infrastructure. That results in a rather different cost/benefit calculus around abstraction/performance tradeoffs than the ones for which object-oriented and functional programming were designed. For example, I think that it's probably good for all of us that there's not really a whole lot of dynamic dispatch happening in the Linux kernel. I would generally prefer that my syscalls keep pointer chasing to an absolute minimum. But I'm hard pressed to imagine how a C++ style that avoids vtables like the plague could really have that much to offer over straight C. And it would simultaneously put extra code review pressure on the kernel team, since they would have to carefully watch to make sure contributors aren't introducing such things. Similar concerns apply to Rust, mind. But it's much easier for me to see how Rust without trait objects could still bring something of value to the table.
  - jeffbee 5y ago
    The linux kernel is crawling with dynamic dispatch, but because it is in C they are the most inefficient dynamic dispatch mechanisms possible, with arrays of function pointers populated at runtime that 1) the compiler can never optimize, because they aren't visible at build time, and 2) that have been the causes of numerous vulnerabilities, because it's not always obvious at commit/review time that the author has screwed up the assignment of function pointers to dispatch slots. C++ would be a huge win all over the kernel, the only barrier to it is Linus' ignorance.

fxtentacle 5y ago

Less religious missionaries. Also, less funding by FAANG.

rvz 5y ago
You know that the Rust hype squad will do everything they can to get the Linux maintainers to shove Rust into the Linux kernel even if it the excuse is: "You'll get used to it" or "It will take time to learn." or "It's not that hard at first but it will be worth it!" I'm sure the Rust hype squad are now coming out of the woodwork to prepare the coronation of the Linux kernel project using Rust.
- sophacles 5y ago
  I understand you don't like rust. That's fair it's got pros and cons and some cool stuff and warts. What i don't understand is the sheer level of anger it brings out in people. As one of those angry folks: what makes you so upset?
  - detaro 5y ago
    not OP, but: Presumably the impression that there is a Rust hype squad that's pushing it everywhere and swipes away any counter arguments. I'm not that opposed to Rust and think its an interesting language, but the more annoying parts of its fanbase really haven't done it any favors. The sort that comments on every new project not in Rust "why is this not in Rust" (this specific thing seems to have died down somewhat), ignores any progress in other languages or Rusts weaknesses when making comparisons and thinks "Everyone still writing C++ should be tried in Den Haag" is a perfectly fine contribution (yes, that's a real example. sadly)
    - Guvante 5y ago
      C++ has nearly as many rabid fanboys as Rust. I am curious why the community reacts differently to them. I am not saying "just write it in Rust" is a good thing, I think anyone claiming someone else needs to rewrite their program is automatically wrong. This thread is full of "Linus hates C++" as if "the subset of C++ that can be used in the kernel is basically C" is an outright fabrication. I may be oversampling on the fact that nearly every article about programming languages here is filled with people wondering what the point is though shrug.

gjsman-1000 5y ago

It’s truly the only low-level language that could actually be used for systems programming. C#, Java? Managed code with JITs, not supported on a kernel level no-way no-how. Ditto for Python, PHP, JavaScript, and other high-level languages without pointers and all that jazz. Go would be close… but it requires bundling a bunch of libraries in with each binary and wasn’t designed for low-level development. Again unsuitable. C++? Linus Torvalds and the kernel developers hate it for being unnecessarily complicated and only making things harder to maintain while bringing little to the table at this point (they’ve made it this far without classes, and C++ doesn’t bring anything new like memory safety).

vips7L 5y ago
D and Zig could work.
- gjsman-1000 5y ago
  Nobody really proposed these in earnest. Also, it’s a kernel, where diversity of programming languages is a nightmare. It’s not the kernel’s job to support every language people want - it’s just that Rust has enough going for it that it’s finally being considered worthwhile after years of investigation.
- infogulch 5y ago
  Insofar as they don't bundle a runtime (unlike the languages mentioned by GP), yes. But they don't really offer much above C in the area of resource tracking / safety that rust's novel ownership+lifetimes system provides.
  - floatboth 5y ago
    Heh, there were plans to add ownership&borrowing to D: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... but of course bolting something on as an option is not the same as having the whole language designed strictly around it.
  - 5y ago

henpa 5y ago

I guess it's because Rust is a "safe programming language" and the world needs that.

deleted 5y ago

[deleted]

johnisgood 5y ago

Because no one bothered. I would rather prefer the drivers be written in Ada/SPARK.

skywal_l 5y ago

Probably because the older languages did not bring enough to the table versus C. I've notice that the trend of new compiled language is fairly recent with Nim (2006)/Go (2009)/Rust (2010). The previous trend was more oriented toward interpreted languages Python (1991)/Ruby (1995)/Javascript (1995). So maybe, 10 years is the maturity age and we will see more of those language used for Linux kernel development.

loeg 5y ago
And the older compiled languages were often GC languages, which is unsuitable for the kernel (eg Java — arguably compiled, or AoT C#).

pjmlp 5y ago

Mostly because Linus hates C++, basically. Other candidates like Modula-2 or Ada, never had big sucess in UNIX space. Objective-C never went beyond NeXT and Apple (yes NeXTSTEP drivers were written in Objective-C).

Guvante 5y ago
I think that isn't fair to Linus. C++ with minimal use of templates, nearly no dynamic allocations and never calling any function that could possibly throw an exception is pretty dang close to C.
- pjmlp 5y ago
  It is quite fair to Linus, “I will not use C++ and programmers who develop projects instead of C are kicked out, lest they mess up the projects I’m involved in”, “C++ ended up with a bunch of terrible, unmaintainable garbage” So how could C++ ever be possible in the Linux kernel? The problem isn't technical, and to come back to your C++ example, there are plenty of OSes using C++ at the kernel level. macOS being one of them via IO Kit, Windows since Vista, or that maker board loved by everyone, named Arduino. Probably to Linus dismay, all Project Treble drivers (which run in userspace) on Android, are mix of C++ and Java, classical Linux drivers are considered "legacy" in what concerns AOSP project.
  - formerly_proven 5y ago
    On the other hand, subsurface is now mostly C++ (mostly due to a GUI framework written in C).
    - pjmlp 5y ago
      Except Linus doesn't touch that C++ code at all.
- spacechild1 5y ago
  You would still get RAII, generic programming and compile time evaluation - which I think is a big deal.

matheusmoreira 5y ago

Rust actually has support for freestanding programming without any standard library.

fnord77 5y ago

popularity, safety guarantees, no GC, modern features There might be objectively better languages for kernel development out there, but it doesn't do any good if nobody uses or knows them.

mumblemumble 5y ago

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.

summerlight 5y ago

There are not many older languages that specifically targeted low level programming and gained some level of traction, which I cannot think out of C++ (and perhaps D? but it's not really popular).

the__alchemist 5y ago

The list of appropriate languages is short. Here's what I have, for non-GC, systems languages, other than C: - C++ - Rust - Zig - Ada

nathancahill 5y ago
I'd add Nim with `--gc:arc` or `--gc:none`
floatboth 5y ago
Also D in 'betterC' mode

jokoon 5y ago

Because c is simple. Rust has many qualities, but it's not a simple language. The problem with complex languages is that they are ill suited for low level stuff. Sometimes it's better to not have high level language features, because it allows everybody to understand the code without having to know every feature of the language. Simple is better. There are too many developers who prefer complexity.

pornel 5y ago
Simplicity is not that simple :) Brainfuck is an objectively smaller and simpler language than C, but it's not any better. Certain problems have an inherent irreducible complexity. This complexity has to go somewhere. If the language doesn't tackle it, then users of the language will have to. This is especially clear in the case of memory errors in C. C is too basic to express ownership of memory, valid scopes of pointers, and thread-safety of their usage. This doesn't make these problems disappear, only requires users to handle it manually and get it right without compiler's help. In Rust you have to specify ownership and thread-safety of everything. It is complex, but not because Rust is complex, but because safe low-level memory management and thread safety are difficult problems.
- raxxorrax 5y ago
  Not that difficult problems most of the time, but in practice the problems are more or less ignored and it often works, in most cases anyway. Not good obviously. Problem I have with Rust is that it uses certain patterns to make it work against the unforgiving borrow checker. I am not convinced that we will stay at this point. Rust disallows some operations where the developer can know the operation to be safe, but the borrow checker does not. So you need to accommodate the language.
  - pornel 5y ago
    Yes indeed, in Rust you have to do things the Rust way. But that's not much different than pains of trying to write imperative code in an OOP language, or mutable code in a pure functional language. Rust is closer to ML than the C family of languages, and the differences become apparent if you try to use it like C/C++. It's not a blocker in practice, because you can fudge things with `unsafe` if you know you're smarter than the borrow checker.

ksec 5y ago

>Why didn't older languages get this far? It is the "first language" that Linus didn't object to. He hated both C++ and Ada. I am not entirely sure if he really likes rust, sees borrow checker as something important worth trying, or lost to the pressure from RESF ( Rust Evangelism Strike Force ) within the linux kernel dev community. He is a proponent of C because he can imagine, or envision the generated assembly from C compiler. Something like a High Level of assembly. And something along the line of people who can write good C code tends to have all the scar tissue to prove it.

dureuill 5y ago
Would you happen to have some links about Linus hating Ada? While his stance on C++ is well-known, this is the first time that I hear he has public opinions about Ada. Thank you
- ksec 5y ago
  >https://www.infoworld.com/article/3109150/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux-at-25-linus-... >What do you think of the projects currently underway to develop OS kernels in languages like Rust (touted for having built-in safeties that C does not)? >That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters. >I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations. And I asked him once I think in a private email a few years back and he manage to gave me a long detailed reply that was like an essay ( Still very very grateful for his time ). May be he doesn't hate Ada as he did to C++, but it certainly feels he doesn't like it. I would be interested to see his opinion on Zig, which I think really fits his liking. But may be after 1.0, which is still some way off.
  - dureuill 5y ago
    Thank you!

shmerl 5y ago

Rust seems to be the first decent alternative to C that works for Linux and has momentum to invest in it. I think Linus also commented that it has to be exciting and interesting for developers besides being useful obviously.

rodgerd 5y ago

> Why didn't older languages get this far? People are talking about Linus' opinions of some other languages, but more importantly the Rust folks have been prepared to put in a lot of work to meet Linus' concerns. You're now seeing all sorts of other language advocates pop up with D, Zig, and so on, but they've not put in the same work to convince Linus that anything else are real options.