8 ms·

Rust support in the kernel is good news, but it's just inexcusable that we've had to wait this long for a post-C language. Human beings cannot consistently writ

Rust support in the kernel is good news, but it's just inexcusable that we've had to wait this long for a post-C language. Human beings cannot consistently write correct C --- not you, not me, not Linus Torvalds. Spending decades writing C when a safer language was available caused the industry needless pain. C++ support could have been viable a decade ago had it not been for strong egos on LKML refusing to admit they were wrong. Rust support in Linux is at least partially a face-saving way of backtracking on C++ in the kernel. Rust is great, but with the sole exception of Rust's reified lifetime management, C++ is the better language.

harry8 5y ago
Can't disagree with the idea of having C++ in an os kernel strongly enough. It has certainly been tried and in the cases I know of, regretted.
- quotemstr 5y ago
  > Can't disagree with the idea of having C++ in an os kernel strongly enough Why? How, precisely, does C++ hurt? > It has certainly been tried and in the cases I know of, regretted. Did it? Fuchsia didn't regret C++ in the kernel. GDB didn't regret moving to C++. (I know GDB isn't the kernel, but it's systems-y.) Android's libc, Bionic, is also written in C++. Every single argument I've seen against C++ in systems code has been specious: people act like typing "g++" instantly implants a copy of the GoF book in your head and turns you into a design patterns robot. "I don't like it" is not a technical argument. Neither is a profanity-laced rant, as satisfying as it might be to pound out such a thing. You can just use C++ as a safer C. Linux would have gotten huge rewards in both safety and developer efficiency if LKML hadn't spent a decade doubling down on their nonsense arguments against C++.
  - inglor_cz 5y ago
    Symbian OS was AFAIK written in a specific dialect of C++ as well.
    - varajelle 5y ago
      Every C++ project is written in some dialect of C++
    - harry8 5y ago
      At least one of the L4 implementations. IBM's K42. I think one of the windows kernels tried it once then reverted? Or did every single windows kernel use C too? Symbian really hit a wall taking Nokia down with it. The N95 was well established in the market before the iphone hit but they couldn't get the slow out. Blame it on C++, something else, whatever. C++ is fine for systems code done tastefully. GDB, GCC, libc, java, go nuts! Kernel, not so much. There's a few things going on. You have to agree on a subset of C++ which is a royal bloody pain in the backside at best. It's like a bracing style meeting where the issues actually matter. Some of this is decided for you, you can't have exceptions. Now you can't have operator overloading either. Now constructors are a bit of an issue to consider fairly deeply, "YOU'RE KIDDING YOU'RE SO WRONG I HATE YOU!" And I don't even know what you think about it yet! ;-) Now do that with thousands of contributors. Nasty. Google and Fuchsia? I think they've already got rid of most contributors with the CLA. https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual I couldn't find an actual license and didn't feel like curling to bash to find out what's in the code. It's not surprise that most who try it have a microkernel based system. It is doable. It's been done! Criticising Linus for refusing to go that way seems a little naieve to me tbh. He can point at considerable success as a result of his fundamental approach. That may not be the end of it. But it clearly wasn't a disaster. Critics haven't managed to achieve the success the early days of linux yet as far as I'm aware. C++ compilers have universally sucked incredibly hard until fairly recently when gcc and clang really lifted the standard. No the crooks at intel and the way they sabotaged their customers to make their competitors look bad do not count. They lost the right to be taken seriously at that point. C++ for cross platform has been horrible until very recently. A = B + C + D; You know exactly what that does in C without thinking. C++ not so much. Having those extra layers of thought required between the reader and the machine is unpleasant for OS stuff. C++ has its place. Many of its features are extremely useful and seductive. Many can be used tastefully in userspace to make better, stronger, more reliable code. The Kernel? I don't see it . You want to do dynamic dispatch in C. You can see exactly how that will work on the machine. Virtual functions. No, there's magic there. The implementation isn't guaranteed and can change. There are simply more corner cases, gotchas, foot guns and nastiness where you really don't want it. Kernels are hard enough.
  - sseagull 5y ago
    > Every single argument I've seen against C++ in systems code has been specious: people act like typing "g++" instantly implants a copy of the GoF book in your head and turns you into a design patterns robot. "I don't like it" is not a technical argument. Neither is a profanity-laced rant, as satisfying as it might be to pound out such a thing. Well put. Given the style of C used in the linux kernel, it should have been possible to restrict the use of C++ in the same way. Yes there is lots of bad C++ in there, but it doesn't have to make its way into the kernel. The maintainer s can reject code that is uses inheritance, or templates in the wrong way, etc. It's like believing you shouldn't use C in the kernel because it's possible to write lines that are over 80 characters long.
