Rust in 2018: Let’s fix where the bullet holes aren’t

Although I’m a rust beginner, I’ve thoroughly enjoyed reading all the Rust 2018 blogposts lately. And as a systems engineer who leans towards embedded work, I especially enjoyed one recent post about embedded rust. I do think Rust has a lot of room to expand in the embedded environment. Sometimes it seems like there is just one guy working on embedded projects and carrying the torch for a target audience which would be a wonderful focus point of Rust — embedded systems. And in the vein of “representation matters”, it can be slightly disheartening for embedded systems engineers to see big, hyped, and de facto sanctioned projects for asynchronous I/O (like mio, futures, and tokio) and always be presented with examples of HTTP GET Requests, or database queries, or TCP Servers.

One recent exchange I’d like to focus on happened in the reddit comments of the above linked blog post. Here, a programmer mentions some difficulty they had been having with supporting embedded SDKs as Rust, and Steve Klabnik helpfully responds asking more about the issue, saying “We tend to prioritize production users’ needs, if we can”. I think this is really crucial and his response reminds me of a famous story of armoring bombers in World War II. Jordan Ellenberg’s recounting of the story can be found, in part, here:

So here’s the question. You don’t want your planes to get shot down by enemy fighters, so you armor them. But armor makes the plane heavier, and heavier planes are less maneuverable and use more fuel. Armoring the planes too much is a problem; armoring the planes too little is a problem. Somewhere in between there’s an optimum. The reason you have a team of mathematicians socked away in an apartment in New York City is to figure out where that optimum is.

The military came to the SRG with some data they thought might be useful. When American planes came back from engagements over Europe, they were covered in bullet holes. But the damage wasn’t uniformly distributed across the aircraft. There were more bullet holes in the fuselage, not so many in the engines.

souce: https://en.wikipedia.org/wiki/Survivorship_bias

The officers saw an opportunity for efficiency; you can get the same protection with less armor if you concentrate the armor on the places with the greatest need, where the planes are getting hit the most. But exactly how much more armor belonged on those parts of the plane? That was the answer they came to Wald for. It wasn’t the answer they got.

The armor, said Wald, doesn’t go where the bullet holes are. It goes where the bullet holes aren’t: on the engines.

Now, I don’t know if the seeming lack of permeance of Rust into the embedded world so far is due to survivorship bias or not. But it is very possible that potential embedded engineers are being turned away, or existing embedded engineers have left Rust. I don’t have enough experience in the Rust community to be able to make that assessment. Hopefully, this is something that the annual Rust Community Survey can shed some light on. Unfortunately, the Rust Community Survey itself may be affected by survivorship bias.

But regardless of survivorship bias, adopting a policy of “ [prioritizing] production users’ needs” will have the effect of concentrating the focus of the Rust project on the largest existing projects and most prominent existing users. Features will be promoted that boost those domains and scarce development and documentation resources will be spent expanding Rust into new frontiers. The result is a real risk that the ecosystem becomes more and more stratified until Rust becomes only known for (and only used for) one application domain.

Of course it is a balance — if our goal is to do the community the most good, we should make improvements that a majority of users benefit from. A small feature used by a large number of people can have a tremendous positive effect. But I believe another goal of the Rust project should be wide adoption, and making a language and ecosystem as welcoming to everyone as possible.

I suppose I should also list a few concrete things I would like to see in 2018. I know that as of right now my money is not where my mouth is — I haven’t done any work towards making progress on any of these items. That is something I hope to change in 2018!

1. It might be nice to see some focus on expanding platform support. Maybe some of the Tier 2 platforms can move up to Tier 1, and Tier 3 platforms could move to Tier 2. I would love to see the addition of even more architectures! I am looking forward to hopefully compiling my projects for AVR someday.
2. Const generics would help a lot in laying a foundation for solid high performance linear algebra library. I’ve read past the end of a vector in EigenC++ on several occasions . Rust should be able to provide a safe, high performance alternative.
3. SIMD support would be great for the platforms that have it.
4. I personally wouldn’t get much use out of inline assembly, but I’m sure a lot of people out there would!
5. More classes, guides, tutorials, and examples of Rust in the embedded world!

I’m sure there’s much more.

Embedded systems isn’t the only area that deserves attention. I hope we broaden our scope as wide as possible. After all, there are only so many developers in one application domain. So broadening scope therefore becomes the best way to achieve mass adoption. It may be best to prioritize the needs of those who don’t use Rust at all.