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

21–30 of 119 posts

Re: Should you Rust in embedded yet?

#21

Post by pknopf »

bb88 wrote: post #18
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…

> 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.

Ah, I forgot about the assembly.

Is assembly important in microcontrollers?

Re: Should you Rust in embedded yet?

#22

Post by pcein »

_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…

It is not just the borrow checker. The ownership system / move semantics and powerful static type system with traits and generics helps to create some interesting abstractions (which have very little run time overhead) - pleas check: http://blog.japaric.io/brave-new-io/ as well as other articles on that blog.

Re: Should you Rust in embedded yet?

#23

Post by jwhite »

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++?

Nothing. I've worked on Cortex-M4 projects in C++. It's nice in many ways. The people working on the project had a much more diverse background than the typical EE who learned C as an undergrad mentioned in another thread.

Re: Should you Rust in embedded yet?

#24

Post by bb88 »

Inityx wrote: post #19
bb88 wrote: post #14

Earlier quoted context omitted.

Here's a rant by Linus Torvalds. Take the politics and snark with a grain of salt. His technical arguments, however, are spot on. http://harmful.cat-v.org/software/c++/linus

I'm not sure how much water his argument here holds anymore. C++ has changed A LOT since 2007; idiomatic C++11 is an extremely different language from C++03, and C++20 is almost unrecognizable to an early C++ developer.

I bet you $5 if you ask him, he'd probably say the exact same thing.

Re: Should you Rust in embedded yet?

#25

Post by tarmon »

Analemma_ wrote: post #15
pknopf wrote: post #11

Earlier quoted context omitted.

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

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.

There is still a lot to be gained by strong typing even in projects where everything is statically allocated.

Re: Should you Rust in embedded yet?

#26

Post by q3k »

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++?

The standard library (with all its' duplicate code resulting from hardcore templating) will blow up your flash space usage significantly, to the point where you will run out of it sooner than you expect. You will spend time finding alternative standard libraries that are size-optimized and you might end up rewriting a lot of what you take for granted in your C++ daily usage. For example, the Arduino environment is C++-based, but it's not anything like on the desktop due to it not shipping an std:: .

Your typical heap-happy usage will not go down well on a microcontroller, either. Having very constrained RAM makes heap fragmentation much more of an issue.

Re: Should you Rust in embedded yet?

#27

Post by wallacoloo »

_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…

Also working in the same space. I had the opportunity to evaluate Rust for our development environment back in late September. The killer feature it offered us is serde - rust's general purpose SERializer DEserializer library.

So much of our code is centered around taking measurements with a bare metal system and then transmitting them to a linux box for processing. Being able to just write `#[derive(Serialize, Deserialize)]` above a struct and then be able to send/receive it across the channel via `rpmsg.send(mystruct)` or `let mystruct: MyStruct = rpmsg.recv()` is magic. Furthermore, by encapsulating each possible message type as an enum variant, match statements provide a really great way for dispatching the message to the appropriate handler after we deserialize it.

As for the borrow checker, I actually did find it useful in bare metal. But more for handling hardware resources. Different measurements require different sets of power supplies to be activated, and exclusive control over different I/Os, etc. The ownership model made it easier to ensure statically that we sequence the measurements in a way such that the different measurement routines can never reconfigure resources that are in use by a different routine.

Anyway, we sadly aren't using Rust yet in production, even after that. Holding off until we start the next product.

Re: Should you Rust in embedded yet?

#28

Post by jwhite »

Analemma_ wrote: post #15
pknopf wrote: post #11

Earlier quoted context omitted.

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

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.

Re: Should you Rust in embedded yet?

#29

Post by torn_pages »

pknopf wrote: post #21
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.

Ah, I forgot about the assembly. Is assembly important in microcontrollers?

I would say it does. I learned microcontroller programming in assembly before I learned about C.

Re: Should you Rust in embedded yet?

#30

Post by mikekchar »

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++.

It's more difficult. I used C++ in many projects for years and enjoyed working with it. You have to be very disciplined, though, and you need to know a lot about how it works under the hood to get it to play nicely, but it has it's niche. Embedded is not it's niche IMHO (and I've also done embedded, where we specifically chose to use C over C++).

Really, whenever you are doing any kind of embedded or real time project you are basically doing "resource limited development". The resource can be memory, I/O, CPU or any and all of that (or more). You need to be able to control exactly how it's used. C++ is often used to abstract you away from those things -- which is exactly the opposite of what you want.

C is a high-ish level language that is close enough to the metal that you can fairly easily understand the implications of what you are doing. C++ is not and it's incredibly easy to build a monstrocity that chews memory -- not just working memory, but application size too. Even dealing with name mangling is a surprising PITA when you are dealing with embedded -- remember embedded means you often have to build your own tools because nobody else is using your platform ;-).

Like I said, I actually like C++ (or at least C++ of a couple of decades ago -- the language seems to have changed a lot since I last used it, so it's hard for me to say). There are a lot of times where I simply don't care about controlling resources to that level. These days there are a lot of other choices and I'm not sure that I would ever choose C++ for a project again, but definitely back in the day it was something I reached for quite a bit.

WRT Rust, I agree with the OP that the borrow checker is really nice. I recently spent some time playing with Rust to see how easy it was to implement higher level abstractions. One of the things I was really impressed with was how hard Rust slaps you when you try to do something that would explode your memory footprint. It still feels a bit immature to me, but it has tremendous promise (and if you don't mind working around the immaturity, it's probably fine to use at the moment).

Post reply on HN