undefined | Better HN

0 pointsalbinofrenchy9y ago0 comments

GC languages are almost certainly not even in consideration for most embedded applications. There aren't good strategies for general garbage collection that don't insert random pauses for starters, and you also have a non-negligible impact on RAM usage on systems where RAM might be a premium.

A lot of the things rust brings to the table aren't always relevant on embedded platforms. Dynamic memory allocation on embedded is the exception, not the rule. Everything is statically allocated, so memory management is relatively simple -- everything sticks around forever.

The things that make C/C++ good for embedded are sorta what make it unfortunate for general purpose use. The things that make Rust/Go/Swift good for general purpose use make it unfortunate for embedded use.

0 comments

pcwalton9y ago

> A lot of the things rust brings to the table aren't always relevant on embedded platforms. Dynamic memory allocation on embedded is the exception, not the rule. Everything is statically allocated, so memory management is relatively simple -- everything sticks around forever.

In that case, you can simply not use the dynamic allocation features of Rust, just as you can simply not use malloc() in C.

albinofrenchyOP9y ago

Absolutely, but then what does it buy you over C/C++? It has a few 'nice to haves' over that, but in this domain those won't tend to be nice enough to motivate most people to bother setting up toolchains purposed for it.

kibwen9y ago

  > GC languages

Rust is not a GC'd language, it essentially uses RAII to deterministically determine at compilation time when memory will be freed.

  > Dynamic memory allocation on embedded is the exception

Rust fully supports running entirely without dynamic allocation. There is a subset of the standard library defined explicitly for this purpose.

albinofrenchyOP9y ago

> Rust is not a GC'd language

Right, I was referring to Go and Swift with the comment about GC. Since rust didn't have that problem, I mentioned why major adoption might not be forthcoming.

I understand that you can statically allocate all you want in Rust, but it's memory safety, particularly with regards to object ownership is one of its major selling points. Object ownership and lifetimes are trivial when everything is static.

The other arguable selling point to rust is its standard library, but much like C++ the standard library would be left aside in most embedded applications.

So it doesn't buy you much of anything at all, but it takes some work to setup, plus you are fighting the momentum that C/C++ has. Unless there is some other compelling reason to use it, I don't expect much adoption.

j / k navigate · click thread line to collapse

0 pointsalbinofrenchy9y ago0 comments

0 comments

pcwalton9y ago

In that case, you can simply not use the dynamic allocation features of Rust, just as you can simply not use malloc() in C.

albinofrenchyOP9y ago

kibwen9y ago

  > GC languages

Rust is not a GC'd language, it essentially uses RAII to deterministically determine at compilation time when memory will be freed.

  > Dynamic memory allocation on embedded is the exception

Rust fully supports running entirely without dynamic allocation. There is a subset of the standard library defined explicitly for this purpose.

albinofrenchyOP9y ago

> Rust is not a GC'd language

Right, I was referring to Go and Swift with the comment about GC. Since rust didn't have that problem, I mentioned why major adoption might not be forthcoming.

The other arguable selling point to rust is its standard library, but much like C++ the standard library would be left aside in most embedded applications.

j / k navigate · click thread line to collapse