Live data from Hacker News

Should you Rust in embedded yet?

kazlauskas.me

31–40 of 119 posts

Re: Should you Rust in embedded yet?

#31
post #17
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++?

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 used in that way, tends to do a lot of things behind the scenes. This is perfectly okay in a place where you have an operating system and a linker that have your back. On an embedded system none of this is guaranteed.

Re: Should you Rust in embedded yet?

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

Many people need in memory databases and linked lists (or binary trees) to hash information and sort it.

There's a case to be made for an OO style program where I create an object and give it a chunk of memory to manage a B-tree, so I can keep my memory from being fragmented, but using C++ for that is serious overkill.

Re: Should you Rust in embedded yet?

#33
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…

Static initializers and templates are great in a deeply embedded context, IMO.

Re: Should you Rust in embedded yet?

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

RAII is absolutely killer. Managing real time priorities with lock_guards so that you can never forget to drop priority will win over almost any grizzly old firmware engineer.

Re: Should you Rust in embedded yet?

#35
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…

The borrow checker is not inherently about dynamic memory allocation. Heck, my toy x86_64 OS doesn't even have an allocator at all yet! Rust's features, including the borrow checker, are still useful here.

I really like https://os.phil-opp.com/page-tables/, for example, which talks about using Rust's type system to ensure safe page table usage.

Re: Should you Rust in embedded yet?

#36
post #21
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?

Sometimes. Usually you just write "normal" C, until you realise your single `sprintf` use took 20% of your ROM size. Or until you need some interrupt handler to take no more than N cycles. You probably don't switch to assembly at that point, but you definitely start checking what the compiler output is and where are the bytes/cycles wasted.

Actually writing assembly is more of a last resort time.

Re: Should you Rust in embedded yet?

#37

Earlier quoted context omitted.

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…

Static initializers and templates are great in a deeply embedded context, IMO.

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 realizing how this stuff really works underneath.

So, C++ can be a wonderful tool in proper hands, but it is much easier to misuse than C in an embedded context.

Re: Should you Rust in embedded yet?

#38

Earlier quoted context omitted.

Static initializers and templates are great in a deeply embedded context, IMO.

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.

Re: Should you Rust in embedded yet?

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

Even without dynamic memory there's ton of useful things:

Namespaces, References, collection types (std::array, string_view, intrusive containers, etc.), RAII (release mutexes at scope ends), strong typing, proper encapsulation, interfaces, etc.

Re: Should you Rust in embedded yet?

#40
post #7

One definition of "embedded" is: does the user treat it like an appliance or like a computer? If it's the former, it's 'embedded' even if it uses a reasonably powerful processor or does not have hard real time requirements. I use Erlang for that kind of thing and it works well. Rust is, I think, more performant, so if that works for you and what you need, go for it.

what do you think of nerves?
Post reply on HN