Thoughts on Rust

Edit: o uau, this post got picked up by the fine folx on reddit! hello reddit peeps, thank you for reading this post ^_^

I’ve been working on some rust projects recently and I really really love this language. I’d love it if one day I could get paid just to write rust! Until then, I’ll make do with trying to contribute to the community, despite life being overly busy and wishing that I had just a few more spoons to spend right now.

I was tooling around the rust internal forum when I came across a p. exciting post there, asking for peeps in the community to write stuff about what they want out of rust. Since I’m so excited about the language and I’d love to contribute to it somehow, I figured I’d toss some words on a page, so here they are!

Tooling: roogle?

I think rust has pretty great tooling in general. I really appreciate cargo, I think it gets package management right in a way that many other languages fail to do (and then third party tooling makes a mess of the ecosystem). However, as one internals forum post indicates, it’s not always easy to find a crate which would be good for your project on crates.io.

This seems to be a problem that’s pretty universal — npm is a good example of what happens when you put a lot of incentive behind developing in a language (webdev == $$$): you get a venn diagram of 50million libraries, each which accomplish approximately the same goal, but in mostly-incompatible ways, and under mostly-incompatible assumptions. js has bred a universe of lies and deception, and that universe is called npm .

I think one reason for this is that javascript is really hard to describe using syntax/semantics alone — you need humans to describe what a package does, and by that point it’s too late. Haskell, on the other hand, mitigates this somewhat, by having a strong-enough static type system + syntax that it becomes possible to search for code using the actual language syntax.

I don’t know if it’s possible to make “roogle” (AKA hoogle but for rust), but I believe that the preconditions are pretty good — rust’s syntax is designed for static analysis, down to the typechecking and borrowing semantics. Sure, there’s some modification to hindley-milner to make subtyping work, but I think that the design of the trait system is both good enough and young enough that it would be possible to design a query language that lets people search for functionality based on function signatures, lifetimes, traits, and maybe some additional sugar. Who knows.

If such a tool could be constructed, it might go a fair way in making it easier to find crates which already define the behavior that I need for my projects. Maybe I’m wrong, maybe the non-curried function syntax of rust and the proliferation of custom traits and types would make this too hard to accomplish. Macros certainly make it at least a little hairier. But it’s an idea and there it is.

One final point: if it is actually possible to make “roogle”, its mascot must be a dog.

Support More Microarchitectures (for fun projects)

To clarify this heading, I’m mostly thinking mostly about arduinos. The raspberry pi seems to have more support than the arduino right now (which makes sense, the pi is much more of a computer than a microcontroller, and it runs a bona-fide linux distro).

I think it would be fantastic to be able to program more microcontrollers in rust. The language guarantees would make it really fun to build networked devices which work with each other concurrently to do cool stuff — weight-activated lights, wifi-sniffers, the works. Travis Goodspeed is my inspiration here.

Documentation: More User Guides

The racket community has a great practice when it comes to documenting code: authors will usually write two pieces of documentation.

  1. Reference documentation, which is what you usually expect — “function foo takes these args, produces these outputs, etc. etc.”
  2. user guide — an explanation, sometimes from first principles, of what the things is, and how to use it.

I think this is one of the most fantastic practices in a language community that I’ve ever seen, mainly because it’s so widespread. It’s as important for core modules like scribble as it is for community contributions like lens. It makes getting started with a module much easier, because the author themselves has taken the time to write out a simpler set of documents for the average kid to read and understand. And, makes it easier for the average kid to evaluate the use of a module — will it suit my needs? Will it become a maintenance nightmare down the road?

I think that the rust community would do itself (and the future contributors) a huge favor by making this practice more widespread. Certainly, some tool authors do this today, seemingly out of goodwill — but I don’t think that people put nearly as much time or effort into simple documentation as they could. I would love it if a substantial user guide were required to upload to crates.io — it’s not good enough to just document the functions/structs/traits therein, nor even to have a 1-page “getting started” section in the crate description. If you write something useful and you want people to actually use it, you have to put in the work to describe what those things mean from first principles.

