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

111–119 of 119 posts

Re: Should you Rust in embedded yet?

#111

Post by pjmlp »

bb88 wrote: post #109
pjmlp wrote: post #92

Earlier quoted context omitted.

Modern C++ does just fine on a Commodore C64. CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” https://www.youtube.com/watch?v=zBkNBP00wJE

Sad that it took C++ almost 40 years to get there.

I was doing C++ development on MS-DOS already in the 90's.

Never cared for C beyond using it in Turbo C 2.0 for MS-DOS, and later when required to use it for university projects and client projects that explicitly required ANSI C89.

So it wasn't 64 KB, but it was perfectly usable on 640 KB systems.

The main problem has always been fighting misconceptions.

Re: Should you Rust in embedded yet?

#112

Post by pjmlp »

bb88 wrote: post #110
pjmlp wrote: post #55

Earlier quoted context omitted.

Only when compiling without any kind of optimizations, nor using vector instructions. In any case, C++ is copy-paste compatible with 99% of C89. So same benefits apply when using that subset. It is plain language religion as observed at a few C++ conference talks.

I think you're not giving engineers enough credit here. The world moved from C++ to Java on the enterprise side back in the late 1990's. Why? Java was arguably faster and easier to develop in, even though many thought (including me) that C++ was technically a better language.

So, I will let one of the renowned experts speak instead.

CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”

https://www.youtube.com/watch?v=D7Sd8A6_fYU

Embedded Development with Dan Saks

http://cppcast.com/2016/10/dan-saks/

Regarding Java vs C++, yes the enterprise world has adopted Java, however as someone doing consulting across Java, .NET and C++, I am really seeing it coming back since ANSI C++ has picked up steam again.

I see it in projects related to IoT, AI, VR, big data,....

They are all polyglot projects with C++ plus something else, not C plus something else.

Re: Should you Rust in embedded yet?

#113

Post by freeone3000 »

pjmlp wrote: post #112
bb88 wrote: post #110

Earlier quoted context omitted.

I think you're not giving engineers enough credit here. The world moved from C++ to Java on the enterprise side back in the late 1990's. Why? Java was arguably faster and easier to develop in, even though many thought (including me) that C++ was technically a better language.

So, I will let one of the renowned experts speak instead. CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++” https://www.youtube.com/watch?v=D7Sd8A6_fYU Embedded Development with Dan Saks http://cppcast.com/2016/10/dan-saks/ Regarding Java vs C++, yes the enterprise world has adopted Java, however as someone doing consulting across Java, .NET and C++, I am really seeing it coming back since ANSI C++…

It is very hard to get a Java or Python programmer (what those AI guys want to use) to move to C, even if they HAVE to use something native. So C++ is where they end up.

Re: Should you Rust in embedded yet?

#114

Post by pjmlp »

freeone3000 wrote: post #113
pjmlp wrote: post #112

Earlier quoted context omitted.

So, I will let one of the renowned experts speak instead. CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++” https://www.youtube.com/watch?v=D7Sd8A6_fYU Embedded Development with Dan Saks http://cppcast.com/2016/10/dan-saks/ Regarding Java vs C++, yes the enterprise world has adopted Java, however as someone doing consulting across Java, .NET and C++, I am really seeing it coming back since ANSI C++…

It is very hard to get a Java or Python programmer (what those AI guys want to use) to move to C, even if they HAVE to use something native. So C++ is where they end up.

This whole thread started about embedded development.

As noted, unless we are speaking about PICs with 8KB and similar, the majority of them can easily be targeted by C++, which is what Arduino and ARM mbed do.

Already in MS-DOS, on 640KB computers, using C made little sense.

When we needed performance, Assembly was the only option, because the code any compiler was generating in those days was average quality on their better days.

When performance wasn't that critical, then the improved type system, RAII, reference types, type safe encapsulations were already better than using plain C.

We even had frameworks like Turbo Vision available.

So if something like a PCW 512 didn't had issues with C++, so a modern micro-controller can also be targeted by it, except for political reasons.

Developers that are against anything other than C, even if their compiler nowadays happens to be written in C++ (e.g. gcc, clang, icc, vc).

Re: Should you Rust in embedded yet?

#115

Post by arcticbull »

gmueckl wrote: post #88
arcticbull wrote: post #69

Earlier quoted context omitted.

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

In many ways, generalized statements like this for all possible controllers and software out there are worse than understanding that accessing address 0 from high level code can have its uses and be completely correct. ;) In a less condescending tone, if some HW designer put control structures at address 0 and they are writeable, then you have to deal with it in software. If there is no MMU that can remap that memory…

If the software is unintentionally reading or writing address zero, it’s by definition not functioning properly, but because of the lack of memory protection/safety this failure mode is going undetected. Rust won’t stop you from intentionally accessing 0x0.