- pjmlp 5y ago
  Symbian, BeOS, Apple, Microsoft, ARM, Arduino, Google, IBM don't seem to much regretted about their decisions. And no, it wasn't C++ that killed Symbian or BeOS.
  - cturner 5y ago
    BeOS kernel was written in C, "It may come as a surprise to some BeOS developers that in our wonderful, buzzword-enabled, OO-powered OS, there is not a single line of C++ code in the kernel." (https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-39.html https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-39....) Windows NT kernel was all C apart from bits of the graphics layer - friction from that team's use of C++ is a theme in /Showstopper/.
    - pjmlp 5y ago
      Windows NT does C++ on the kernel since Vista. Naturally they did not rewrite everything from scratch, just opened the door for new code to use C++. As for BeOS, well I never seen the kernel and Haiku doesn't count.
  - secondcoming 5y ago
    Whoa, Symbian's C++ was quite different to the C++ most people understand. 2-phase construction, no exceptions (Leaves and Traps), no string type (Descriptors). It was quite difficult to write, and new hires had to essentially be retrained. Expecting an app ecosystem to be built on Symbian C++ was unrealistic. It's the lack of an ecosystem that killed it really.
    - pjmlp 5y ago
      Symbian's C++ is still C++, not C.
      - secondcoming 5y ago
        In the same way that Medieval English is still English.
k__ 5y ago
I guess, C++ didn't bring enough on the table for kernel developers to be considered a viable addition. For Rust to be judged differently is a huge signal, I think.
- pjmlp 5y ago
  It has brought to Symbian, BeOS, Apple, Microsoft, ARM, Arduino, IBM, though.
  - rswail 5y ago
    Symbian and BeOS are dead. Apple's software is written in C (BSD Kernel+userland), Objective C (not C++) and now Swift. ARM "operating system" is hardly used extensively. Arduino's are embedded devices and can be programmed in any language but are hardly applicable across the vast range and scale of Linux deployments. IBM's primary operating systems that aren't Unix based are written in Assembler or even RPG.
    - pjmlp 5y ago
      I advise yourself to get acknowledged with IO Kit, Drivers Kit and Metal graphics subsystem. IBM mainframes are written in mix of PL.8 and PL/S originally, with newer code being C++. ARM apparently doesn't have any issues getting their stuff used in medical devices.
    - the_only_law 5y ago
      > IBM's primary operating systems that aren't Unix based are written in Assembler or even RPG. God I want to see the source code of an operating system written in RPG now.
varajelle 5y ago
I'd claim that most (non-toy) Operating System written this century was *not* written in C.
bitL 5y ago
As if human beings were any good in writing Rust code that passed borrow checker in low-level concurrent constructs that also need to be fast...
kzrdude 5y ago
Will Rust be better than C? The kernel uses a lot of non-local reasoning and global resources, when Rust handles them, a lot of its benefits might evaporate. I guess the main authors behind this change have a more optimistic vision of this, than me, though.
geofft 5y ago
Agreed about the inability to write C, but the part about C++ is simply not true. I don't know about "better" in the general sense, but for the specific use case of the Linux kernel, Linus has identified some entirely reasonable objections (though aggressively worded) to C++: https://lkml.org/lkml/2004/1/20/20 https://lkml.org/lkml/2004/1/20/20 - the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++. Those objections do not apply to Rust, which avoids exception handling, avoids implicit allocations, and has a much smaller OO system that resembles what the kernel does for filesystems. Those objections continue to apply to C++. There are good, principled reasons to accept Rust and continue to reject C++. (There are also good reasons to believe that C++ doesn't solve any of the problems with human inability to write correct C, meaning that it wouldn't be worth the cost of adding a new language: https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/ https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/)
- quotemstr 5y ago
  The passage you've quoted is exactly the sort of angry technical schlock that's held back Linux specifically and the industry generally. > the whole C++ exception handling thing is fundamentally broken Not an argument. It's the closest thing in Linus's excretion of unfounded technical opinion to an argument, but it's nevertheless not an actual case for anything. Don't like exceptions in C++? Don't use them. (That said, exceptions aren't "fundamentally broken" no matter how many times Linus repeats that baseless slander.) > any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel This is a general-purpose tirade against any abstraction whatsoever. Good software engineering is all about judiciously "hid[ing] things", including memory allocation. And as it turns out, Linux has plenty of abstractions, some of which involve memory handling. Also, you don't have to use any particular abstraction with C++: you get to choose the abstractions. The language doesn't force any on you. Besides: Rust can do the same sort of abstractions that Linus claims disqualifies C++ as a "good choice for a kernel". It's almost as if C++ was fine even back in 2004 and that the only difference between then and now is that Linus has matured. > you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++. This is a restatement of Linus's opinion, not an argument. You can write everything in assembler too: why take on the baggage of the heap of crap called C?

