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

91–100 of 119 posts

Re: Should you Rust in embedded yet?

#91

Post by c3833174 »

lvh wrote: post #89
koffiezet wrote: post #84

Earlier quoted context omitted.

Your compiler adding the execution of an unpredictable amount of CPU instructions at certain points, which can change with new compiler versions? That sounds like an nightmare for realtime applications. Yes, I have been in situations where I had to count the instructions and clock-cycles to meet deadlines.

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.

Re: Should you Rust in embedded yet?

#92

Post by pjmlp »

koffiezet wrote: post #87
atilaneves wrote: post #81

Earlier quoted context omitted.

They'd move over if technical considerations were the only reason why people choose programming languages. In my experience it tends to be psychological ones. > you can actually figure out in your head what the assembly will look like I keep hearing this, and I don't buy it. Did you know that `gcc -O3` will turn `int add(int x, int y) { return a + b; }` into an `lea` instruction? I doubt many people do. And it's not…

Psychological ones? No, simply the lack of available reliable compilers for some platforms was my problem. I developed POS applications, where C++ would have worked fine, if we had a decent C++ compiler on every platform we wanted to support. Some platforms used GCC, but most used proprietary compilers - where C++ support was completely absent or very scetchy. When you can't use exceptions, the memory allocator is ab…

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

Re: Should you Rust in embedded yet?

#93

Post by jononor »

koffiezet wrote: post #84
jononor wrote: post #76

Earlier quoted context omitted.

The borrow checker should be quite useful when using tasks and shared resources in an RTOS. Just closures alone is a benefit.

Your compiler adding the execution of an unpredictable amount of CPU instructions at certain points, which can change with new compiler versions? That sounds like an nightmare for realtime applications. Yes, I have been in situations where I had to count the instructions and clock-cycles to meet deadlines.

Why do you think this will be a problem? I mean any more than with any optimizing compiler (C etc).

Re: Should you Rust in embedded yet?

#94

Post by lpasselin »

tov_objorkin wrote: post #79
lpasselin wrote: post #45

Any progress with ti's c2000 series in rust?

Oh, ti c/c+ compiler is such a joke, not event c99 supported. I was thinking about rust to C compiler [1], but thats require c11 support. 1. https://github.com/thepowersgang/mrustc

C99 is supported but it is not the default.

Re: Should you Rust in embedded yet?

#95

Post by icedchai »

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.

I take it you didn't do much development on machines without memory protection. The problem isn't reading from 0x0. It's writing to 0x0 (and beyond), clobbering system memory , memory mapped IO, or even your own application.

I learned C on an Amiga, back in the late 80's. A bad pointer typically resulted in "Guru Meditation" error (OS crash), followed by a reboot.

Re: Should you Rust in embedded yet?

#96

Post by epage »

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

To me, the power of it isn't just in dynamic memory but also in that Rust has clear move vs ref vs bit copy vs logical copy (clone) and use-after-free protection.

As one example of the benefit of this. This makes me feel a lot more comfortable writing state machines in Rust's type system.

See https://hoverbear.org/2016/10/12/rust-state-machine-pattern/

Re: Should you Rust in embedded yet?

#97

Post by Symmetry »

Matthias247 wrote: post #39
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.

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.

In general tools for constraining hardware complexity like namespaces and encapsulation are a lot less important for the project sizes where you're typically working with embedded systems. For the rest they mostly provide some benefit but that's offset by the danger of a move to a much, much larger and more complicated language in an environment where many people writing code are primarily EEs and most C++ answers they Google will provide solutions inappropriate for embedded development. And I say this as someone who was one of those EEs when he started out.

Re: Should you Rust in embedded yet?

#98

Post by petra »

koffiezet wrote: post #83
_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…

I used to work in a space that was once considered to be embedded (POS systems, including some based on low-cost 8bit controllers, m86k based stuff and low-end ARM at the end), and got out of it just before the entire thing was taken over by fast 32bit or even 64bit ARM CPU's, which eventually moved to running stock Linux or Android. As ARM chips become cheaper and cheaper, the low-level embedded fields will shrink f…

And even where Linux won't go, mbed os and it's ecosystem could take - as long as the requirements for faster time to market will continue.

Re: Should you Rust in embedded yet?

#99

Post by steveklabnik »

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.

That's true of any compiler of any language.

Re: Should you Rust in embedded yet?

#100

Post by throwaway84742 »

rvense wrote: post #73
throwaway84742 wrote: post #58

Earlier quoted context omitted.

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.

But it is never what you want. So even if there are no immediate explosions, your LED's not going to blink the way you expected it. I'd say a clear, stern sign that something was wrong is better than limping along after dereferencing null.

Sure. I’m just saying that null pointer deref and read is not generally a fatal operation. Most programmers expect the program to die in this case. When it doesn’t, they are surprised.
Post reply on HN