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

151–159 of 159 posts

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

#151

Post by troad »

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"?

Huh? Now I'm quite puzzled. I find both fine to say. I think I make it pretty clear in my comment that dependency use is a per-programmer issue. If you come to Rust with an unquenchable dependency-lust, then yeah, you'll wind up with a Cargo file that looks like the Chicago phonebook. But - here's the kicker - you can do that with C or C++ too! There's really nothing about Rust that requires or recommends this, is my point.

Rust is a generally safer language than C, this much is fairly well established. That alone is an intrinsic advantage. I'm the sort of dev to inline handwritten assembly for a performance boost, so I feel very warmly towards C (which is just assembly in a wig), but for those things where correctness and safety is more important, Rust is simply the better tool.

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

#152

Post by troad »

palata wrote: post #150
iknowstuff wrote: post #149

Earlier quoted context omitted.

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…

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

Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library.

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

Then don't use them?

Your concerns appear to boil down to 'bad software exists'. Which... yeah. It does. Not sure what you want us to say. It's an intrinsic characteristic of open source / free software, and it's not like C/C++ is somehow under-represented (or Rust over-represented) in dodgy software.

There's plenty of closed ecosystems you can stick to if you don't trust yourself not to use dodgy dependencies (though I think this is a very strange concern to have).

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

#153

Post by palata »

troad wrote: post #152
palata wrote: post #150

Earlier quoted context omitted.

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

> I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust? Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. > 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 R…

> Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library.

Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro.

Somehow it feels like Rust does not go really well with distros (because it pushes for static linking).

> Your concerns appear to boil down to 'bad software exists'.

I was reacting to someone generalizing on C/C++ code, saying that "people dramatically overestimate it". I feel like it's nice to have some memory safety brought by Rust, but I find it a bit hypocritical to criticize the security of C/C++ code if Rust projects tend to statically link random code from hundreds of dependencies nobody ever reads. Because that's a big security issue IMO.

Sure, you can do it right with Rust. But you can also write good code with C/C++.

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

#154

Post by troad »

palata wrote: post #153
troad wrote: post #152

Earlier quoted context omitted.

> I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust? Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. > 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 R…

> Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. Somehow it feels like Rust does not go really well with distros (because it pushes for static linking). > Your concerns appear to boil down to 'bad software exists…

> Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro.

You're comparing apples to oranges. Most C/C++ software in business use isn't pulling its dependencies from distro PMs, it's pulling them from some monstrous dark web of Visual Studio projects and opaque git repos. And on the other hand, Rust software that's distributed in distro PMs uses distro dependencies like any other package. Equally, as you note, the reverse exists. None of this tells us very much about Rust or C/C++ as languages.

> Rust projects tend to statically link random code from hundreds of dependencies nobody ever reads

'Tend to' is doing a lot of heavy lifting in that sentence, and doesn't seem to be based on very much more than 'I saw it a few times'. Well, I've seen my share of nightmarish C++ dependency trees. Is that a good argument against C++? Not really.

You're picking up on real issues - unnecessary and untrusted dependencies - except you're then erroneously drawing some imagined line in the sand where Rust bad and C/C++ good, which is where a rational argument seems to collapse into vibes. On the whole, there's a lot more C++ projects out there guilty of this than Rust projects.

> Sure, you can do it right with Rust. But you can also write good code with C/C++.

You can hammer a nail with a broom, but that doesn't make it the best tool for the job. The safety advantages of Rust can't just be hand-waved away. C is a fine programming language when safety is less of an issue. If you're writing a Nintendo emulator, sure, C, why not. If you're writing business logic that handles health data, maybe not.

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

#155

Post by iknowstuff »

palata wrote: post #153
troad wrote: post #152

Earlier quoted context omitted.

> I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust? Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. > 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 R…

> Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. Somehow it feels like Rust does not go really well with distros (because it pushes for static linking). > Your concerns appear to boil down to 'bad software exists…

> But you can also write good code with C/C++.

That's funny, literally every data point I've read says otherwise. What are you reading?

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

#156

Post by palata »

troad wrote: post #154
palata wrote: post #153

Earlier quoted context omitted.

> Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. Somehow it feels like Rust does not go really well with distros (because it pushes for static linking). > Your concerns appear to boil down to 'bad software exists…

> Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. You're comparing apples to oranges. Most C/C++ software in business use isn't pulling its dependencies from distro PMs, it's pulling them from some monstrous dark web of Visual Studio projects and opaque git repos. And on the other hand, Rust software that's distributed in dis…

> Rust software that's distributed in distro PMs uses distro dependencies like any other package.

I haven't found a single Rust package that depends on a shared Rust library coming from the system package manager. Do you have an example of that? Genuinely interested in seeing how it looks. Many people tell me that Rust "doesn't support shared libraries", which seems odd to me. But I have never seen one, so...

> except you're then erroneously drawing some imagined line in the sand where Rust bad and C/C++ good

I don't think that, maybe I did not express myself correctly. I was answering to a comment that, to me, sounded like "C/C++ bad and Rust good", by saying that I also see issues in Rust (namely with the dependency management).

I like Rust-the-language. What I don't like, to be honest, is how Rust people seem to believe that static linking is the solution to all their problems.

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

#157

Post by palata »

iknowstuff wrote: post #155
palata wrote: post #153

Earlier quoted context omitted.

> Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. Somehow it feels like Rust does not go really well with distros (because it pushes for static linking). > Your concerns appear to boil down to 'bad software exists…

> But you can also write good code with C/C++. That's funny, literally every data point I've read says otherwise. What are you reading?

I am not reading anything saying that there exists C/C++ code. I read code and make my own opinion.

Most code is bad, but that's true for Rust as well. The memory safety does not magically make code good. BTW Rust is not the only language that has memory safety, by far.

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

#158

Post by Groxx »

palata wrote: post #156
troad wrote: post #154

Earlier quoted context omitted.

> Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. You're comparing apples to oranges. Most C/C++ software in business use isn't pulling its dependencies from distro PMs, it's pulling them from some monstrous dark web of Visual Studio projects and opaque git repos. And on the other hand, Rust software that's distributed in dis…

> Rust software that's distributed in distro PMs uses distro dependencies like any other package. I haven't found a single Rust package that depends on a shared Rust library coming from the system package manager. Do you have an example of that? Genuinely interested in seeing how it looks. Many people tell me that Rust "doesn't support shared libraries", which seems odd to me. But I have never seen one, so... > excep…

Last I checked Rust itself does not have a stable ABI, so there are effectively no "shared Rust libraries" outside of static linking / compiling from source.

But they can and do simply use C's ABI when dynamic linking, because that is stable. Rust-to-Rust libraries generally don't bother with this because Cargo exists and that trivializes "build from source" and is far more configurable and optimizable and compile-time-provable, but it's used any time Rust uses C-compatible stuff or vise versa and that's quite common.

Post reply on HN