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

Why Rust is worse than C for programming low-level hw

infosec.exchange

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Why Rust is worse than C for programming low-level hw

#11

Post by practicalrs »

mjb wrote: post #6
practicalrs wrote: post #2

Such fameous hacker like Zalewski should better distinguish language and library interfaces design issues.

Yeah, this is just trolling. There's nothing inherent to rust that requires ( or even recommends) writing code like this. There's nothing inherent to C that prevents bad API designs like this. Nothing about this post is notable or interesting. It's low-effort rage bait.

"There's nothing inherent to C that prevents bad API designs like this."

I don't have any data to back this and library interface designs are so personal taste-prone, but I would say that the average Rust crate has a better API than the average C library.

Re: Why Rust is worse than C for programming low-level hw

#12

Post by lpribis »

This is one of my big frustrations with the embedded rust ecosystem (not a problem with the language IMO). They are so hell-bent on taking the typestate pattern and various abstractions to their extreme to prevent you from ever doing anything bad with the registers that the cognitive overhead of the API is unusable.

It's all great and clean if you're just writing led blinky examples. As soon as you need to dig down to some obscure datasheet minutia (as you invariably have to for any decent size embedded project), it becomes very annoying to map this back to the safe API. The code also becomes less readable since you can no longer look up things you don't understand in the datasheet.

The other this is that because of the excessive use of typestate, any driver struct needs to have a separate generic parameter for each io pin.

Re: Why Rust is worse than C for programming low-level hw

#14

Post by steveklabnik »

To be honest, at Oxide we have basically skipped a lot of the standard Embedded Rust stack. We don't use embedded-hal, and don't really like the style of code svd2rust spits out.

We haven't produced an alternative, so are still using those lower-level svd2rust APIs. But the pain points are very real.

Overall, still quite happy with embedded Rust overall, dealing with annoying APIs is just part of doing professional work.

(Hubris' design also mitigates this issue indirectly, since you're communicating with a driver, where this kind of code lives, so most of the code has a much nicer API, which is also why it's not the end of the world.)

Re: Why Rust is worse than C for programming low-level hw

#16

Post by sunshowers »

larusso wrote: post #9

I don’t know if this one of the embedded Hal libs or not. But what they do is to move the state of GPIO etc into the type system. So the type system maps a state machine. In practice it’s impossible to flip a bit on a pin which is not in the right configuration etc. My understanding was that this is the hot stuff that rust offers to embedded programming. Compiletime error handling. But in reality it can look overly c…

I'm generally a fan of encoding invariants in the type system, but there's a balance to be had between that and the library becoming relatively unusable. I haven't used embedded Rust very much, but my general impression from afar, and from talking to people who are experts in the domain, is that the ecosystem leans far too much into the type system.

Re: Why Rust is worse than C for programming low-level hw

#17

Post by shrimp_emoji »

sumeruchat wrote: post #13
practicalrs wrote: post #2

Such fameous hacker like Zalewski should better distinguish language and library interfaces design issues.

Say that to corporate java writers. Language creates culture and this applies to human as much as computer.

So my instinct to avoid Java at all costs wasn't irrational dysphoria after all!

Re: Why Rust is worse than C for programming low-level hw

#18

Post by larusso »

sunshowers wrote: post #16
larusso wrote: post #9

I don’t know if this one of the embedded Hal libs or not. But what they do is to move the state of GPIO etc into the type system. So the type system maps a state machine. In practice it’s impossible to flip a bit on a pin which is not in the right configuration etc. My understanding was that this is the hot stuff that rust offers to embedded programming. Compiletime error handling. But in reality it can look overly c…

I'm generally a fan of encoding invariants in the type system, but there's a balance to be had between that and the library becoming relatively unusable. I haven't used embedded Rust very much, but my general impression from afar, and from talking to people who are experts in the domain, is that the ecosystem leans far too much into the type system.

I agree. But the point still is that the post wants to make it look like: this is how rust looks like. Look it is as bad as enterprise Java.

Re: Why Rust is worse than C for programming low-level hw

#19

Post by Sharlin »

sumeruchat wrote: post #13
practicalrs wrote: post #2

Such fameous hacker like Zalewski should better distinguish language and library interfaces design issues.

Say that to corporate java writers. Language creates culture and this applies to human as much as computer.

The JavaEE APIs essentially set the example for everybody to then imitate. Of course it didn’t help that design patterns were in peak fashion. The Java core language is small, and most of the SE APIs aren’t particularly byzanthine. But EE then went all in for some reason.

Re: Why Rust is worse than C for programming low-level hw

#20

Post by sunshowers »

larusso wrote: post #18
sunshowers wrote: post #16

Earlier quoted context omitted.

I'm generally a fan of encoding invariants in the type system, but there's a balance to be had between that and the library becoming relatively unusable. I haven't used embedded Rust very much, but my general impression from afar, and from talking to people who are experts in the domain, is that the ecosystem leans far too much into the type system.

I agree. But the point still is that the post wants to make it look like: this is how rust looks like. Look it is as bad as enterprise Java.

I think from the lens the author is looking at, this is undeniably true. It isn't the complete picture but the folks working on embedded Rust should take it to heart.
Post reply on HN