14 ms·

> the fact that it's been used in a place where it can show it's potential And more importantly, a place where C++ has failed.

by gnull 5y ago

brundolf 5y ago
Do you have specific knowledge of how C++ tried and failed to apply to this usecase?
- gnull 5y ago
  Even though neither Rust nor C++ are supported Kernel languages, Rust has passed a few iterations of trial and discussion, C++ on the other hand was filtered out at the first one. Linus refused to even take C++ seriously (and also mentioned trying it for Kernel in 1992) [1]. Some might argue this doesn't qualify as "C++ trying", but I think it does. [1]: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
  - bsdubernerd 5y ago
    I've been programming on embedded with c++ for quite a while and I really can't agree with linus here. Just the superior type checking, being able to use RAII and simple templates to replace macros completely transform the way you work on a fundamental level without doing anything fancy. Although it's not as pleasant as it should be given its historical baggage (the bad rap is sadly well deserved), I still consider it to be miles ahead of C for embedded work to the point that while I do like Rust a lot, I still consider it to be overhyped in this area.
    - slaymaker1907 5y ago
      My main complaints about C++ are lack of a good way to catch all exceptions and mysterious copying/conversions. In Rust, it is very easy to catch all panics and conversion/cloning is explicit. Copy is only implemented for types where copying is actually cheap/free by convention. Another good thing to look at is how disgusting std::move is and how straight forward the equivalent is in Rust. Additionally, there isn't anything to prevent you from using some variable where you used std::move (which invalidates the contents of said variable). Rust will not allow you to use some variable if ownership has moved. Finally, I personally despise that you end up needing so many constructors in C++ just to do basic things like the assignment operator.
      - bsdubernerd 5y ago
        Agree on most points. I never truly liked how complex C++ was from day 1, and it definitely got more and more complex over time. I'm using cppreference all the time, which is something I feel I shouldn't need. I also think the C++ i/o library is utter garbage too. However I also think how we got to the modern C++ standard, and how early we are with Rust. I think of all the weird C++ features I had to use over time in embedded, and I'm glad I always had the option to have manual control over memory sizing, the ability to alias pointers and everything that you normally wouldn't want or consider unsafe. I also think of Rust and this hell-bent approach to memory safety, and actually think that on embedded I basically never have dynamic memory allocation, and very rarely have issues with ownership that I could solve nicely (without fighting with the very limited lifetime constraints we can have) with Rust. On small targets there is no memory allocation. There's often no copying at all, because it's too expensive: ids and counters are often exchanged over shared buffers. What I feel is a massive improvement in terms of safety in embedded are state machine compilers more than memory safety. Think "ragel", or similar compilers. Using these in embedded couple with wither C or C++ is a game-changer. Memory safety and pointer lifetimes start to be an issue with much bigger targets. I don't have experience with kernel development, but if you can run linux on a platform I would hardly call it "embedded". Or at the very least, we're talking about the very high-end embedded platforms.
    - brundolf 5y ago
      The way I see it, C heavily discourages powerful abstractions. Rust encourages them, but allows contracts between them to be tightly constrained and safe. C++ encourages them, but doesn't give you much help making them constrained or safe. When it comes to being careful and intentional, C++ is the worst of both worlds. I think Linus was wise not to empower people to write shaky abstractions in one of the world's a) largest and b) most important low-level codebases.
    - caskstrength 5y ago
      I don't know about embedded, but I'm quite happy with Linus' decision and appreciate that I can compile kernel on my laptop in reasonable amount of time.
      - pjmlp 5y ago
        Just wait until Rust starts being used across the kernel, if compilation speed is an issue. At least with C++ most corporations actually use binary libraries, we aren't doing Gentoo style across our codebases.
        caskstrength 5y ago
        > Just wait until Rust starts being used across the kernel, if compilation speed is an issue. I don't expect people to start (re)writing their drivers in Rust anytime soon. Maybe some PoC things and stray FAANG-devs aiming for promotions, but it is highly unlikely I will need to have those drivers enabled. Hope Rust compilation times improve by the time it becomes mainstream in systems. > At least with C++ most corporations actually use binary libraries, we aren't doing Gentoo style across our codebases. This is not relevant for the kernel development (Linus' case) and doesn't match my experience working with C++ code bases for ~10 years.
    - xondono 5y ago
      A lot of the problems that tend to be ignored when talking about embedded C++ come from the fact that we have good C++ compilers for embedded targets now. This was certainly not the case just a few years ago, especially before ARM was the de-facto standard for embedded devices. Most MCUs compilers had little if any support for most C++ "fanciness", which meant that trying out C++ ended almost always in some big catastrophe, either by hidden bugs being inserted by those compilers, or portability disasters (+80% your supposedly portable code uses this feature that compiler X doesn't have).
      - bsdubernerd 5y ago
        True. I'm old enough that I had these issues with C++ in the early 2000 even with _system_ compilers (AIX's C++ compiler was especially horrifying). However times have changed. The features and C++ general coding style itself is quite different that what you'd write in '98. If you're considering Rust, you should consider the modern available C++ with all the latest tooling to be fair. And it's _pretty_ good, all things considered.
  - moron4hire 5y ago
    C++ has evolved a lot in the THIRTY years that have (almost) passed since 1992.
    - xedrac 5y ago
      Yes, it grew 30+ new appendages. Jokes aside, it has improved quite a bit with lambdas, move semantics, type inference, standardized filesystem api, smart pointers, optional types, etc... Despite this, it still can't come close to offering the confidence that Rust gives you.
      - brundolf 5y ago
        The most important trait of a language, especially when safety is a high concern, is what it doesn't let you do. And it's virtually impossible to improve on that axis down the line while maintaining backwards-compatibility, which means that ship has sailed for C++ no matter what new features get added.
        pjmlp 5y ago
        True, yet despite all security talk, Google, Apple and Microsoft rather improve C and C++ instead of just throwing away 50 years of libraries, OS code and GPGPU tooling. So while I enjoy doing toy applications in Rust, C++ is the language I have available on the IDE installer to write native code on our projects. Until Rust manages to get a similar checkbox on the same installer, it isn't going to be an option for certain kinds of corporations.
    - blippage 5y ago
      A few years ago I tried out VC++ version 4 (??) for a bit of a laugh. And I felt no wonder as to why C++ got such a bad wrap. The MFC classes seemed to have suffered from gold-plating the specifications, and there was all sorts of casting stuff to cajole C++ into interfacing with the C windowing system. Since then, C++ has gotten massively better. We now have strings and vectors as part of the standard library, so there's no need to use someone's quirky implementation. As I said in a previous post, C++ gets you most of the way to Python, so there's really no point in not using it. Still, it's taken us until C++17 to get sum-types (via variants), and it is amazing to think that it took so long to get such a basic idea included. The handling of variants could do with a bit of simplification, mind. And I'd do wish they could implement the equivalent of "typeclasses", enabling recursive data structures. I'm a big C++ fan, in case that wasn't clear.
  - pjmlp 5y ago
    When the author has religious hate against a specific language, there is nothing to try. There are other platforms that have embraced C++, both of them run on my pocket.
- schuyler2d 5y ago
  At the least, it's failed to pique Linus's interest. He's re-affirmed his disinterest in C++ in this mailing thread again[1]: > You'd have to get rid of some of the complete garbage from C++ for it to be usable. > One of the trivial ones is "new" - not only is it a horribly stupid namespace violation, but it depends on exception handling that isn't viable for the kernel, so it's a namespace violation that has no upsides, only downsides. > Could we fix it with some kind of "-Dnew=New" trickery? Yes, but considering all the other issues, it's just not worth the pain. C++ is simply not a good language. It doesn't fix any of the fundamental issues in C (ie no actual safety), and instead it introduces a lot of new problems due to bad designs. [1] https://lore.kernel.org/ksummit/CAHk-=wiwZWAo_Ki587FD2BrAQVK71TBN=uKimdBf1Pxg3=+nTw@mail.gmail.com/ https://lore.kernel.org/ksummit/CAHk-=wiwZWAo_Ki587FD2BrAQVK...
  - tialaramex 5y ago
    The exception handling thing is a showstopper. Stroustrup is resolute that C++ style exception handling is the right error model. So even if a big fraction of C++ programmers disagree, the ISO C++ language standard, and the guidance for new developers, is going to keep saying Exceptions are the way forward for the foreseeable future. Linus didn't like the panic-on-fail memory allocation handling from userspace Rust for the same reason and so the kernel Rust people had to be very clear early on that was temporary and wouldn't survive from a prototype into the actual kernel. There are some edge cases where this is surprising and I expect Linus will ask for further work. e.g. let x = "Clowns".to_owned(); let mut y = x + " are not welcome here"; y += " any more."; The first variable ends up with a growable String, containing the word "Clowns" so that's an allocation and it might fail, in userspace it panics, in kernel Rust should this not compile? If it needs to "return an error" how? The second line needs a concatenation operation, it won't end up with a new String, the old one gets moved instead (in Rust this means if you try to refer to x after this that won't compile, it was moved and the compiler knows that) but it also gets a concatenation to add this extra string to the end, probably allocating again. Thus it too might fail, in userspace that would panic, but in the kernel what happens this time? Does this Add operator have a Result type now? The third line concatenates again, but this time the operation doesn't even have a return type, it's obliged to mutate y, so there is just no possible way it can result in an error. Either this mustn't happen in the Linux kernel, or it panics when it can't allocate. Whereas these are all fine, they don't allocate and aren't writeable so they won't bother Linus: let x = "Clowns"; // A str, definitely UTF-8 encoded let y = b"\xf7\xf7\xf7"; // not Unicode, just some bytes let z = r#"No need to "escape" the double quotes now."#;
LoveLeadAcid 5y ago
Did you used to work for Mozilla before they fired all the Rustaceans?
pjmlp 5y ago
Only on Linux due to Linus religious hate more specifically, C++ managed alright on Windows, macOS, BeOS, Symbian, GenodeOS, Mbed, Android Treble drivers, Arduino, AUTOSAR.
- raverbashing 5y ago
  Well yes. But Linus is right on that one. I wouldn't say Windows drivers were C++, more like "C with Classes" (and maybe a little bit C++) Also, Windows drivers are usually much more convoluted than Linux drivers https://github.com/microsoft/Windows-driver-samples https://github.com/microsoft/Windows-driver-samples
  - pjmlp 5y ago
    Linus is only right for those that share the same opinion. Anything that uses 1% of C++ specific features is C++. C as used by Linux kernel is not ISO C, yet no one argues it isn't C.
    - raverbashing 5y ago
      > Anything that uses 1% of C++ specific features is C++. Technically correct and this raises an important point. How long would the kernel take to compile in C++ versus in C? Though in practice if you think the kernel should support all the craziness of "modern" C++ you're going to have a big problem in making it work in kernel space. (things like heavy templates, etc) And just to disagree with Linus I think the 'new' part is the least of our problems in making the kernel work with C++
      - pjmlp 5y ago
        Apple, Google and Microsoft do just fine without modern C++ craziness in kernel and drivers. As for compilation times, it is all a matter of how the build system is architected. Most of my C++ build pipelines compile faster than Rust, in make clean all scenarios. There is no black magic in how to achieve it, just knowing what one is doing, making use of binary libraries, build caches, and be aware of how much craziness is allowed, most of which wouldn't be allowed on the kernel anyway.
blub 5y ago
Rooting for others to fail instead of one's own success is a recipe for always being miserable. In this case it's also logically dubious, because we have no idea how C++ would work in a Linux kernel - it was never tried.
- drran 5y ago
  C++, python, basic, or JS can work in kernel. For example, Click modular router for Linux kernel is written in C++: https://github.com/pbuonado/click/blob/master/linuxmodule/module.cc https://github.com/pbuonado/click/blob/master/linuxmodule/mo...

> the fact that it's been used in a place where it can show it's potential And more importantly, a place where C++ has failed.

by gnull 5y ago

> the fact that it's been used in a place where it can show it's potential And more importantly, a place where C++ has failed.

brundolf 5y ago

Do you have specific knowledge of how C++ tried and failed to apply to this usecase?

gnull 5y ago
Even though neither Rust nor C++ are supported Kernel languages, Rust has passed a few iterations of trial and discussion, C++ on the other hand was filtered out at the first one. Linus refused to even take C++ seriously (and also mentioned trying it for Kernel in 1992) [1]. Some might argue this doesn't qualify as "C++ trying", but I think it does. [1]: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
- bsdubernerd 5y ago
  I've been programming on embedded with c++ for quite a while and I really can't agree with linus here. Just the superior type checking, being able to use RAII and simple templates to replace macros completely transform the way you work on a fundamental level without doing anything fancy. Although it's not as pleasant as it should be given its historical baggage (the bad rap is sadly well deserved), I still consider it to be miles ahead of C for embedded work to the point that while I do like Rust a lot, I still consider it to be overhyped in this area.
  - slaymaker1907 5y ago
    My main complaints about C++ are lack of a good way to catch all exceptions and mysterious copying/conversions. In Rust, it is very easy to catch all panics and conversion/cloning is explicit. Copy is only implemented for types where copying is actually cheap/free by convention. Another good thing to look at is how disgusting std::move is and how straight forward the equivalent is in Rust. Additionally, there isn't anything to prevent you from using some variable where you used std::move (which invalidates the contents of said variable). Rust will not allow you to use some variable if ownership has moved. Finally, I personally despise that you end up needing so many constructors in C++ just to do basic things like the assignment operator.
    - bsdubernerd 5y ago
      Agree on most points. I never truly liked how complex C++ was from day 1, and it definitely got more and more complex over time. I'm using cppreference all the time, which is something I feel I shouldn't need. I also think the C++ i/o library is utter garbage too. However I also think how we got to the modern C++ standard, and how early we are with Rust. I think of all the weird C++ features I had to use over time in embedded, and I'm glad I always had the option to have manual control over memory sizing, the ability to alias pointers and everything that you normally wouldn't want or consider unsafe. I also think of Rust and this hell-bent approach to memory safety, and actually think that on embedded I basically never have dynamic memory allocation, and very rarely have issues with ownership that I could solve nicely (without fighting with the very limited lifetime constraints we can have) with Rust. On small targets there is no memory allocation. There's often no copying at all, because it's too expensive: ids and counters are often exchanged over shared buffers. What I feel is a massive improvement in terms of safety in embedded are state machine compilers more than memory safety. Think "ragel", or similar compilers. Using these in embedded couple with wither C or C++ is a game-changer. Memory safety and pointer lifetimes start to be an issue with much bigger targets. I don't have experience with kernel development, but if you can run linux on a platform I would hardly call it "embedded". Or at the very least, we're talking about the very high-end embedded platforms.
  - brundolf 5y ago
    The way I see it, C heavily discourages powerful abstractions. Rust encourages them, but allows contracts between them to be tightly constrained and safe. C++ encourages them, but doesn't give you much help making them constrained or safe. When it comes to being careful and intentional, C++ is the worst of both worlds. I think Linus was wise not to empower people to write shaky abstractions in one of the world's a) largest and b) most important low-level codebases.
  - caskstrength 5y ago
    I don't know about embedded, but I'm quite happy with Linus' decision and appreciate that I can compile kernel on my laptop in reasonable amount of time.
    - pjmlp 5y ago
      Just wait until Rust starts being used across the kernel, if compilation speed is an issue. At least with C++ most corporations actually use binary libraries, we aren't doing Gentoo style across our codebases.
      - caskstrength 5y ago
        > Just wait until Rust starts being used across the kernel, if compilation speed is an issue. I don't expect people to start (re)writing their drivers in Rust anytime soon. Maybe some PoC things and stray FAANG-devs aiming for promotions, but it is highly unlikely I will need to have those drivers enabled. Hope Rust compilation times improve by the time it becomes mainstream in systems. > At least with C++ most corporations actually use binary libraries, we aren't doing Gentoo style across our codebases. This is not relevant for the kernel development (Linus' case) and doesn't match my experience working with C++ code bases for ~10 years.
  - xondono 5y ago
    A lot of the problems that tend to be ignored when talking about embedded C++ come from the fact that we have good C++ compilers for embedded targets now. This was certainly not the case just a few years ago, especially before ARM was the de-facto standard for embedded devices. Most MCUs compilers had little if any support for most C++ "fanciness", which meant that trying out C++ ended almost always in some big catastrophe, either by hidden bugs being inserted by those compilers, or portability disasters (+80% your supposedly portable code uses this feature that compiler X doesn't have).
    - bsdubernerd 5y ago
      True. I'm old enough that I had these issues with C++ in the early 2000 even with _system_ compilers (AIX's C++ compiler was especially horrifying). However times have changed. The features and C++ general coding style itself is quite different that what you'd write in '98. If you're considering Rust, you should consider the modern available C++ with all the latest tooling to be fair. And it's _pretty_ good, all things considered.
- moron4hire 5y ago
  C++ has evolved a lot in the THIRTY years that have (almost) passed since 1992.
  - xedrac 5y ago
    Yes, it grew 30+ new appendages. Jokes aside, it has improved quite a bit with lambdas, move semantics, type inference, standardized filesystem api, smart pointers, optional types, etc... Despite this, it still can't come close to offering the confidence that Rust gives you.
    - brundolf 5y ago
      The most important trait of a language, especially when safety is a high concern, is what it doesn't let you do. And it's virtually impossible to improve on that axis down the line while maintaining backwards-compatibility, which means that ship has sailed for C++ no matter what new features get added.
      - pjmlp 5y ago
        True, yet despite all security talk, Google, Apple and Microsoft rather improve C and C++ instead of just throwing away 50 years of libraries, OS code and GPGPU tooling. So while I enjoy doing toy applications in Rust, C++ is the language I have available on the IDE installer to write native code on our projects. Until Rust manages to get a similar checkbox on the same installer, it isn't going to be an option for certain kinds of corporations.
  - blippage 5y ago
    A few years ago I tried out VC++ version 4 (??) for a bit of a laugh. And I felt no wonder as to why C++ got such a bad wrap. The MFC classes seemed to have suffered from gold-plating the specifications, and there was all sorts of casting stuff to cajole C++ into interfacing with the C windowing system. Since then, C++ has gotten massively better. We now have strings and vectors as part of the standard library, so there's no need to use someone's quirky implementation. As I said in a previous post, C++ gets you most of the way to Python, so there's really no point in not using it. Still, it's taken us until C++17 to get sum-types (via variants), and it is amazing to think that it took so long to get such a basic idea included. The handling of variants could do with a bit of simplification, mind. And I'd do wish they could implement the equivalent of "typeclasses", enabling recursive data structures. I'm a big C++ fan, in case that wasn't clear.
- pjmlp 5y ago
  When the author has religious hate against a specific language, there is nothing to try. There are other platforms that have embraced C++, both of them run on my pocket.
schuyler2d 5y ago
At the least, it's failed to pique Linus's interest. He's re-affirmed his disinterest in C++ in this mailing thread again[1]: > You'd have to get rid of some of the complete garbage from C++ for it to be usable. > One of the trivial ones is "new" - not only is it a horribly stupid namespace violation, but it depends on exception handling that isn't viable for the kernel, so it's a namespace violation that has no upsides, only downsides. > Could we fix it with some kind of "-Dnew=New" trickery? Yes, but considering all the other issues, it's just not worth the pain. C++ is simply not a good language. It doesn't fix any of the fundamental issues in C (ie no actual safety), and instead it introduces a lot of new problems due to bad designs. [1] https://lore.kernel.org/ksummit/CAHk-=wiwZWAo_Ki587FD2BrAQVK71TBN=uKimdBf1Pxg3=+nTw@mail.gmail.com/ https://lore.kernel.org/ksummit/CAHk-=wiwZWAo_Ki587FD2BrAQVK...
- tialaramex 5y ago
  The exception handling thing is a showstopper. Stroustrup is resolute that C++ style exception handling is the right error model. So even if a big fraction of C++ programmers disagree, the ISO C++ language standard, and the guidance for new developers, is going to keep saying Exceptions are the way forward for the foreseeable future. Linus didn't like the panic-on-fail memory allocation handling from userspace Rust for the same reason and so the kernel Rust people had to be very clear early on that was temporary and wouldn't survive from a prototype into the actual kernel. There are some edge cases where this is surprising and I expect Linus will ask for further work. e.g. let x = "Clowns".to_owned(); let mut y = x + " are not welcome here"; y += " any more."; The first variable ends up with a growable String, containing the word "Clowns" so that's an allocation and it might fail, in userspace it panics, in kernel Rust should this not compile? If it needs to "return an error" how? The second line needs a concatenation operation, it won't end up with a new String, the old one gets moved instead (in Rust this means if you try to refer to x after this that won't compile, it was moved and the compiler knows that) but it also gets a concatenation to add this extra string to the end, probably allocating again. Thus it too might fail, in userspace that would panic, but in the kernel what happens this time? Does this Add operator have a Result type now? The third line concatenates again, but this time the operation doesn't even have a return type, it's obliged to mutate y, so there is just no possible way it can result in an error. Either this mustn't happen in the Linux kernel, or it panics when it can't allocate. Whereas these are all fine, they don't allocate and aren't writeable so they won't bother Linus: let x = "Clowns"; // A str, definitely UTF-8 encoded let y = b"\xf7\xf7\xf7"; // not Unicode, just some bytes let z = r#"No need to "escape" the double quotes now."#;

LoveLeadAcid 5y ago

Did you used to work for Mozilla before they fired all the Rustaceans?

pjmlp 5y ago

Only on Linux due to Linus religious hate more specifically, C++ managed alright on Windows, macOS, BeOS, Symbian, GenodeOS, Mbed, Android Treble drivers, Arduino, AUTOSAR.

raverbashing 5y ago
Well yes. But Linus is right on that one. I wouldn't say Windows drivers were C++, more like "C with Classes" (and maybe a little bit C++) Also, Windows drivers are usually much more convoluted than Linux drivers https://github.com/microsoft/Windows-driver-samples https://github.com/microsoft/Windows-driver-samples
- pjmlp 5y ago
  Linus is only right for those that share the same opinion. Anything that uses 1% of C++ specific features is C++. C as used by Linux kernel is not ISO C, yet no one argues it isn't C.
  - raverbashing 5y ago
    > Anything that uses 1% of C++ specific features is C++. Technically correct and this raises an important point. How long would the kernel take to compile in C++ versus in C? Though in practice if you think the kernel should support all the craziness of "modern" C++ you're going to have a big problem in making it work in kernel space. (things like heavy templates, etc) And just to disagree with Linus I think the 'new' part is the least of our problems in making the kernel work with C++
    - pjmlp 5y ago
      Apple, Google and Microsoft do just fine without modern C++ craziness in kernel and drivers. As for compilation times, it is all a matter of how the build system is architected. Most of my C++ build pipelines compile faster than Rust, in make clean all scenarios. There is no black magic in how to achieve it, just knowing what one is doing, making use of binary libraries, build caches, and be aware of how much craziness is allowed, most of which wouldn't be allowed on the kernel anyway.

blub 5y ago

Rooting for others to fail instead of one's own success is a recipe for always being miserable. In this case it's also logically dubious, because we have no idea how C++ would work in a Linux kernel - it was never tried.

drran 5y ago
C++, python, basic, or JS can work in kernel. For example, Click modular router for Linux kernel is written in C++: https://github.com/pbuonado/click/blob/master/linuxmodule/module.cc https://github.com/pbuonado/click/blob/master/linuxmodule/mo...