←back to thread

Embedded Rust in Production?

(blog.lohr.dev)
205 points michidk | 2 comments | 14 Oct 24 06:06 UTC | HN request time: 0s | source
Show context
cesaref ◴[14 Oct 24 08:01 UTC] No.41835275[source]▶
The problem I have with articles like this is that if we were to substitute anything in for 'Rust', it would read the same. I imagine if they had re-written it in C it would also be better than before. If it was an advert for anything, it might be chucking away a dodgy prototype and starting again (which is surprisingly rare).

Anyhow, on the other side of the coin, it's good to see newer languages getting a proper outing in real world situations. Proving stuff is 'up to it' can be a bit of a long haul, so every data point is useful.

replies(1): >>41835559 #
simon_void ◴[14 Oct 24 08:50 UTC] No.41835559[source]▶
> Rust takes longer to write than C

> but spent basically zero time debugging

that's the difference to rewriting it in C

replies(1): >>41835876 #
1. nicce ◴[14 Oct 24 09:42 UTC] No.41835876[source]▶
One could argue that when the program is finished without bugs, then it is maybe completed. So does it take actully longer to write with Rust?
replies(1): >>41836084 #
2. pornel ◴[14 Oct 24 10:21 UTC] No.41836084[source]▶
It depends how proficient you're in Rust. Once Rust itself is not a difficulty for you, there's a lot of productivity gained from having a modern language with many conveniences, and great tooling.

Rust moves more bugs to compile time, so you will technically spend more time getting the code to compile, but in my experience in 99% of cases it's a time saving. And it lets you be more confident about a program correct by construction, rather than merely fuzzed and not observed to crash. The 1% of counter-examples is trying to be too clever with generic interfaces and hitting Rust's limits.