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

Rust for Embedded Systems: Current state, challenges and open problems

arxiv.org

Post reply on HN
Print view View original

91–100 of 159 posts

Re: Rust for Embedded Systems: Current state, challenges and open problems

#91

Post by atoav »

the__alchemist wrote: post #35
atoav wrote: post #23

As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. So let's say I happen to work with a MCU that is well supported in Rust, what if I want to connect it to a popular OLED display? Is there a library for that? If so, does it work? If it works, does it have the needed features? Now maybe I am incredibly lucky and all of that works, what about a popular gyro IC? Gran…

You will probably be on your own unfortunately regarding hardware support. Even when libraries exist, they are often not worth the fork/PR/modification process to accommodate your use case. I hope you like datasheets... This sounds rough, but I will highlight two upsides: #1: You benefit from the nice tooling and language of rust #2: You are forced to learn how to use peripherals at a lower level than would otherwise…

You make it sound worth a try. I will keep the thought in mind, thanks.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#92

Post by palata »

iknowstuff wrote: post #85
palata wrote: post #68

Earlier quoted context omitted.

> People dramatically overestimate the correctness of their [C/C++] code Genuinely interested: what do people think of their tons of third-party dependencies in Rust? My experience building Rust projects is that there are orders of magnitudes more dependencies than what would make me comfortable. At least in C/C++ it's much harder to get there.

Long story short is that I trust their quality. The community is great about vetting unnecessary uses of unsafe code. That’s more than can be said about hand rolled equivalents in C/C++.

So if you have 200 dependencies, you trust them just because they don't run what Rust calls "unsafe" code? What about safe code that could be malware?

Re: Rust for Embedded Systems: Current state, challenges and open problems

#93

Post by rcxdude »

steveklabnik wrote: post #70
bigyikes wrote: post #61

Earlier quoted context omitted.

Is video game security an entire subfield of its own? I imagine there are categories of exploits in video games which simply don’t exist in other areas of software

The latest in FPS cheating (that I'm aware of, not like I'm super plugged into the underground) involves buying a second PC to run the cheats, a card for your main PC to grab a copy of memory over DMA, ship it off to the second PC, then joining the two video feeds together. Apparently you can also hook your mouse up to a connection where it will edit the data flowing from the mouse to give you better aim as well. A l…

Security != DRM, i.e. 'anti-cheat'. Security is more about 'a malicious player can't RCE other players' than "cheaters can't access data which is sent to their PC anyway". One is a lot more tractable than the other.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#94

Post by jeff-davis »

tialaramex wrote: post #84
kevin_thibedeau wrote: post #78

Earlier quoted context omitted.

MongoDB's BSON library calls abort() on malloc failure because they can't be bothered to handle OOM gracefully.

That seems completely reasonable. The only interesting case is "There was far too little storage, so we gave up early" e.g. you need 14GB, there is 186MB available, give up. I probably don't want my photo viewer to crash because I tried to open a JPEG that wouldn't fit in RAM, better it just says that's too big and I can pick a different file. Whenever people are imagining they're going to recover despite OOM in low…

Postgres is designed to recover on OOM in most cases.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#95

Post by throwaway234890 »

kevin_thibedeau wrote: post #78
jcelerier wrote: post #28

Earlier quoted context omitted.

> People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation Really depends on the field. I heard more than once in my life now that it's better to reboot every night than spend even an afternoon of engineering trying to fix memory leaks.

MongoDB's BSON library calls abort() on malloc failure because they can't be bothered to handle OOM gracefully.

Linux supports overcommitted memory and so will lie to your application about memory availability. When I tested several common open-source applications in a memory-constrained environment none of them, except for the Java VM, handled OOM conditions gracefully. I came to the conclusion it's not worth the programming effort unless your application will specifically expect this condition to occur.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#96

Post by galangalalgol »

Animats wrote: post #79
jcranmer wrote: post #71

Earlier quoted context omitted.

> I've seen what comes out of the transpiler. Nobody should touch that code by hand. It's awful Rust, and uglier than the original C. I can't disagree here. I think the original idea was to rely on automated refactoring tools to try to make the generated Rust somewhat more palatable, but I never was able to get that working. > C23 doesn't actually use that info. True; the intent is to require it so that it can be lev…

The real problem is not translating code. It's translating data types. If you can determine that a "char *" in C can be a Vec in Rust, you're most of the way there. It's no longer ambiguous what to do with the accesses. This is where I think LLMs could help. Ask an LLM "In this code, could variable "buf" be safely represented as a Rust "Vec", and if so, what is its length?. LLMs don't really know the languages, but t…

They have made some improvements here recently. There is a lot less unsafe generated. The rest is more idiomatic too. The cost is that it will be throwing panics everywhere until you fix the faulty assumptions it asserted. I like the new way better.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#97

Post by llm_trw »

atoav wrote: post #86
jdiez17 wrote: post #40

Earlier quoted context omitted.

From my experience in the embedded world, the ecosystem doesn't seem super relevant. You may depend on certain libraries for encryption, compression, etc. but you're more likely than not to be writing drivers for all of your devices more or less from scratch. Other than Arduino, which of course has pretty good support for many devices and is likely to work out of the box.

It probably depends on what you do with embedded, I can certainly imagine situations/jobs where you are correct, but I am not in that situation, unfortunately. I can't afford the time to write my own drivers unless I really need/want to. I run an electronics workshop at an artschool, so the end result counts and how we get there is more or less arbitrary unless it happens in a finite timeframe. For my own private pro…

>I like fooling around with the interesting bits, not with rewriting a thing others have written before.

For some reason the rust community seems to love rewriting things others have done before and not do much new work.

At this point the biggest thing holding the language back are its users.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#98

Post by infamouscow »

throwaway234890 wrote: post #95
kevin_thibedeau wrote: post #78

Earlier quoted context omitted.

MongoDB's BSON library calls abort() on malloc failure because they can't be bothered to handle OOM gracefully.

Linux supports overcommitted memory and so will lie to your application about memory availability. When I tested several common open-source applications in a memory-constrained environment none of them, except for the Java VM, handled OOM conditions gracefully. I came to the conclusion it's not worth the programming effort unless your application will specifically expect this condition to occur.

I work on systems that don't run on Linux, and those systems also have reasonable business requirements for graceful failure on OOM. This is unhelpful.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#99

Post by bsder »

adrianN wrote: post #50
bsder wrote: post #43

Earlier quoted context omitted.

Not really. The semantics as you cross the boundary are ill-defined. And you will pay dearly if the C library wants to own any of the resources (like an event loop). And "unsafe" programming in Rust is really difficult to get right--possibly harder than C. To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them.

>To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them. Yes, including C.

Incorrect.

Two C libraries interface just fine if library 1 handles ownership and library 2 (or your program) simply operates on the resulting things being passed around.

Rust, on the other hand, will go bananas and your life will be miserable. See: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...

Re: Rust for Embedded Systems: Current state, challenges and open problems

#100

Post by rockdoe »

kevin_thibedeau wrote: post #78
jcelerier wrote: post #28

Earlier quoted context omitted.

> People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation Really depends on the field. I heard more than once in my life now that it's better to reboot every night than spend even an afternoon of engineering trying to fix memory leaks.

MongoDB's BSON library calls abort() on malloc failure because they can't be bothered to handle OOM gracefully.

Firefox and Chrome (and thus Edge, Brave, OperaGX, etc etc) do the same for many allocations - it's safer to crash than to end up in an obscure failure path that never had its error handling exercised and may accidentally be security sensitive.
Post reply on HN