←back to thread

Embedded Rust in Production?

(blog.lohr.dev)
205 points michidk | 3 comments | 14 Oct 24 06:06 UTC | HN request time: 0.002s | source
Show context
nsoonhui ◴[14 Oct 24 09:06 UTC] No.41835659[source]▶
I'm ignorant about Rust, but to me it's just static type language akin to C#. And C# has IOT library which seems to target Rust most usual use case, namely on embedded platform. C# also has memory safety just like Rust.

So why do we need Rust at all? What's the use case for it?

Anything that I'm missing?

replies(5): >>41835666 #>>41835762 #>>41836656 #>>41839000 #>>41843390 #
15155 ◴[14 Oct 24 09:06 UTC] No.41835666[source]▶
> Anything that I'm missing?

C# is garbage collected. This is a no-go in many/most embedded software applications.

C# also grants you poor explicit control over heap/stack allocation: this is essential for embedded development.

replies(3): >>41835721 #>>41838112 #>>41838658 #
1. neonsunset ◴[14 Oct 24 15:50 UTC] No.41838658[source]▶
C# is the language with the best degree of control over allocation among all GC-based languages. You can write code that is completely allocation-free including abstractions. Most "data processing" APIs in the standard library do not allocate at all or allocate once for initializing e.g. lookup tables.

The actual issue is existing selection of runtimes for embedded platforms is limited: https://nanoframework.net/ and https://www.wildernesslabs.co/device (to be fair, a friend of mine uses the second one for automating his lab for his microfluidics devices research project, so it is useful).

replies(1): >>41840559 #
2. 15155 ◴[14 Oct 24 18:45 UTC] No.41840559[source]▶
> C# is the language with the best degree of control over allocation among all GC-based languages.

It's the best, but if I can't say: "never heap allocate under any circumstances," it's a problem.

replies(1): >>41840747 #
3. neonsunset ◴[14 Oct 24 19:04 UTC] No.41840747[source]▶
You can :) It just requires going out of your way a bit. It effectively works as C with better type system and generics (C++ lite if you will), that can be either JIT or AOT compiled (statically linked too). For example https://github.com/bflattened/bflat has a target flavour that does not support GC at all.

I'm not saying it's an optimal choice for embedded, only pointing out that you can write allocation-free code with confidence. Patterns that allocate are known - predominantly boxing and closures. You can easily avoid both, you can also declare your structs as 'ref struct' which completely prohibits placing them on the heap, either as a box or as a part of heap-allocated memory inside some other object/struct.