Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I used to work as an embedded systems developer (for systems where a single failure could cost a quarter million dollars), and I've experimented with kernel-space Rust just for fun.

Rust is a surprisingly nice language on bare metal.

If you use '#![no_std]' in Rust, it disables the standard library and substitutes the 'core' library. This has no 'malloc' (unless you supply one, which is easy) and no OS-level features. But you still get iterators, slices, traits, "scoped" closures and generic types. You get a lot of abstraction with basically zero overhead. And don't forget that embedded systems have lot of state machines, which are nice to implement using Rust's "tagged union" support and exhaustive 'match' statement.

Here's an example of a Rust I/O port wrapper (https://github.com/emk/toyos-rs/tree/master/crates/cpuio) and an interrupt controller interface (https://github.com/emk/toyos-rs/tree/master/crates/pic8259_s...). These APIs are reasonably pleasant for something so close to the metal.

Rust would be a very agreeable programming language on an AVR system, IMO. And not necessarily because of pointer safety, either.



As a hobbyist and C junior, if I can get anything higher level than C, I'll be ecstatic. Of course, it's going to be the same as with micropython, which is fantastic: The entire ecosystem is in C.

I tear my hair out every time I have to wrestle with C for the simplest things, though, whereas Rust is a joy to write.


On "full size" systems we solve that with FFI, but I don't know whether that would work here is not.


Having recently worked on a few projects written in C++11 for embedded systems (again, no standard library), I must concur with your comment. C++11 brings a lot of the same features (minus the functional coding components) to embedded systems making program flow a breeze.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: