←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. zifpanachr23 ◴[14 Oct 24 16:29 UTC] No.41839074[source]▶
It's widespread practice to notate who owns what in the comments in C code. "Ownership" as a concept comes from well established C best practices and a good C developer is going to understand exactly what you mean if you say something like "Caller owns the memory returned from this function" etc.