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

111–120 of 159 posts

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

#111

Post by infamouscow »

steveklabnik wrote: post #49
sheepybloke wrote: post #46

Honestly, the biggest thing that concerns me with using Rust for embedded is the size of the crates. We were looking to do some packages for a product, and the Rust packages were huge compared to the C++ ones. Granted, this was mostly because the C++ ones could use .so's, while Rust had to compile those into the crate, but this is a huge issue when doing OTA updates.

It's just something you have to care about, but it's not a show-stopper. We use a bunch of crates in our projects at work, I left some example sizes in a comment a while back https://news.ycombinator.com/item?id=34032824

It's a show stopper when size matters and you can't fit the binaries into flash.

I'm sure "sorry for getting everyone to switch to this unestablished language" will go over very well with your boss and upper management. At least in C and C++ you can blame your tools.

If you've stupidly convinced management the existing tooling is shit, then you've got a problem. And I don't mean a technical one, I mean a problem with paying rent, because you're not going to be employed much longer.

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

#112

Post by throw10920 »

infamouscow wrote: post #101
marcosdumay wrote: post #45

Earlier quoted context omitted.

It's not only security, it's correctness. It's about your software staying running and doing the right thing. I can believe HFT developers think they don't need it.

First, 100% of HFT are businesses trying to make money above all else. Security and correctness are secondary to the business requirement of making money, especially when you are uniquely situated to have financially quantified their risk when things go wrong to remain within controlled error bands. Second, HFT developers are using very expensive FGPAs to do trading with network packets. People are quick to reach to…

> It helps immensely to understand ones concerns, constraints, and values before assuming they're identical and them swiftly demonizing anyone that dissents. The Rust community really has done itself a massive disservice in alienating everyone that doesn't conform to its monoculture composed mostly of amateurs and unemployable extremists.

I think that it's a little unlikely that the Rust community is mostly composed of "amateurs and unemployable extremists" - a lot of the working software engineers I know are interested in or actively use it.

However, "assuming they're identical and them swiftly demonizing anyone that dissents" is an excellent characterization of, at least, the parts of the Rust community that I see on HN and Reddit.

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

#113

Post by jeff-davis »

tialaramex wrote: post #104
jeff-davis wrote: post #94

Earlier quoted context omitted.

Postgres is designed to recover on OOM in most cases.

That's nice, how well does it work in practice?

It works. Bugs have been found, and some more bugs probably exist, but I think it meets a fairly high bar of quality.

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

#114

Post by GrumpySloth »

meragrin_ wrote: post #109
rockdoe wrote: post #103

Earlier quoted context omitted.

FYI Google and Mozilla audit all their dependencies and share them: * https://chromium.googlesource.com/chromiumos/third_party/rus... * https://searchfox.org/mozilla-central/source/supply-chain/au... It's quite likely that most of your dependencies were already audited.

So what in there guarantees I can get the same thing they audited?

Version numbers. You can’t modify an already-published version of a Rust crate on crates.io.

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

#115

Post by kkert »

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…

Honestly i have a far easier time finding working no-std libraries for anything i need on embedded Rust compared to embedded C++. Arduino ecosystem is an exception, but that's not necessarily something i'd put in production

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

#116

Post by troad »

palata wrote: post #68
AlotOfReading wrote: post #7

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of fail…

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

I'm somewhat puzzled - the obvious answer is that you don't have to use them. Rust by itself is no less feature complete than C. Anything you can write in C without dependencies, you can write in Rust without dependencies too.

Of course, dependency-reliance falls on a spectrum for any individual programmer. On the one hand you have script kiddies with 400 npm dependencies gathered from arcane Discord channels - on the other you have old bearded wizards who don't understand why you'd need printf() when you can just mov rax 1; syscall.

I find Rust is not strongly opinionated about this. You can just as easily eschew dependencies as use them. There's usually a good array of options available, or you could always FFI to a C lib directly if you need to.

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

#117

Post by GrumpySloth »

throwaway17_17 wrote: post #65
pornel wrote: post #48

Earlier quoted context omitted.

A bounds-checked slice type would be a relatively small addition to C, and if adopted, it would make size tracking and bounds checking easier. However, there's generally a strong pushback from C developers against features that have an unnecessary performance overhead. Having reliable bounds checking without run-time cost if a much more complicated problem. Rust uses iterators for this, but that requires generics and…

To be clear, I don't think there is any hope of implementing any protections at the language level in C, the push back would be exceptionally fierce. Although I do agree that a 'slice' type in the stdlib would not be to much to ask for. My comment was more for consideration in the design of new languages, in particular, the development of the frequently cited as not existing, simple, C-like language with memory safet…

The problem with slices in C being added in stdlib would be that they really are a generic data type. It would be similar to atomic types. While C++ could just add std::atomic, C needed to add a special construct: _Atomic(T).

C++ already has a slice type. It’s called std::span. Porting it to C would probably require something similar to atomics. At which point I guess you may just as well get on with it and switch to C++.

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

#118

Post by rendaw »

palata wrote: post #92
iknowstuff wrote: post #85

Earlier quoted context omitted.

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?

Isn't this hierarchical trust? You select immediate dependencies that you believe are written by reasonably security-conscious people, not just anything that immediately solves a problem, and because they're reasonably security-conscious people they select their own dependencies the same way? And at each level vetting is implicitly shared with other users of the dependencies, some of whom will be more critical/inquisitive.

I've heard the alarms about dependencies and I'm not sold. I feel like this is bleeding over from the JS/frontend world where people don't choose to do the above, for whatever reason.

Whenever I add a dependency in Rust I look at crates.io downloads, dependents (any big projects there?), github stars, I browse the issues to see what sort of problems have been reported and when, with what sort of replies from the author, how many contributors there are, release history, what commits look like, and what other stuff the authors have worked on. I use a lot of dependencies, and I do rewrite stuff myself when I feel like I can't rely on a dependency.

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

#119

Post by adrianN »

bsder wrote: post #99
adrianN wrote: post #50

Earlier quoted context omitted.

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

So the author tried very hard to provide a safe interface for things that are inherently unsafe and found it to be too much work. That’s similar but different to just calling C from Rust and living with unsafe code like you normally do in C.

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

#120

Post by otabdeveloper4 »

AlotOfReading wrote: post #7

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of fail…

Memory safety issues don't matter.

There are five orders of magnitude more pwned boxes due to misquoted strings then there are due to memory safety issues.

You are searching for a problem that could potentially make Rust useful instead of solving a real existing problem that people actually have.

Post reply on HN