←back to thread

Embedded Rust in Production?

(blog.lohr.dev)
205 points michidk | 1 comments | 14 Oct 24 06:06 UTC | HN request time: 0.001s | source
Show context
baq ◴[14 Oct 24 07:45 UTC] No.41835199[source]▶
As expected, the people problem is the biggest factor. Turns out getting C folks to learn Rust is a difficult proposition (hello, lkml) but the other way around it isn't too much of a problem.

I wonder how much of it is low-level experienced developers only ever using C fail to see that C is not the universally best tool (or, 'if all you have is a hammer, everything looks like a nail' question).

replies(5): >>41835262 #>>41835561 #>>41835870 #>>41836074 #>>41836108 #
fulafel ◴[14 Oct 24 08:50 UTC] No.41835561[source]▶
The complexity of Rust is on another level, it's a huge language.
replies(1): >>41836290 #
baq ◴[14 Oct 24 10:53 UTC] No.41836290[source]▶
It’s a tradeoff. The ownership rules are mostly the same as C. The difference is that Rust enforces them at compile time.
replies(1): >>41836710 #
fulafel ◴[14 Oct 24 12:03 UTC] No.41836710[source]▶
Hrm. These are the top level Rust ownership rules according to the book[1]:

    Each value in Rust has an owner.
    There can only be one owner at a time.
    When the owner goes out of scope, the value will be dropped.
C has none of these. Or borrowing, etc.

[1] https://doc.rust-lang.org/book/ch04-01-what-is-ownership.htm...

replies(3): >>41837086 #>>41839074 #>>41839855 #
1. wyager ◴[14 Oct 24 17:42 UTC] No.41839855[source]▶
Using pointers correctly and safely in C basically requires tracking pointer rules substantially similar to the rust pointer rules, but in your head. Most people who don't do this just write incorrect code, although it might only rarely cause a serious problem.