harry8 5y ago

Can't disagree with the idea of having C++ in an os kernel strongly enough. It has certainly been tried and in the cases I know of, regretted.

quotemstr 5y ago
> Can't disagree with the idea of having C++ in an os kernel strongly enough Why? How, precisely, does C++ hurt? > It has certainly been tried and in the cases I know of, regretted. Did it? Fuchsia didn't regret C++ in the kernel. GDB didn't regret moving to C++. (I know GDB isn't the kernel, but it's systems-y.) Android's libc, Bionic, is also written in C++. Every single argument I've seen against C++ in systems code has been specious: people act like typing "g++" instantly implants a copy of the GoF book in your head and turns you into a design patterns robot. "I don't like it" is not a technical argument. Neither is a profanity-laced rant, as satisfying as it might be to pound out such a thing. You can just use C++ as a safer C. Linux would have gotten huge rewards in both safety and developer efficiency if LKML hadn't spent a decade doubling down on their nonsense arguments against C++.
- inglor_cz 5y ago
  Symbian OS was AFAIK written in a specific dialect of C++ as well.
  - varajelle 5y ago
    Every C++ project is written in some dialect of C++
  - harry8 5y ago
    At least one of the L4 implementations. IBM's K42. I think one of the windows kernels tried it once then reverted? Or did every single windows kernel use C too? Symbian really hit a wall taking Nokia down with it. The N95 was well established in the market before the iphone hit but they couldn't get the slow out. Blame it on C++, something else, whatever. C++ is fine for systems code done tastefully. GDB, GCC, libc, java, go nuts! Kernel, not so much. There's a few things going on. You have to agree on a subset of C++ which is a royal bloody pain in the backside at best. It's like a bracing style meeting where the issues actually matter. Some of this is decided for you, you can't have exceptions. Now you can't have operator overloading either. Now constructors are a bit of an issue to consider fairly deeply, "YOU'RE KIDDING YOU'RE SO WRONG I HATE YOU!" And I don't even know what you think about it yet! ;-) Now do that with thousands of contributors. Nasty. Google and Fuchsia? I think they've already got rid of most contributors with the CLA. https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual I couldn't find an actual license and didn't feel like curling to bash to find out what's in the code. It's not surprise that most who try it have a microkernel based system. It is doable. It's been done! Criticising Linus for refusing to go that way seems a little naieve to me tbh. He can point at considerable success as a result of his fundamental approach. That may not be the end of it. But it clearly wasn't a disaster. Critics haven't managed to achieve the success the early days of linux yet as far as I'm aware. C++ compilers have universally sucked incredibly hard until fairly recently when gcc and clang really lifted the standard. No the crooks at intel and the way they sabotaged their customers to make their competitors look bad do not count. They lost the right to be taken seriously at that point. C++ for cross platform has been horrible until very recently. A = B + C + D; You know exactly what that does in C without thinking. C++ not so much. Having those extra layers of thought required between the reader and the machine is unpleasant for OS stuff. C++ has its place. Many of its features are extremely useful and seductive. Many can be used tastefully in userspace to make better, stronger, more reliable code. The Kernel? I don't see it . You want to do dynamic dispatch in C. You can see exactly how that will work on the machine. Virtual functions. No, there's magic there. The implementation isn't guaranteed and can change. There are simply more corner cases, gotchas, foot guns and nastiness where you really don't want it. Kernels are hard enough.
- sseagull 5y ago
  > Every single argument I've seen against C++ in systems code has been specious: people act like typing "g++" instantly implants a copy of the GoF book in your head and turns you into a design patterns robot. "I don't like it" is not a technical argument. Neither is a profanity-laced rant, as satisfying as it might be to pound out such a thing. Well put. Given the style of C used in the linux kernel, it should have been possible to restrict the use of C++ in the same way. Yes there is lots of bad C++ in there, but it doesn't have to make its way into the kernel. The maintainer s can reject code that is uses inheritance, or templates in the wrong way, etc. It's like believing you shouldn't use C in the kernel because it's possible to write lines that are over 80 characters long.
