Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

arxiv.org

Post reply on HN
Print view View original

131–140 of 172 posts

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#131

Post by cyberpunk »

IshKebab wrote: post #129
cyberpunk wrote: post #87

Earlier quoted context omitted.

I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax. They had some great stories trying to get something or other running again where they had to fly one of the original designers over to hand solder a board back into action. How we do th…

> I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust. Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years. C is an absolute nightmare in comparison. I tried to compile some old C code I had for Nordic nRF51 chips, only a few years after the chips became available. I gave u…

shrug I guess we have different experiences. Any even small sized rust application I've come across rivals nodejs for amount of deps it pulls in.

Sure, just vendor them in, simples, right?

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#132

Post by bigstrat2003 »

nine_k wrote: post #66
fluidcruft wrote: post #44

Earlier quoted context omitted.

I think people don't like the JavaScript treadmill. People want to think about using tools and getting proficient with them rather than relearning tools. I'm not saying rust is like that, but I do feel that way about python and JavaScript. Those are dynamic languages but it is what all this editions stuff evokes. It's an if it were stable, it wouldn't be changing sort of thing.

> using tools and getting proficient with them rather than relearning tools This attitude works in carpentry, but not in software. You need to get proficient, but your tools will keep evolving, like everything else in the software world.

That attitude works just fine in software. It's literally only web devs that are constantly chasing trends in how to make software.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#133

Post by 3836293648 »

tialaramex wrote: post #71
vmg12 wrote: post #40

Earlier quoted context omitted.

> Rust is evolving far too fast I'm curious why I've seen this sentiment repeated in so many places, I learned Rust once 5 years ago and I haven't had to learn any new idioms and there have been no backwards incompatible changes to it that required migrating any of my code.

To be very fair there are legitimate gripes here, they're small but they are worth covering, and then there's a huge nonsense L1: The edition system allows Rust to literally mutate the language. 2024 edition (if you begin a new Rust project today) has different rules from 2021 Edition, from 2018 edition and the Rust 1.0 "2015 edition". These changes aren't exactly huge, but they are real and at corporate scale you wo…

Strip_suffix won't break with new compiler versions. Anything explicitly imported takes precedence over the prelude, or else everything is a breaking change and would have to wait for an edition.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#134

Post by tialaramex »

nine_k wrote: post #115
estebank wrote: post #80

Earlier quoted context omitted.

This attitude doesn't even work in carpentry, depending on the timeframe you look at, tools have changed over time. You can still use a hand saw, where a table saw would be just as suitable, or have a SawStop(tm) and reduce the likelihood of losing a finger.

In carpentry, you still do a lot of work with a hammer which did not change materially for last 70 years. Programming tools did change very, very much since 1956, even though some still retain the recognizable shape (e.g. Lisp or Fortran).

I don't think there are Titanium hammers 70 years ago. The changes are smaller but they are there.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#135

Post by 3836293648 »

oytis wrote: post #28
estebank wrote: post #22

Earlier quoted context omitted.

Can you point at any piece of code from 5 years ago that doesn't work today?

I only tried Rust for small hobby projects, but I did experience weird code rot when you just leave the code there and after a while it does not compile. Might have something to do with how Cargo manages dependencies

Either you used nightly, explicitly non stable, rust instead of the default stable rust; or you used dependencies that have been yanked due to security issues; or you didn't commit your lockfile and implicitly upgrades everything by having to generate a new lockfile because you used a really wide range of compatible versions.

All of these options require you to go out of your way to enable breakage.

You could also be in the super unlucky state of using something that was later proved unsound in std, which is the only case where rust will break your code on stable. (Missused unsafe in std)

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#137

Post by tialaramex »

3836293648 wrote: post #133
tialaramex wrote: post #71

Earlier quoted context omitted.

To be very fair there are legitimate gripes here, they're small but they are worth covering, and then there's a huge nonsense L1: The edition system allows Rust to literally mutate the language. 2024 edition (if you begin a new Rust project today) has different rules from 2021 Edition, from 2018 edition and the Rust 1.0 "2015 edition". These changes aren't exactly huge, but they are real and at corporate scale you wo…

Strip_suffix won't break with new compiler versions. Anything explicitly imported takes precedence over the prelude, or else everything is a breaking change and would have to wait for an edition.

https://rust.godbolt.org/z/4bsb91Krf is code which calls our strip_suffix in 1.40

Switch to Rust 1.50 and now it's calling the stdlib strip_suffix silently, I actually wasn't expecting it to be silent, and obviously if they have the same exact behaviour (mine instead panics to show we're calling it) you wouldn't even notice, but it is a change.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#138

Post by whytevuhuni »

fluffybucktsnek wrote: post #122
staticassertion wrote: post #17

Earlier quoted context omitted.

> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. That statement deserves support.

Why, given the existence of editions?

Very surprised to hear that, since editions are exactly the kind of mechanism Rust is using to make sure software will keep working unchanged for decades.

The Rust compiler can build a 2024 edition application which depends on a 2015 edition library, which in turn depends on a 2018 edition library.

Every crate can upgrade at their own pace, or even never at all.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#139

Post by IshKebab »

cyberpunk wrote: post #131
IshKebab wrote: post #129

Earlier quoted context omitted.

> I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust. Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years. C is an absolute nightmare in comparison. I tried to compile some old C code I had for Nordic nRF51 chips, only a few years after the chips became available. I gave u…

shrug I guess we have different experiences. Any even small sized rust application I've come across rivals nodejs for amount of deps it pulls in. Sure, just vendor them in, simples, right?

You could do (it is simple), but all the code is stored on crates.io so there's no real need.

An exception is for crates that wrap C code which might get the code from elsewhere but those are quite rare.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#140

Post by cyberpunk »

IshKebab wrote: post #139
cyberpunk wrote: post #131

Earlier quoted context omitted.

shrug I guess we have different experiences. Any even small sized rust application I've come across rivals nodejs for amount of deps it pulls in. Sure, just vendor them in, simples, right?

You could do (it is simple), but all the code is stored on crates.io so there's no real need. An exception is for crates that wrap C code which might get the code from elsewhere but those are quite rare.

And they’re immutable, forever? No one can pull a leftpad?
Post reply on HN