7 ms·

That's Linus's opinion, yes. Not everyone has to share it.

by erikj 10y ago

jordigh 10y ago
It's a really annoying widespread opinion. I've been looking for people who really do write OSes in modern C++.
- wichtounet 10y ago
  Hello. I'm the author of the mentioned project. It's indeed a very annoying opinion. Although there are indeed some difficulties in writing an operating system and quite some runtime support to implement, I would say that it's worth it only to have a more powerful language. I'd rather use a language that I really like rather than be forced to use one I don't really care about. I cannot say that C++ is the best language to develop an operating system, but I would definitely say that it's possible if you really know the language. And you don't have to use the complete language (I didn't enable exceptions nor RTTI in my OS).
- ingve 10y ago
  IncludeOS? [0] From the CppCon 2016 presentation description: "Early in the design process we made a hard choice; no C interfaces and no blocking POSIX calls. We’ve done everything from scratch with modern C++ 11/14 - Including device drivers and the complete network stack all the way through ethernet, IP and ARP, up to and including UDP, TCP and recently also an http / REST API framework. To achieve maximum efficiency we decided to do everything event based and async, so there's plenty of opportunities to use lambdas and delegates." [1] [0] http://www.includeos.org/ http://www.includeos.org/ [1] https://cppcon2016.sched.org/event/d30a43dae4a490dce81a3dfc6dea5ce9 https://cppcon2016.sched.org/event/d30a43dae4a490dce81a3dfc6...
  - wichtounet 10y ago
    Nice :) I didn't know this project. I'll definitely read about this project.
    - AlfredBratterud 10y ago
      I'm Alfred from IncludeOS. We're open source, so check us out on GitHub if you want to try IncludeOS or would like to participate: https://github.com/hioa-cs/IncludeOS https://github.com/hioa-cs/IncludeOS We also have a chat if you have any questions: https://gitter.im/hioa-cs/IncludeOS https://gitter.im/hioa-cs/IncludeOS
  - kbenson 10y ago
    Is that really a "hard" choice? Aren't blocking POSIX calls usually just a case where the kernel blocks for you on what is essentially an asynchronous operation anyway? Maybe it's meant to be hard in the "we decided we weren't going to be POSIX compliant which has implications" send and not the hard to implement sense?
- vertex-four 10y ago
  Genode (essentially a microkernel abstraction layer, and some useful userland, a full Qt implementation and a reasonable UNIX-y layer) is entirely C++, with some C++ microkernels available for it (Fiasco.OC and Nova being the two I'm playing with).
- pjmlp 10y ago
  BeOS, Symbian, L4, Genode, Mac OS X drivers, and big parts of Windows are all examples of C++ use in OS development.
  - pklausler 10y ago
    And there was Chorus back in the 90's.
  - retro64 10y ago
    BeOS is the reason I learned C++. I don't recall exactly, but either I didn't understand how or there was no other option but C++ if one wanted to hit the BeOS API. Pity Be Inc. got shafted so bad by MS monopoly abuse. They had zero vendors willing to put their OS on a box and resell it because MS threatened the vendors with pulling their right to sell Windows if they did. This wasn't particular to Be, but to any other OS.
    - pjmlp 10y ago
      Yeah, still have my Be CDs stored somewhere. However regarding Microsoft, I actually think that vendors were as guilty as Microsoft. They could have chosen not to take Microsoft's discount and try to sell alternative OSes, even if it meant having to face a few challenges. The one that takes is as guilty as the one that gives.
      - retro64 10y ago
        I would have to really dig for the emails the company sent out (I should have them archived someplace), but I thought the issue wasn't discounts, but a revoking of the license to sell Windows if the OEMs didn't comply. I did a quick search and came up with Quora answer given here: https://www.quora.com/Why-was-the-BeOS-dropped https://www.quora.com/Why-was-the-BeOS-dropped but this doesn't jive with my memory. I will have to see if I can find an old email or maybe dig further on the net. I certainly don’t want to be rewriting history.
        pjmlp 10y ago
- notalaser 10y ago
  I don't write OSes in modern C++ at the moment (most of my day job is embedded Linux nowadays, go figure...) but I've seen a lot of sane, OS-level C++ code. Even C++ code that I have bad memories about (uh, Symbian) is partly justifiable. The only real beef I have with C++ is its complexity. As I did less and less high-level programming, I forgot about many of C++'s pitfalls and nowadays I'm always tiptoeing when I have to write C++ code. I think a lot of it is unwarranted, or at least not needed when you're writing system-level code (but my impression may be distorted by the fact that I'm used to embedded systems and high-reliability applications; my sight may be narrow here). Edit -- oh, by the way: it's worth pointing out, in the context of a thread that mentions Torvalds' opinion on the matter, that the whole thing was written a while ago. The Internet endlessly recycles some of these arguments, e.g. STL still gets a lot of criticism that hasn't been true in a while. Yes, STL was terrible, terrible fifteen years ago, but that's, like, 50 years in computer years.
  - PeCaN 10y ago
    The STL might be the best programming success story. It used to be awful, but now I rank it among the best standard libraries of any language.
    - gpderetta 10y ago
      that's because Stepanov named and shamed standard library and compilers implementors whose standard library wasn't compliant/fast enough.
