Binaries compiled from Go are 50 to 100 times bigger than similar functionality using C. The “blink led” program is 20 to 40 bytes on embedded C (plus platform-dependent boilerplate).
MicroPython advertises itself as being able to fit in 256 Kilobytes, so i dont think it will be better than Go.
Especially for mass production (thousands of flash chips), using frameworks with big run-time boilerplate is just uneconomical. This is also the reason why, even with Go and Rust, embedded will stay an stronghold for C.
Sure, but there’s definitely a constant overhead factor. A trivial program will have a lot of size overhead from the runtime. A nontrivial program will not have so much.
The smallest known ELF binary produced by Rust was 151 bytes. While WASM isn’t exactly an embedded thing, conceptually it’s similar, and a single “plus one” function compiles to ~100 bytes.
There are lots of barriers for Rust in this space, but binary size shouldn’t be one of them.
I consider rust one of the candiates that have indeed a chance here. I’ll wait until the toolchain and interfaces have somewhat stabilized, hoping they’ll ever do (Which many trendy things dont).
What kind of instability are you worried about? We take the stability of the language quite seriously. This (embedded) isn’t my area of expertise though, so always looking to collect feedback!
Lack of well defined and stable ABI and second tier support for more exotic hw platforms. ABI problem can be fixed by Rust team, but unless hw vendors start shipping rust and llvm, it will be hard for rust to break into embedded.
Im sure it could be made smaller given OcaPIC got some Ocaml on a PIC microcontroller. That seems harder. Far as alternatives, Astrobe lets people use Oberon. That’s a bit closer to Go given it’s inspired by Oberon-2 partly.
I wonder how this compares with other languages designed for the embedded space, like micropython.
Binaries compiled from Go are 50 to 100 times bigger than similar functionality using C. The “blink led” program is 20 to 40 bytes on embedded C (plus platform-dependent boilerplate).
MicroPython advertises itself as being able to fit in 256 Kilobytes, so i dont think it will be better than Go.
Especially for mass production (thousands of flash chips), using frameworks with big run-time boilerplate is just uneconomical. This is also the reason why, even with Go and Rust, embedded will stay an stronghold for C.
Sure, but there’s definitely a constant overhead factor. A trivial program will have a lot of size overhead from the runtime. A nontrivial program will not have so much.
The smallest known ELF binary produced by Rust was 151 bytes. While WASM isn’t exactly an embedded thing, conceptually it’s similar, and a single “plus one” function compiles to ~100 bytes.
There are lots of barriers for Rust in this space, but binary size shouldn’t be one of them.
I consider rust one of the candiates that have indeed a chance here. I’ll wait until the toolchain and interfaces have somewhat stabilized, hoping they’ll ever do (Which many trendy things dont).
What kind of instability are you worried about? We take the stability of the language quite seriously. This (embedded) isn’t my area of expertise though, so always looking to collect feedback!
Mostly API stability. But thats sort of inevitable for a young project of that complexity.
Lack of well defined and stable ABI and second tier support for more exotic hw platforms. ABI problem can be fixed by Rust team, but unless hw vendors start shipping rust and llvm, it will be hard for rust to break into embedded.
Im sure it could be made smaller given OcaPIC got some Ocaml on a PIC microcontroller. That seems harder. Far as alternatives, Astrobe lets people use Oberon. That’s a bit closer to Go given it’s inspired by Oberon-2 partly.