My Wishes for Rust 2020
2019 was another huge year for rust, but instead of implementing the shiny new thing, it's been a focus on refining existing ideas.
Having being using rust professionally for over 3 years, I feel I will very soon be regailing new rust developers of the times before NLL & async, where we had to play lexicon-fu to get things like caches to work in a reasonable fashion, or using super dooper combinator chains and wrestling with futures types (
So I'd like to make clear my acknowledgement that I am happy with the direction that the rust language is heading in, and these requests are really nice to haves.
The Future of Futures
The async/await is on track to be stabilised next month, which means it's not a goal for 2020, but we have to look back to the futures-rs! There is a whole ecosystem that now needs to play catchup and I hope that it does within the year 2020.
I also really hope they start using the logo a bit more!
I would like to see tokio version
1.0 in 2020. I would also like the core of tokio to be trimmed down immensely for inclusion as a dependency. Just a small wish I know!
I understand the reluctance to brand it as
1.0 but there is already a lot of churn from the move from
tokio-core last year. This would also signal to users that it is mostly stabilised, since async/await is dropping soon. I haven't been following development closely to know if there are any further blockers beyond this though.
Alternatives to tokio
I'd also like to see more than one library for async reach wide use. I'd like to be able to mix and match executors with library code, and choose an implementation. The promise of async/await should allow for this in theory, but we'll have to see what it's like in practice.
This will both add a bit of healthy competition to the ecosystem but will also prevent future design decisions from library bias.
I know that async-std is a great contender here and I hope that one day I could use this as a (mostly) drop in replacement for running my futures.
Some more care needs to be put into the non-async world. There was a great thread about an alternative to reqwest which doesn't require the entire async stack to run.
I would also like to see the blending of async and sync code made easier. Sometimes you want to use a db pool such as diesel, and currently that is a very messy thing to do.
It would be great if that bridge was seamless and doesn't shoot you in the foot (i.e, make it a compile time guarantee to ensure no blocking code in async).
Chat and Community Channels
I really enjoyed the IRC chat room, but as Mozilla is decommissioning it, it feels like there is now a massive empty hole where a good resource use to be.
This isn't really something that the rust team themselves can do anything about, but I also don't think fragmenting team discussions across a variety of chat platforms sets a good precedent for the greater rust community.
I don't have any direct qualms about using discord (which is currently recommended on the community page) but it would be preferable if whatever was chosen was both accessible and open. I'd love it to be matrix, but riot is a bit of a clunky client, and there isn't really a better alternative client. Discord has much more polish.
Reflecting on Last Year's Wishes
My last blog I had 3 main areas of improvement that I would like to have seen a focus on.
Compiler Times, IDE Support and RLS
It seems the IDE story is a lot better, but still a long way off. Who knew it could be so hard! IntelliJ has made strides this year in making their IDE much better. Still though, every few months I load up some of my bigger rust projects, only to have some weirdness show up.
I feel like this is very much an aspirational goal though, IDEs for all languages continue and improve to get better with time. It's not ever going to be the ideal of an IDE, but it's trending towards it.
The Async/Await story definitely improved with the imminent release (as of this blog) of
async syntax landing on stable.
While there was a substantial amount of dogfooding around the syntax, I feel that the language team has settled on an appropriate solution. It looks a bit weird at first, but the promise of having
match or others use the same syntax style is intruiging.
This is still an area of concern, but has been addressed mostly in some of the frameworks I've seen. I feel like this won't be fixed until all the ecosystem has stabilised around new language features and we land a few more
It's going to be a hassle redoing examples with async keywords!
I am happy with the way things have progressed throughout 2019 and I feel that 2020 is going to be a massively exciting time for rust.
I don't feel there is a need for another epoch just yet, considering we're still working through the current one.
Let's work towards polishing the async ecosystem for this year, and hopefully we'll have a very compelling story for everyone else to get involved.