This post makes me extremely happy. :D

> among the sites of its peers, only Ruby is similarly localized. Given that several prominent Rustaceans like Steve Klabnik and Carol Nichols came from the Ruby community, it would not be unreasonable to guess that they brought this globally inclusive view with them.

Not just that, I actually looked at how Ruby's website did it in order to bring it to our site. This has... issues. But it's served us fairly well.

Additionally, while there's so much more I could say about this post, one thing:

> my naive Rust was ~32% faster than my carefully implemented C.

This is a metric I'm more interested in, far more interested than classic benchmarks, where various experts eke every last little bit out of an example. What's the average case here?

It is, of course, much much harder to get numbers for these kinds of things...

I talked to some embedded C programmers and they said thad basically everything besides C is too slow for their use-cases.

I would be interested if they're wrong, hehe

In my experience speed is rarely the problem for embedded systems - usually it's more about code size. And tooling.

I'm an embedded engineer, who's been tinkering a bit with learning Rust; so far only for an application-level project, but am keen to try it out in embedded. So far, it's been fun and exciting, along similar lines as Bryan wrote about in the OP. In fact, a video of a talk he did (https://www.youtube.com/watch?v=LjFM8vw3pbU) is what pushed me to getting started.

I think you're spot on with regards to tooling being a major concern, and to me, this is one of the promising aspects of Rust, with cargo at the high level and the LLVM tools lower down. It seems like a system that's primed for open source libraries targeting specific families of chips, cleaning up the mess we've got now with each vendor having their own framework, IDE, configuration tool, etc.

Speed and size concerns though, seem to depend a lot on the specific project. In the last couple years, I've worked on systems that had neither/either/both of those as the primary challenge. Of course in embedded, where you try to save money on parts early in a project can determine the technical (and so, schedule) challenges later on.

And, I'd add safety to the list, having spent loads of time finding bugs in legacy C caused by stuff like walking off the ends of arrays, jumping to uninitialised function pointers, fun with enums and unions, etc.

James Munn gave a super interesting talk at this year's RustConf about some of the abstractions they're building for embedded systems: https://www.youtube.com/watch?v=t99L3JHhLc0

I think Rust is in a great position to become incredibly useful in the embedded space.