- monocasa 10y ago
  I'm the maintainer of a proprietary C++14 RTOS for work. What do you want to know?
  - roninb 10y ago
    I'm not OP, but I'm interested in the fact that you specified C++14. Are there any features specific to C++14 that you use? I have about two university classes worth of experience with low-level software, but I can really only see the deprecation attribute and binary literals being useful? All of the other language additions (added support for type deduction, templates, lambdas, and the mixing of all three to various degrees) seem like they would take up too many resources to be useful.
    - monocasa 10y ago
      We switched from C++11 to C++14 mainly for constexpr (it existed in 11, but had a lot of restrictions that limited it's usefulness). The advanced template techniques (and to a degree, I'm throwing type deduction in there too), when treated skeptically do lead to more efficient code. It's easy to go off the deep end though, which is why I said "when treated skeptically". As for lambdas, we have an entirely asynchronous OS, so they're really nice for callback glue. EDIT: Binary literals actually come up way less than you'd think, even for deeply embedded (I think the smallest thing we ship on currently is 16KB of RAM). Everyone here knows hex like the back of their hand.
tmptmp 10y ago
Yes, but his opinion counts more than some John Doe's as Linus supports his case with solid arguments.
- gpderetta 10y ago
  'It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C' Solid argument that. His two other arguments: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) Considering that the linux kernel is strongly tied to the specific C dialect supported by GCC and is not portable at all, this argument is bullshit. - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app. You can abstract yourself in a corner in C as well. In C++ you are more likely to pay less for abstractions. Sorry, but I take it personally when me and my colleagues are called substandard programmers.
  - grive 10y ago
    > You can abstract yourself in a corner in C as well. It's much, much harder to do than in C++. It's also much more obvious when it happens, and in collaboration others will spot it quickly. His tone is harsh but I find it completely right. I prefer to use C at work exactly because the same kind of software would be an absolute nightmare to write in C++ (it is very low-level soft, extremely similar to kernel code). C++ is good if you can enforce very strict guidelines and if every single programmer that contributes to the code is very good at C++. Those are pretty big if, especially if you work with a partially open source codebase.
  - TillE 10y ago
    As long as you avoid "virtual", I can't even think of any C++ features which would lead you towards worse performance characteristics than C. Templates may bloat your binary size and increase compile times, but they're plenty fast.

That's Linus's opinion, yes. Not everyone has to share it.

by erikj 10y ago

That's Linus's opinion, yes. Not everyone has to share it.

jordigh 10y ago

It's a really annoying widespread opinion. I've been looking for people who really do write OSes in modern C++.

wichtounet 10y ago
Hello. I'm the author of the mentioned project. It's indeed a very annoying opinion. Although there are indeed some difficulties in writing an operating system and quite some runtime support to implement, I would say that it's worth it only to have a more powerful language. I'd rather use a language that I really like rather than be forced to use one I don't really care about. I cannot say that C++ is the best language to develop an operating system, but I would definitely say that it's possible if you really know the language. And you don't have to use the complete language (I didn't enable exceptions nor RTTI in my OS).
ingve 10y ago
IncludeOS? [0] From the CppCon 2016 presentation description: "Early in the design process we made a hard choice; no C interfaces and no blocking POSIX calls. We’ve done everything from scratch with modern C++ 11/14 - Including device drivers and the complete network stack all the way through ethernet, IP and ARP, up to and including UDP, TCP and recently also an http / REST API framework. To achieve maximum efficiency we decided to do everything event based and async, so there's plenty of opportunities to use lambdas and delegates." [1] [0] http://www.includeos.org/ http://www.includeos.org/ [1] https://cppcon2016.sched.org/event/d30a43dae4a490dce81a3dfc6dea5ce9 https://cppcon2016.sched.org/event/d30a43dae4a490dce81a3dfc6...
- wichtounet 10y ago
  Nice :) I didn't know this project. I'll definitely read about this project.
  - AlfredBratterud 10y ago
    I'm Alfred from IncludeOS. We're open source, so check us out on GitHub if you want to try IncludeOS or would like to participate: https://github.com/hioa-cs/IncludeOS https://github.com/hioa-cs/IncludeOS We also have a chat if you have any questions: https://gitter.im/hioa-cs/IncludeOS https://gitter.im/hioa-cs/IncludeOS
- kbenson 10y ago
  Is that really a "hard" choice? Aren't blocking POSIX calls usually just a case where the kernel blocks for you on what is essentially an asynchronous operation anyway? Maybe it's meant to be hard in the "we decided we weren't going to be POSIX compliant which has implications" send and not the hard to implement sense?
