Rust2019
It’s the time year to reflect on the past and to make wishful prospects for the future.
2018: The Highlight Reel 🎥
2018 was a good year. When I look back at my notes from last year at this time I’ve accomplished some of my goals but not all of them to their fullest.
🏠 I’ve tried to get more active in helping host more local Meetups with the NYC Rust Meetup to help grow the community. I’ve always been active to some degree in local Meetup’s in NYC. In recent years I’ve felt a decline in my participation and I’ve missed the IRL experience. I’ve had a chance to make new friends this year by reactivating myself locally. Next year I’m committing myself to speak/teach more at these Meetups.
✍️ I told myself I would blog more about Rust (not just code). I procrastinated on this but picked up the slack toward the end of the year by setting up a streak where I tried to publish one post about Rust every week. The experience was rewarding and though hard to keep up. I’m going to try to sustain some level of commitment to continue writing posts in 2019. I honestly think blogging is an unrealized tool to grow the communities pool of easily accessible shared wisdom. I’d like to see more of this.
📰 Hear ye, hear ye 📢 2018 got an new edition and as a result, saw the stabilization of many community tools! This should really be a bunch of individual highlighted points because there are so many great improvements that fell out of these changes, but because this is so recent I myself am not fully up to date on all of them. I’ll just leave a note about my favorite. In the category of things in Rust you no longer have to do… 🥁you no longer have declare linked dependencies with extern crate in source files! While I understand the desire to keep cargo, the tool, separate from source code semantics, users felt the impact of the redundancy. Putting a stronger focus on developer experience was a strong plus for me here. I hope Rust does more of this in the future.
2019: What’s next for me
⚡In an interesting twist of fate at the tail end of 2018, AWS announced support for open Lambda runtimes and showed commitment to supporting an official Rust runtime in the form of on open source project. Those that know me, know that I’ve been working on improving the story for serverless Rust for more than a year now. While I’m proud of that work, I value what I learned more than the artifacts produced. I decided to re-invest what I’ve learned into the AWS supported Rust runtime and put a maintenance label on past work. This is better for the community having more shared experiences contributing together than apart. I’ll be definitely doing more work in this space ;) The 2018 AWS reinvent announcement list left no shortage of new tools that change the story for what the future will look like.
🐚 Related to the above I’ve been working more closely with the rusoto team to improve the AWS SDK story for Rust. This is getting much better but more people need to get involved to make it happen. Much more work still needs to be done to call this on par with AWS SDK’s in other languages. If you have any interest here, jump right in. There are many ways to contribute, more than just code.
👨🌾 Be a better maintainer. I own a lot of github repository based projects but I can’t say a maintain a lot of github repository based projects. It’s taken a long time and a lot of experience and guilt to realize this. I’ll be posting more on that I mean by this in the future but something I’ll be expecting more of my self is investment in better processes for project maintainability not just more the generation of more source code!
2019: What’s next for the community
🐇 Compile times. This is a carry over from last year. It got a little bit better but not a lot better. Honestly, I think if even it got a lot better it should continue to get even better, year after year. Compile times is a core developer experience when it comes to a compiled language like Rust. Consider the analog of mobile devices. With every new mobile device release there’s typically an announcement about how much better battery life got. A year passes and new bar is set. Then you get better next year, and the next. For compile times, I want to hear a story about them getting drastically better year after year, not minutely improved and then tabled on the next year. After a year passes new bars and expectations should be raised and compile times should drop to meet them. Compile times account for a measurable amount of productivity time lost while developers are stuck in a waiting state. As Rust makes it’s way into more production systems long compile times also keep continuous integration and deployment systems in a waiting state. I realize this is a hard problem and yes tools like sccache exist, but they are a crutch to lean on and complicate the toolchain. Fast compile times should be a language feature, not an after thought that needs additional tooling to accommodate. Unfortunately compile times was listed last in the prioritized list of things the Rust teams are likely going to invest in in 2019. If you also feel strongly about this. Please speak up in your #rust2019 posts and your local Rustlang representatives! 🙏
✋🏿The current minority report makes me sad. Though the story is getting better, the results of Rust’s diversity efforts are still not at their best. Rust bridge looks promising not to mention this
But in order to reflect on impact, one only needs to visit your local Meetups and conferences. I still see pictures of rooms full of almost entirely white males. We need to improve in this area this as a first class community priority. I realize this is also a hard problem so solve but like compile times, we should never stop improving in this area year after year.
🙈 Rust usage will be revealed where you wouldn’t expected it. This year I observed many interesting announcements about cloud CDNs like cloudflare and fastly offering a new wasm-based serverless offerings. This is interesting as it reflects an alternate future to container based runtimes. As you may have heard, the story for wasm in most circles already includes Rust as a main character. If you weren’t paying attention to wasm or Rust in the last year, now may be a good time to start! AWS made an interesting announcement about its impressively fast Rustlang vm provisioning software called firecracker that it’s rolling out to improve the startup times and isolation of its AWS Lambda runtimes. This is also interesting in that it could change the story for container centric runtimes. Containers aren’t going away, but like any technology the landscape that exists around them changes. Even if you don’t plan on running your own Rust lambdas, ( which you totally should ), you’re lambdas will still running on top of Rust in production! I think Rust’s period of stabilization has caused some hesitation for larger companies to invest in Rust but now that process is wrapping up, that story is changing. We’ll see.
🧪 Test story evolution. What we have works, but in the most MVP definition of the word “works”. We have a built-in to way slap a #[test] attribute on a function that can express boolean tests via assert! and equality tests via assert_eq! and have it resolved by cargo and run in its own compile time configuration. To be honest, those coming from other languages have higher bars for expectations when it comes to testing tools. I believe the stabilization of proc macros will help but 👉 “we need you” to help design and build those tools. We also “need you” to help remove the blockers for existing tools that fill gaps in areas like code coverage by removing the blockers for nightly only usage. My heart goes out to you, tarpaulin team! We also need these tools to work on multiple platforms where multiple means more than just linux.
👜 Quality of life enhancers is what I am rebranding IDE’s as so I can discard any previous notion I had with associating words like “clunky” with the potential of a more accessible developer experience. Vscode has been game changing for me in this market. Having come from an emacs based background for many years. Yes I feel productive and have walked up the hill and learned tricks that aren’t necessarily discoverable for a new developer on a team but I can reflect and observe that what’s more important is to make programming accessible for as many people as possible to grow the diversity of thought around the community. Rust’s initial investment on the rls vscode plugin was a good first step but there needs to be heavier commitment towards making the quality of life while developing Rust programs jump leaps and bounds over previous years every year. Invest in the experience and you will be remembered.
There are a number of other things that’d I’d like to see changed and improved but I’m a bit more humble these days thanks to the strong Rust working groups that have formed around topics of interest in Rust have proven dependable enough that I no longer have to worry. I also realized that the fewer things I wish for Christmas increase the statical chance that’ll I’ll get any one of them 🎄
