Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should you Rust in embedded yet?

kazlauskas.me

Post reply on HN
Print view View original

61–70 of 119 posts

Re: Should you Rust in embedded yet?

#61

Post by tluyben2 »

pknopf wrote: post #11
_sh wrote: post #9

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (t…

Why is C king? Why not C++? The difference is just a compiler, and you can use C in C++.

I find it easier to use C and assembly on very constrained devices becauee I know what the output will be; with C++ it is less clear. If you write code that has to fit in 24kb, you need to think about what every instruction looks like after compilation and that just is far easier with C and (obviously) asm in my experience.

Re: Should you Rust in embedded yet?

#62

Post by mtgx »

wiremine wrote: post #2

Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to s…

Time to start lobbying Arm. For instance, I think we already missed a big opportunity to have Arm develop its Firmware-M in Rust. That firmware is going to be used by billions of IoT devices in the future. Although I'm sure Arm is trying to make the C code as safe as possible, at that scale there will be plenty of bugs, especially since OEMs will get to use customized versions of it, too.

https://developer.arm.com/products/architecture/platform-sec...

Re: Should you Rust in embedded yet?

#63

Post by vardump »

ShroudedNight wrote: post #54
bb88 wrote: post #18

Earlier quoted context omitted.

> C is king because the industry is currently dominated by people who have been doing this since before C++ was a thing. No. If C++ were a great language those C coders would have moved over in an instant. One of the advantages of looking at C code is that you can actually figure out in your head what the assembly will look like.

> One of the advantages of looking at C code is that you can actually figure out in your head what the assembly will look like. One can do this with most C++ too. Though admittedly, non-tree virtual inheritance hierarchies, as well as member function pointers [et al] make this harder to achieve universally. I will also admit that it's easier to do with C. If the optimizer gets its hands on either though, you may be i…

C++ extra object copies can sometimes be pretty difficult to see without checking disassembler listing.

Re: Should you Rust in embedded yet?

#64

Post by carlmr »

_sh wrote: post #9

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (t…

You might want to check out https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h..., it goes into other types of concurrency in Rust, some probably more interesting to embedded devs than the general dynamic allocation stuff. The key takeaway is that the borrow checker isn't only good for dynamic memory allocation in GCless environments (in general even the stack allocated variables which we have in embedded profit from the borrow checker).

The other thing is that Rust offers a lot of very useful abstractions (e.g. enums with data) and a strong type system, which is sorely lacking for C.

The embedded systems industry is one of the slowest industries to adopt to new technologies, so I'm not holding my breath, but I think everything is there in Rust to make it a good embedded language.

Re: Should you Rust in embedded yet?

#65

Post by carlmr »

jwhite wrote: post #28
Analemma_ wrote: post #15

Earlier quoted context omitted.

I’m not an embedded developer, but my guess is that if they’re not even using dynamic memory, I doubt they need or want anything that C++ has to offer.

That's more a matter of experience and attitude -- even simple things like reference types are nice. Also, templates offer a lot of abstraction power that can be used to model the hardware nicely, without sacrificing efficiency. Many embedded programmers come from a background that doesn't expose them to those sorts of ideas though.

Can confirm, C++ has some nice features which I'd even like without malloc. OTOH I'm already horrified at the code quality problems pretty much every embedded shop faces. C++ would only make this matter worse.

As a software inclined embedded guy I also often think of what would be possible if we switched to C++. But then I think of what's probable.

Re: Should you Rust in embedded yet?

#66

Post by carlmr »

mtgx wrote: post #62
wiremine wrote: post #2

Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to s…

Time to start lobbying Arm. For instance, I think we already missed a big opportunity to have Arm develop its Firmware-M in Rust. That firmware is going to be used by billions of IoT devices in the future. Although I'm sure Arm is trying to make the C code as safe as possible, at that scale there will be plenty of bugs, especially since OEMs will get to use customized versions of it, too. https://developer.arm.com/pr…

The last time I used ARM supplied drivers they were nice to get things started quickly, but they were of terrible quality (at least for the smaller Cortex M microcontrollers).

Re: Should you Rust in embedded yet?

#67

Post by andromeduck »

reificator wrote: post #56
shaklee3 wrote: post #49

Earlier quoted context omitted.

You should be comparing to c++ and not c, since if you are looking for those features, you'll find them.

Embedded systems typically doesn't use C++ either. I think it's still a fair comparison.

In my experience is usually a mix of both.

Re: Should you Rust in embedded yet?

#68

Post by unwind »

throwaway84742 wrote: post #58
pcwalton wrote: post #44

Earlier quoted context omitted.

Just that Rust is known for its borrow checker doesn't mean that the borrow checker is the only type of safety that Rust offers. The old standbys are still valuable: bounds checks, null pointers, compile-time data race detection. > Pragmatism reigns: time-to-market and a cheap BoM are the main metrics, programming language a distant 10th. I find that I can develop software faster with Rust than with C, simply because…

Null pointer is actually perfectly fine on bare metal. There’s no memory protection, so it just points to address 0x0, and if you deref it nothing bad will happen.

This is not true at all.

First, of course, there is no requirement for NULL to map to address zero.

Second even if you do en uo there, many architectures don't even have memory at 0x0. Spurious writes are spurious writes regardless of whether or not you get a fault. You are still not doing what you want to be doing.

Re: Should you Rust in embedded yet?

#69

Post by arcticbull »

throwaway84742 wrote: post #58
pcwalton wrote: post #44

Earlier quoted context omitted.

Just that Rust is known for its borrow checker doesn't mean that the borrow checker is the only type of safety that Rust offers. The old standbys are still valuable: bounds checks, null pointers, compile-time data race detection. > Pragmatism reigns: time-to-market and a cheap BoM are the main metrics, programming language a distant 10th. I find that I can develop software faster with Rust than with C, simply because…

Null pointer is actually perfectly fine on bare metal. There’s no memory protection, so it just points to address 0x0, and if you deref it nothing bad will happen.

In many ways I would say a non-faulting non-protected read or write from 0x0 is worse than a crashing protected read.

Re: Should you Rust in embedded yet?

#70

Post by Animats »

pknopf wrote: post #17
Inityx wrote: post #16

Earlier quoted context omitted.

C is king because the industry is currently dominated by people who have been doing this since before C++ was a thing. Additionally, most of these people are primarily electrical engineers, and don't have as strong of a background in computer science. They've been using C for decades and it does everything they want, why would they take the time to learn the boundless complexity introduced by a language that offers t…

Let me ask it this way: I'm a higher level programmer. Later in my career I happen to get down to microcontrollers, what would stop me from using C++?

Not much. The Arduino programming environment is really gcc in C++ mode, but a different library.
Post reply on HN