vertex-four 10y ago
Genode (essentially a microkernel abstraction layer, and some useful userland, a full Qt implementation and a reasonable UNIX-y layer) is entirely C++, with some C++ microkernels available for it (Fiasco.OC and Nova being the two I'm playing with).
pjmlp 10y ago
BeOS, Symbian, L4, Genode, Mac OS X drivers, and big parts of Windows are all examples of C++ use in OS development.
- pklausler 10y ago
  And there was Chorus back in the 90's.
- retro64 10y ago
  BeOS is the reason I learned C++. I don't recall exactly, but either I didn't understand how or there was no other option but C++ if one wanted to hit the BeOS API. Pity Be Inc. got shafted so bad by MS monopoly abuse. They had zero vendors willing to put their OS on a box and resell it because MS threatened the vendors with pulling their right to sell Windows if they did. This wasn't particular to Be, but to any other OS.
  - pjmlp 10y ago
    Yeah, still have my Be CDs stored somewhere. However regarding Microsoft, I actually think that vendors were as guilty as Microsoft. They could have chosen not to take Microsoft's discount and try to sell alternative OSes, even if it meant having to face a few challenges. The one that takes is as guilty as the one that gives.
    - retro64 10y ago
      I would have to really dig for the emails the company sent out (I should have them archived someplace), but I thought the issue wasn't discounts, but a revoking of the license to sell Windows if the OEMs didn't comply. I did a quick search and came up with Quora answer given here: https://www.quora.com/Why-was-the-BeOS-dropped https://www.quora.com/Why-was-the-BeOS-dropped but this doesn't jive with my memory. I will have to see if I can find an old email or maybe dig further on the net. I certainly don’t want to be rewriting history.
      - pjmlp 10y ago
notalaser 10y ago
I don't write OSes in modern C++ at the moment (most of my day job is embedded Linux nowadays, go figure...) but I've seen a lot of sane, OS-level C++ code. Even C++ code that I have bad memories about (uh, Symbian) is partly justifiable. The only real beef I have with C++ is its complexity. As I did less and less high-level programming, I forgot about many of C++'s pitfalls and nowadays I'm always tiptoeing when I have to write C++ code. I think a lot of it is unwarranted, or at least not needed when you're writing system-level code (but my impression may be distorted by the fact that I'm used to embedded systems and high-reliability applications; my sight may be narrow here). Edit -- oh, by the way: it's worth pointing out, in the context of a thread that mentions Torvalds' opinion on the matter, that the whole thing was written a while ago. The Internet endlessly recycles some of these arguments, e.g. STL still gets a lot of criticism that hasn't been true in a while. Yes, STL was terrible, terrible fifteen years ago, but that's, like, 50 years in computer years.
- PeCaN 10y ago
  The STL might be the best programming success story. It used to be awful, but now I rank it among the best standard libraries of any language.
  - gpderetta 10y ago
    that's because Stepanov named and shamed standard library and compilers implementors whose standard library wasn't compliant/fast enough.
monocasa 10y ago
I'm the maintainer of a proprietary C++14 RTOS for work. What do you want to know?
- roninb 10y ago
  I'm not OP, but I'm interested in the fact that you specified C++14. Are there any features specific to C++14 that you use? I have about two university classes worth of experience with low-level software, but I can really only see the deprecation attribute and binary literals being useful? All of the other language additions (added support for type deduction, templates, lambdas, and the mixing of all three to various degrees) seem like they would take up too many resources to be useful.
  - monocasa 10y ago
    We switched from C++11 to C++14 mainly for constexpr (it existed in 11, but had a lot of restrictions that limited it's usefulness). The advanced template techniques (and to a degree, I'm throwing type deduction in there too), when treated skeptically do lead to more efficient code. It's easy to go off the deep end though, which is why I said "when treated skeptically". As for lambdas, we have an entirely asynchronous OS, so they're really nice for callback glue. EDIT: Binary literals actually come up way less than you'd think, even for deeply embedded (I think the smallest thing we ship on currently is 16KB of RAM). Everyone here knows hex like the back of their hand.

tmptmp 10y ago

Yes, but his opinion counts more than some John Doe's as Linus supports his case with solid arguments.

gpderetta 10y ago
'It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C' Solid argument that. His two other arguments: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) Considering that the linux kernel is strongly tied to the specific C dialect supported by GCC and is not portable at all, this argument is bullshit. - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app. You can abstract yourself in a corner in C as well. In C++ you are more likely to pay less for abstractions. Sorry, but I take it personally when me and my colleagues are called substandard programmers.
- grive 10y ago
  > You can abstract yourself in a corner in C as well. It's much, much harder to do than in C++. It's also much more obvious when it happens, and in collaboration others will spot it quickly. His tone is harsh but I find it completely right. I prefer to use C at work exactly because the same kind of software would be an absolute nightmare to write in C++ (it is very low-level soft, extremely similar to kernel code). C++ is good if you can enforce very strict guidelines and if every single programmer that contributes to the code is very good at C++. Those are pretty big if, especially if you work with a partially open source codebase.
- TillE 10y ago
  As long as you avoid "virtual", I can't even think of any C++ features which would lead you towards worse performance characteristics than C. Templates may bloat your binary size and increase compile times, but they're plenty fast.