Rust2018
Rust, in no small way, has captured quite a bit of my imagination in the last 4 and a half years. The language and community has a lot of love to share. That doesn’t mean there’s no room for improvement. Reflection powerful tool for improvement. Because the Rust maintainers are smart, they also realize this and lit up the crab signal for community posts about reflections on accomplishments 2017 and goals for 2018. Since then, there have been a flood of thoughtful responses shared on twitter. Feeling a bit inspired, I decided to write down some of my own Rust reflections.
A bit on where I’m coming from for context. I’m a curious dabbler. I’ve been in and around and sometimes between the Rust community since about a year before it was stable. I’ve cultivated lots of little crates over the years. I still don’t consider myself to be an expert with Rust but I’ve learned a lot through experimentation and interacting with its awesome community. One thing I’ve learned to be a truism: stable foundations enable incredible things. When stable Rust landed, it exploded ( in great ways ). I’ll let is the theme of this post.
2017: The Highlight Reel 🎥
🎉 An async version of hyper was published ( on crates.io ). Tokio was really the catalyst for this and the futures crate was really the catalyst for that. Why this was huge for the community was that hyper serves as a foundation for building http servers and clients within the Rust ecosystem. It took a while for hyper to have an async story because the Rust ecosystem didn’t have a stable and common foundation for async programming. The async foundation is still settling, but the building blocks are now sharing a consistent shape. This enabled crates like hyper to create a ripple effect of forward progress.
🎉 Serde 1.0 was published. What made this amazing for the community was really that you could use serde, as intended, on stable Rust. The catalyst for this was the foundation for procedual macros stabilized. Prior to this, if you wanted to use serde as nature intended on stable Rust, you were forced to go through some interesting build gymnastics with cargo and custom build.rs scripting. Looking back, it was kind of embarrassing. Despite how amazing the serde library is, the setup for how one actually used it on stable Rust was not exactly how you’d impress your non-Rust friends.
🎉 Ripgrep happened. What made this special is not necessarily what it did for folks learning Rust but in how it showed others what using Rust can look like. I can’t understate how amazingly fast (and useful) this tool is. One of the most common activities folks that live inside terminals do is finding things. I graduated from grep to ack a few years ago because of how much time it saved me. It was like an exponential leap. ripgrep is the next exponential leap, and it’s a leap that I firmly believe Rust enabled. The hat tip to this tool for me was watching a golang talk where the programmer used ripgrep in their go demo and called it out recommending it to the audience. It’s a good sign to see other communities adopting Rust tools for the sake of the value they produce, not just the language they were authored in. We need more of these as examples to show that Rust is not just for curious programmers. It can make amazingly useful things!
🎉 Rocket happened. I’m not sure if this was technically dec 2016 or jan 2017 but it happened and when it did it was amazing, not because of and interesting feature of Rust but because it was a shining example of what a Rust project should look like. I’m emphasizing “project” because what made it a big deal and so quickly was that it was more than just code and a readme. It launched with amazingly helpful and branded documentation. This set the bar a bit higher for Rust projects in general.
🎉Clap is still keeping it real (and awesome). It’s tempting in any language community to want to jump from one idea to the next, leaving incomplete artifacts of your interest in your wake. Clap to me is a perfect example of a focused project that just keeps gets better over time because of strong and good project ownership. Clap is not a new project and command line processing is not a particularly sexy domain for most, but it’s an essential domain and one its maintainers continue to improve and make a strong foundation for cli apps in Rust. It sets a good example for what a maintained Rust project should look like.
Many other great things happened in 2017, but others have captured them better in their #rust2018 posts
2018: What’s next for me
For myself, I want to commit to the following.
Make people (IRL people) central to the Rust ecosystem. This means getting more involved in ( and keeping alive ) the local NYC Rust Meetup. This is something I’ve been procrastinating on for far too long. In the past I’ve also expressed much interest in helping create a local Rust bridge. It turned out there are some fine folks who actually went out and did it, picking up my slack. In 2018, I want to commit to helping grow that as well in what ever way I can. People are the most valuable asset a community can have. We should be heavily investing in our IRL communities in what ever capacity we can. We are more than just the code we write. We’re people too!
💼 Adopting more Rust at work. I’ve been the catalyst for more than a few tools as well as a handful of internal micro services written in Rust at work. I want to commit to actually writing up company posts about that to show other companies that “yes, you can do that too!” because Rust has really great tools out of the box to make enable this. More than one may think given how young the community is. More than that, I want to make a commitment do more evangelizing. Evangelizing and adoption is more than just showing up with working code and looking like a wizard ( Rust will not always make you look like a wizard but when it does, wear the hat proudly 🧙 ). Adoption is teaching and at least 2 quarts empathy. Luckily there is a increasing large pool of quality learning resources for Rust like this that reduce the burden of organizations needing to manage their own learning resources. Having an internal #rustlang channel to share learning resources is also a good and easy way to get started with Rust within your organization for curious programmers and potential rustlings.
💁 Contribute to more projects that are not my own. If you are like me, you may suffer from this type of behavior
I’m constantly on a curiosity voyage. Rust is like my paddles and I need my paddles to travel. As a result I’m typically working on more projects than I should because I find everything so amazingly interesting. That’s not always the best use of my time strategically. A good foundation is build on community. A community is a group of people working together, not separately, on semi related projects. I would rather have one really great crate with 3 people working on it together than 3 semi okay crates that are all in some way incomplete and don’t ingrate well. I already have some initial ideas for contributing in areas of community tooling like feature gaps in rls vscode ( which I’m currently using daily ) and various network programming crates. Again, a stable foundation is important for amazing things to happen. My commitment here is to shift the focus of my curiosity and energy and exercise different ways to contribute to the foundation of the community. Rust as an ecosystem is not new to this kind of thinking. The RFC process and working groups are great models for how we can work better together to solve bigger problems as units. I’ll try to spend more time thinking about collaboration efforts this year than I thinking about new projects. We’ll see how that works out in a follow up #rust2019 post!
✍️ Write more. I have half a dozen drafted posts on Rust that I never make the time to fully complete. Writing blog posts is an incredibly rewarding and useful activity but also a very time consuming one. My last goal is to make sure I’m writing more about what I learn about in my experiments with Rust in 2018 and actually posting them!
2018: What’s next for the community
For the community in 2018, I’d like to see the following.
🔐 Have a default story for tls. We currently have good tls support, but not a default story. This has a heavy toll on the community in terms of new project assembling. For hyper, this means it doesn’t and won’t support https out of the box which means you’ll have to assembly your own set of crates to establish secure connections with the internet. This is disappointing for new comers to Rust. Https is becoming the default of the web and we should have a good default story to support this. I think the tls situation is one of the key motivators for reqwest. I’ve always been suspicious of reqwest because it really doesn’t add that much value over vanilla hyper::Client. It adds a few conveniences that I think would not be needed if a good and stable foundation for tls ( and a few other things ) were available and could exist within hyper itself. Like the minor embarrassments of using serde before it had the strong stable procedural macro foundation, the necessity of crates like openssl-probe are embarrassments of using tls in Rust in today. I hope the default story for tls reveals itself in 2018!
☁️ Have a better stable foundation for network programming. Hyper 0.11 was a huge enabler but there are still some things that hold it back from being truly complete. Namely things like connection and server timeouts built into the underlying crates. I believe this is blocked by tokio reform. An outsiders perspective may find this confusing and frustrating. We really have to prioritize a stronger foundation for network programming in order to have it more adopted in larger organizations for more serious workloads that require adapting to “cloudy conditions”.
🍽️ Finish what was started in 2017. There are alot of great things currently in flight that came out of Rust 2017 initiatives. I really can’t wait to finally be able to actually use them. Function signatures that specify return types that only describe what they “impl” vs leaking concrete types everywhere in api’s is the thing I’m most personally excited about. We need to really buckle down an focus on launching these in stable rust before starting new things. For realz.
🐝 Wasm. I understand that Rust is a very strong contender in this space, but I don’t want to lose focus of the goal. The goal here is not to force Rust, the goal is a good wasm experience. Pushing Rust too hard here can appear from external perspective that it’s being forced, especially from those where this is their first encounter with Rust. Yes rustaceans are excited that wasm can be the way we can get Rust out on the dance floor showing off our moves to a new crowd. For those just learning what a rustacean is, they may not immediately appreciate Rust forcing its way through the the front door, even with our safety and concurrency badges in full view. I don’t think we want that kind of reputation. That kind of reputation is hard to undo once experienced. Rust has a lot to offer and the wasm space is a good opportunity to get javascript engineers interested in Rust but there are some things Rust could also be working on to make that initial experience great. i.e compile times.
🐇 Compile times. More often than not compile times are a cost that advanced languages realize they need to pay down after the point where it’s really difficult to improve. I learned this with the scala community and it’s still struggling with slow compile items. I realize that there have a already been many compiler speed improvements ( cargo check was a nice gift ) but I believe that to get more adoption from other communities where we are trying to step in and save the day, we should make sure that we’re at least being considerate of local customs. One local custom for the web is fast turn around time between code changes. Things like adding a println!, compiling to wasm, then reloading a page are way too painful at this time. There will always be some inherent “pain” in waiting for a compiler, the Rust compiler is our friend after all and we like our friends, but we should put more focus on making that pain as light as possible and make that fast compile time a “feature” of the language.
👩💻 Do more than just post about our greatness. We should post more about our faults, acknowledging them, and how we plan to address them in order to rectify them. One area Rust, and many if not most programming communities, could do better in is building diversity into their ecosystems. It is one thing to say you support diversity, but another to actively seek it out. Rust should actively be seeking out diversity. An experiment I like to do is that for any language community conference ask, what is the ratio of women speakers to men speakers? For any given programming meetup, what is the ratio of women to men attendees? The result is always disappointing to me. I really admire initiatives like Women Who Go and PyLadies. It makes me believe there’s hope. We should consider it a fault of the Rust community ( not of individuals ) that such an initiative doesn’t exist for us, at least not that I know of. It’s our individual responsibility as a members of a community to ensure a healthy diversity of people so that we ensure a healthy diversity of thought and perspective. Without those we’ll be searching for many years and continue asking ourselves why we don’t yet have the stable foundation we keep looking for.