pjmlp 5y ago
Symbian, BeOS, Apple, Microsoft, ARM, Arduino, Google, IBM don't seem to much regretted about their decisions. And no, it wasn't C++ that killed Symbian or BeOS.
- cturner 5y ago
  BeOS kernel was written in C, "It may come as a surprise to some BeOS developers that in our wonderful, buzzword-enabled, OO-powered OS, there is not a single line of C++ code in the kernel." (https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-39.html https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-39....) Windows NT kernel was all C apart from bits of the graphics layer - friction from that team's use of C++ is a theme in /Showstopper/.
  - pjmlp 5y ago
    Windows NT does C++ on the kernel since Vista. Naturally they did not rewrite everything from scratch, just opened the door for new code to use C++. As for BeOS, well I never seen the kernel and Haiku doesn't count.
- secondcoming 5y ago
  Whoa, Symbian's C++ was quite different to the C++ most people understand. 2-phase construction, no exceptions (Leaves and Traps), no string type (Descriptors). It was quite difficult to write, and new hires had to essentially be retrained. Expecting an app ecosystem to be built on Symbian C++ was unrealistic. It's the lack of an ecosystem that killed it really.
  - pjmlp 5y ago
    Symbian's C++ is still C++, not C.
    - secondcoming 5y ago
      In the same way that Medieval English is still English.

k__ 5y ago

I guess, C++ didn't bring enough on the table for kernel developers to be considered a viable addition. For Rust to be judged differently is a huge signal, I think.

pjmlp 5y ago
It has brought to Symbian, BeOS, Apple, Microsoft, ARM, Arduino, IBM, though.
- rswail 5y ago
  Symbian and BeOS are dead. Apple's software is written in C (BSD Kernel+userland), Objective C (not C++) and now Swift. ARM "operating system" is hardly used extensively. Arduino's are embedded devices and can be programmed in any language but are hardly applicable across the vast range and scale of Linux deployments. IBM's primary operating systems that aren't Unix based are written in Assembler or even RPG.
  - pjmlp 5y ago
    I advise yourself to get acknowledged with IO Kit, Drivers Kit and Metal graphics subsystem. IBM mainframes are written in mix of PL.8 and PL/S originally, with newer code being C++. ARM apparently doesn't have any issues getting their stuff used in medical devices.
  - the_only_law 5y ago
    > IBM's primary operating systems that aren't Unix based are written in Assembler or even RPG. God I want to see the source code of an operating system written in RPG now.

varajelle 5y ago

I'd claim that most (non-toy) Operating System written this century was *not* written in C.

bitL 5y ago

As if human beings were any good in writing Rust code that passed borrow checker in low-level concurrent constructs that also need to be fast...

kzrdude 5y ago

Will Rust be better than C? The kernel uses a lot of non-local reasoning and global resources, when Rust handles them, a lot of its benefits might evaporate. I guess the main authors behind this change have a more optimistic vision of this, than me, though.

geofft 5y ago

Agreed about the inability to write C, but the part about C++ is simply not true. I don't know about "better" in the general sense, but for the specific use case of the Linux kernel, Linus has identified some entirely reasonable objections (though aggressively worded) to C++: https://lkml.org/lkml/2004/1/20/20 https://lkml.org/lkml/2004/1/20/20 - the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++. Those objections do not apply to Rust, which avoids exception handling, avoids implicit allocations, and has a much smaller OO system that resembles what the kernel does for filesystems. Those objections continue to apply to C++. There are good, principled reasons to accept Rust and continue to reject C++. (There are also good reasons to believe that C++ doesn't solve any of the problems with human inability to write correct C, meaning that it wouldn't be worth the cost of adding a new language: https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/ https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/)

quotemstr 5y ago
The passage you've quoted is exactly the sort of angry technical schlock that's held back Linux specifically and the industry generally. > the whole C++ exception handling thing is fundamentally broken Not an argument. It's the closest thing in Linus's excretion of unfounded technical opinion to an argument, but it's nevertheless not an actual case for anything. Don't like exceptions in C++? Don't use them. (That said, exceptions aren't "fundamentally broken" no matter how many times Linus repeats that baseless slander.) > any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel This is a general-purpose tirade against any abstraction whatsoever. Good software engineering is all about judiciously "hid[ing] things", including memory allocation. And as it turns out, Linux has plenty of abstractions, some of which involve memory handling. Also, you don't have to use any particular abstraction with C++: you get to choose the abstractions. The language doesn't force any on you. Besides: Rust can do the same sort of abstractions that Linus claims disqualifies C++ as a "good choice for a kernel". It's almost as if C++ was fine even back in 2004 and that the only difference between then and now is that Linus has matured. > you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++. This is a restatement of Linus's opinion, not an argument. You can write everything in assembler too: why take on the baggage of the heap of crap called C?