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

41–50 of 119 posts

Re: Should you Rust in embedded yet?

#41

Post by dmitrygr »

monocasa wrote: post #38
dmitrygr wrote: post #37

Earlier quoted context omitted.

For you yes, since you know how they are implemented at linker level. But get a few junior devs on your team, and you'll be wondering why hundreds of thousands of cycles run before main is called, or why some driver code is being entered before it is initialized, since someone decided to make a static singleton object for some driver and called some driver method in the constructor which will run before main(), not r…

I lead a team of six, including some junior devs. How initialization occurred (static or otherwise) was just something we made an explicit check off item in code review.

Awesome. Glad it worked out for you. I hope it stays so after you leave the team or no longer have time for each code review.

Re: Should you Rust in embedded yet?

#42

Post by Matthias247 »

_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 don't need dynamic memory to make a ton of memory errors. There's still lots of possibilities to have dangling pointers to somewhere else on the stack, memory issues with objects pools, memory issues due to race conditions in multitasked RTOS systems, etc.

On top of those there's misunderstandings whether a char* is actually a pointer or an array, misunderstandings who knows those, etc.

I've seen enough of these issues in an RTOS project to believe that Rust (and even modern C++) will be a huge step up in overall quality and productivity.

Re: Should you Rust in embedded yet?

#43

Post by Matthias247 »

wallacoloo wrote: post #27
_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, Deser…

What data format do you use with Serde on embedded? JSON? I read somewhere that Serde works in no-std environments, but wasn't sure whether it does that with all possible data formats.

Re: Should you Rust in embedded yet?

#44

Post by pcwalton »

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

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 of language and standard library features: closures, iterators, a real string library, a vector type, hash tables in libstd, better unit testing support, etc. Development speed can affect time to market.

As the industry matures, though, reliability generally becomes more important. And "embedded" covers everything from IoT light bulbs (correctness less important…for now) to avionics (correctness extremely important).

Re: Should you Rust in embedded yet?

#46

Post by shakna »

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

A lot of people do. But they may as well not. They tend to write C-style C++.

Simply put, because you can't use the STL, or a lot of other C++ features, or only with a lot of consideration.

A whole swathe of the embedded world still cares about program size in bytes. There are some that don't, but they tend to be using Linux, and are at a higher abstraction level than many others in the industry. (Industry is kinda divided in half. Those who use tiny Linux machines, and those working with microcontrollers. It's a generalization, but generally fits.)

The stuff I work on day-to-day, usually has between 1-4kb for dynamic memory, and 8-16kb for the compiled program. That line is also usually a bit blurry, and you can move things between both at runtime, but at various costs.

With C++, you get tempted to use stuff like vector, which can blow your memory stack.

I generally work with C++, but it looks like C. I get a few things like implicit pointers, for free, but generally still have to end up making most things explicit.

But, unlike twenty years ago, I no longer have to dive into assembly unless the project is pushing it's limits. The compiler tends to be "good enough".

Re: Should you Rust in embedded yet?

#47

Post by scottlamb »

bb88 wrote: post #24
Inityx wrote: post #19

Earlier quoted context omitted.

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.

He writes C++ now, so I imagine he'd say the language has its place. https://en.wikipedia.org/wiki/Subsurface_(software) (He'd probably still say C++ is inappropriate for the Linux kernel, though.)

Re: Should you Rust in embedded yet?

#48

Post by bb88 »

scottlamb wrote: post #47
bb88 wrote: post #24

Earlier quoted context omitted.

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

He writes C++ now, so I imagine he'd say the language has its place. https://en.wikipedia.org/wiki/Subsurface_(software) (He'd probably still say C++ is inappropriate for the Linux kernel, though.)

I was going to honor my bet here, until I did a little googling and found this during the discussion of when they ported subsurface to Qt.

"A word of warning: Linus has very strong feelings about all the things that are wrong with C++ and at times has been known to be less diplomatic than me when explaining his point of view... :-) But he made a clear statement that he is interested in seeing this port happening, as long as most of the program logic that is not UI code stays in (quote) "sane C files". So please keep that in mind as we drive this further."

http://lists.subsurface-divelog.org/pipermail/subsurface/201...

Re: Should you Rust in embedded yet?

#49

Post by shaklee3 »

pcwalton wrote: post #44
_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…

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…

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

Re: Should you Rust in embedded yet?

#50

Post by bleke »

dmitrygr wrote: post #31
pknopf wrote: post #17

Earlier quoted context omitted.

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

It really depends how you use it. If you are approaching from the standpoint of "I am writing code on a microcontroller", which means no exceptions, no static initializers, probably no templates, definitely no rtti, then it will be all okay. If you approach it from the standpoint of "I'm just programming, how hard could it be? Let's just use std::", you're going to have a very bad time and very quickly. C++, when use…

note, static initializers works in embedded you need to execute functions between __init_array_start and __init_array_end before using any static object in gcc somewhere in program
Post reply on HN