Take, for example, the three most-downloaded crates as of the time of this writing — libc, bitflags, and serde. Of these three, only bitflags and serde have something that resembles a user guide. Of those two user guides, serde is the only one with a multi-page user guide, including descriptions of the data model and many examples. From thereon out, down the list of most-downloaded crates, documentation is fairly hit-or-miss.

I claim that building a community culture which emphasizes and values user guides as necessary parts of documentation will go a long way in keeping the rust language community healthy and inclusive — and will pave the way for contributors from all walks of life. Again, making things easy is not a crime. If we want everyone to be able to contribute to the community, then it’s got to be easy for anyone to get started without knowing much, if anything, about the building blocks we make available.

Diversity

The rust community seems to be pretty populated by techies right now.

This makes sense! rust is a programming language under active development, and many of the people developing it are techies by definition. But, having lived in San Francisco for a year and a half (and gladly left), I think that this is significantly coloring the community contributions.

The community has a lot of white men.

This isn’t a bad thing on its own, but it also has a somewhat chilling effect on getting non-white-men involved. I had the personal experience of going to a rust meetup and being (unfortunately) unsurprised to find pretty much a room of men (from what I could tell, if there were other trans people there they weren’t flagging enough for me to tell). The meetup was fine, but I personally don’t think I could “sell” a rust meetup to a number of my friends. “Why should I subject myself to an hour of confident men when I could do literally anything else?” Which leads me to:

People have detailed opinions about small niche things.

This is more of a warning sign than an outright fault. People having detailed opinions about small niche things is a good thing! It means that people are focused on getting things right.

That said, I’ve noticed that communities which have detailed opinions about small niche things can become pretty exclusive pretty fast, usually due to the manner in which these detailed opinions are delivered. When they’re typically delivered discompassionately by established, confident men, it usually undermines any other attempts to make a community more diverse — because while discompassionate “statements of fact” are usually seen as virtues in tech, this kind of behavior is also deeply patriarchal. The Haskell, Linux Kernel, and C++ “communities” are decent testaments to this, in my mind — they are comprised of a lot of people who like to well, actually, and that rapidly excludes a lot of valuable voices from the conversation. The LKML is famous for being a terrible place (trans lens: where mostly men go to argue about being right on the internet).

This isn’t to say that I think the rust community is doing these things, but I think that rust pretty readily appeals to the same sorts of people who populate the aforementioned communities, and I’m personally really wary of the rust community inheriting that culture. The Recurse Center manual points out a number of related things that I think the Rust community should also think about (full disclosure: I have no relation to RC aside from knowing a couple people who went there).

Ok, so… now what?

Teach!

Overall, I’d really like to have more non-white and non-male contributors in the community. Having taught for a while, I think one way to do this would be to have some sorts of materials that kids/students could use, and then try to bring these materials to afterschool programs. I co-taught an afterschool AP CS class where we had to use Java (an unfortunate constraint of the AP exam), and I think that this sort of curriculum could be adapted to rust pretty easily. It wouldn’t be usable for AP CS, but it would be usable for intro programming materials, like the Hutton 2.0 program (I was a mentor there for a summer). We were teaching C# (because of Unity) — but if there was a good way to put together games in rust, we could have used rust instead.

Make things easier!

A corollary point to this would be to invoke _why’s contributions to the ruby community — I love _why’s work, and I view much of the excellence of his work to be rooted in his commitment to teaching kids, and to making things easy. His whole portfolio echos this philosophy. I think we need more people to follow _why’s example in the rust community. I’m happy to try to do that myself, but I’m still too new at rust to have a significant effect. It would be amazing to have a poignant guide to rust, or a shoes-esque UI tool for rust programming. Making things easy is not a crime.

Leave a Reply