This seems among the hardest bugs to track down I could think of, regardless of what is mapped at address zero. I don’t think it’s condescending to say software that begins operating incorrectly in an undetectable way is always bad.

Have you had to track one of these down before? I haven’t, But I have had to track down silent memory corruption issues in memory unsafe languages in the past and it can take days, on the desktop, with good tooling, I can’t imagine doing it on an embedded system.

Re: Should you Rust in embedded yet?

#116

Post by lvh »

c3833174 wrote: post #91
lvh wrote: post #89

Earlier quoted context omitted.

What feature adds that? The borrow checker, lifetimes and ownership are all compile time concepts in Rust.

Compile time doesn't mean the compiler won't add more instructions where you might not expect them.

Are you suggesting the borrow checker adds instructions? I feel the meaning of my comment was pretty clear to mean “strictly compile time”.

Re: Should you Rust in embedded yet?

#117

Post by gmueckl »

arcticbull wrote: post #115
gmueckl wrote: post #88

Earlier quoted context omitted.

In many ways, generalized statements like this for all possible controllers and software out there are worse than understanding that accessing address 0 from high level code can have its uses and be completely correct. ;) In a less condescending tone, if some HW designer put control structures at address 0 and they are writeable, then you have to deal with it in software. If there is no MMU that can remap that memory…

If the software is unintentionally reading or writing address zero, it’s by definition not functioning properly, but because of the lack of memory protection/safety this failure mode is going undetected. Rust won’t stop you from intentionally accessing 0x0. This seems among the hardest bugs to track down I could think of, regardless of what is mapped at address zero. I don’t think it’s condescending to say software t…

If tracking down these kinds of errors on the desktop took you days, your tooling was maybe not good enough. I honestly cannot remember a an instance where valgrind completely failed me. This is lind of my gold standard for debugging memory issues.

Also, some microcontrollers have amazing debugging support these days. Instruction tracing on Cortex M devices is a great feature, for example. The CPU will log every instruction that it executes over a serial interface for the hardware debugger to store. This allows you to go back in time after the fact, something that desktop debuggers have a really hard time with.

Re: Should you Rust in embedded yet?

#118

Post by arcticbull »

gmueckl wrote: post #117
arcticbull wrote: post #115

Earlier quoted context omitted.

If the software is unintentionally reading or writing address zero, it’s by definition not functioning properly, but because of the lack of memory protection/safety this failure mode is going undetected. Rust won’t stop you from intentionally accessing 0x0. This seems among the hardest bugs to track down I could think of, regardless of what is mapped at address zero. I don’t think it’s condescending to say software t…

If tracking down these kinds of errors on the desktop took you days, your tooling was maybe not good enough. I honestly cannot remember a an instance where valgrind completely failed me. This is lind of my gold standard for debugging memory issues. Also, some microcontrollers have amazing debugging support these days. Instruction tracing on Cortex M devices is a great feature, for example. The CPU will log every inst…

My point is, with a language like Rust, you can pretty much throw all this away. Why put yourself through this intentionally?

I also feel you're dodging my question. A 1-in-1000 spurious write to 0x0 is something you'll have a terrible time even identifying as the cause of your failure specifically because it is completely silent. Your embedded system just happens to stop working sometimes, where do you even think to begin? Assuming you know this is why, sure, throw on a watchpoint and call it a day, but how did you connect "heater stops heating" to 1-in-1000 write to 0x0?

You don't have to worry about that with a language that wont even let you make that invalid program in the first place.

Re: Should you Rust in embedded yet?

#119

Post by gmueckl »

arcticbull wrote: post #118
gmueckl wrote: post #117

Earlier quoted context omitted.

If tracking down these kinds of errors on the desktop took you days, your tooling was maybe not good enough. I honestly cannot remember a an instance where valgrind completely failed me. This is lind of my gold standard for debugging memory issues. Also, some microcontrollers have amazing debugging support these days. Instruction tracing on Cortex M devices is a great feature, for example. The CPU will log every inst…

My point is, with a language like Rust, you can pretty much throw all this away. Why put yourself through this intentionally? I also feel you're dodging my question. A 1-in-1000 spurious write to 0x0 is something you'll have a terrible time even identifying as the cause of your failure specifically because it is completely silent. Your embedded system just happens to stop working sometimes, where do you even think to…

Well, this hasn't even been an issue for us in the last couple of years, even though we use controllers without MMUs. We have a quite complex C++ codebase and our coding style catches a lot of these mistakes outright.

Rust is simply not an option for us because of a distinct lack of tooling available for it. We need a ISO 61508 qualified toolchain including testing frameworks and there is none in sight for rust.

Also, out of interest: has anyone ever tried to write code in rust that is protected against bit flips caused by radiation? Our code is able to detect this because it stores long lived values also as bit inverted patterns and compares them regularly. This does not allow us to recover outright, but we can at least fail gracefully and attempt to reboot the device.

Post reply on HN