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

141–150 of 159 posts

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

#141

Post by palata »

jnxx wrote: post #140
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.

> Genuinely interested: what do people think of their tons of third-party dependencies in Rust? Here are three things I think, and they have in fact nothing to do with Rust: 1. The easier it is to add dependencies, the more dependencies will be added on average - unless you work purposefully against that. 2. The effect of a rising average number of dependencies in libraries is that their number of dependencies grows…

> All these things together is why I believe that systems like NixOS or Guix are the future (but of course there might be other developments in that space).

That, or actually keeping control over the dependencies?

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

#142

Post by infamouscow »

steveklabnik wrote: post #130
infamouscow wrote: post #111

Earlier quoted context omitted.

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…

My point is that you can always fit the binaries into flash. There’s no inherent overhead.

That's great it works well for AMD64 Linux ELF files. I would be surprised if it didn't given the toolchain seems to have been designed around that triple specifically.

But the majority of embedded platforms are not booting or running AMD64 Linux, they're running ARMv{6,7,8}, MIPS, or 32-bit RISC-V chips.

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

#143

Post by jnxx »

palata wrote: post #141
jnxx wrote: post #140

Earlier quoted context omitted.

> Genuinely interested: what do people think of their tons of third-party dependencies in Rust? Here are three things I think, and they have in fact nothing to do with Rust: 1. The easier it is to add dependencies, the more dependencies will be added on average - unless you work purposefully against that. 2. The effect of a rising average number of dependencies in libraries is that their number of dependencies grows…

> All these things together is why I believe that systems like NixOS or Guix are the future (but of course there might be other developments in that space). That, or actually keeping control over the dependencies?

I think it is always wise to constrain unneeded dependencies. And this counts even more in embedded systems.

But on the other hand, programming artefacts, languages and their library systems compete in terms of features, which will usually lead to an ever growing number of dependencies. At least this is what we observe. Even if not all of this is really necessary, this would probably be hard to reverse in general.

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

#144

Post by rendaw »

palata wrote: post #135
rendaw wrote: post #118

Earlier quoted context omitted.

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/inquis…

That's the thing about trust: not everyone uses it the same. There are documented examples of malware being injected to millions of dependents through package managers, so we know that "hierarchical trust" does not work. The big difference with a distro is that I choose to trust the distro maintainers, which is only a handful of people. Whereas with your hierarchical trust, you choose to trust many random people.

I know I remember there being a couple big events in the news, and I know the Javascript ecosystem is also a bigger target also because it's so popular, but do you have examples of these attacks?

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

#145

Post by rockdoe »

palata wrote: post #136
GrumpySloth wrote: post #114

Earlier quoted context omitted.

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

Who in practice pins their dependencies (transitive included) on audited versions?

Small companies with little development experience like Google and Mozilla.

(You can check the files I linked and see audits between deltas for minor version updates)

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

#146

Post by rockdoe »

infamouscow wrote: post #110
rockdoe wrote: post #102

Earlier quoted context omitted.

In C/C++ every project ends up with a hand coded replacement for those external dependencies that is less well written and infinitely less tested.

What about all of the projects where your assumptions are false?

Why would those need a lot of Rust dependencies then? If you want to hand-roll stuff, hand-roll! no_std is a thing because people use it.

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

#147

Post by steveklabnik »

infamouscow wrote: post #142
steveklabnik wrote: post #130

Earlier quoted context omitted.

My point is that you can always fit the binaries into flash. There’s no inherent overhead.

That's great it works well for AMD64 Linux ELF files. I would be surprised if it didn't given the toolchain seems to have been designed around that triple specifically. But the majority of embedded platforms are not booting or running AMD64 Linux, they're running ARMv{6,7,8}, MIPS, or 32-bit RISC-V chips.

This is not for Linux, these are for the RTOS that we have authored. Bare metal 32 bit ARM.

Basically, you've confused the two examples: the first one is about x86_64 Linux, yes, but the rest are all thumbv6m-none-eabi, thumbv7em-none-eabihf, thumbv8m.main-none-eabihf, stuff like that.

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

#148

Post by palata »

rockdoe wrote: post #145
palata wrote: post #136

Earlier quoted context omitted.

Who in practice pins their dependencies (transitive included) on audited versions?

Small companies with little development experience like Google and Mozilla. (You can check the files I linked and see audits between deltas for minor version updates)

I guess my point was: "because [some teams at] Google/Mozilla do it right does not mean that everybody does it right".

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

#149

Post by iknowstuff »

palata wrote: post #132
troad wrote: post #116

Earlier quoted context omitted.

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

> I'm somewhat puzzled Because you find it fine to say that "people dramatically overestimate the correctness of their [C/C++] code", but not fine to say that "people tend to depend on too many third-parties that they never question"?

We have solid data on how much Rust improves safety, while “too many” dependencies seems rather arbitrary. They tend to be high quality and better vetted/tested than bespoke code or copy-pasted hpp headers

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

#150

Post by palata »

iknowstuff wrote: post #149
palata wrote: post #132

Earlier quoted context omitted.

> I'm somewhat puzzled Because you find it fine to say that "people dramatically overestimate the correctness of their [C/C++] code", but not fine to say that "people tend to depend on too many third-parties that they never question"?

We have solid data on how much Rust improves safety, while “too many” dependencies seems rather arbitrary. They tend to be high quality and better vetted/tested than bespoke code or copy-pasted hpp headers

> They tend to be high quality and better vetted/tested

I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust?

> “too many” dependencies seems rather arbitrary

I would say that you have "too many" dependencies when you don't have control over them, e.g. because you can't afford auditing them or maintaining them. I have seen multiple Rust projects that I would rather rewrite myself than audit their tens (hundreds) of dependencies. That's "too many".

Post reply on HN