4 ms·

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

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.

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.