I am a relatively new in Rust, but I believe I have gathered enough experience the last few months to enjoy its strengths and discover some of its current shortcomings. Being relatively new at Rust, I am also of this generation that started immediately with Edition 2018. I switched to nightly very early on, and recently have been porting some code back to stable (1.31.x). I am overall very satisfied with Rust, but sometimes I come across something that doesn't work as I hoped. Every time that happens, I discover there is work-in-progress solving these issues, including, most of the time, a merged RFC, a nightly implementation behind feature gates or at least some blogs from core developers. Many time, the work I come across is from many years back.
I have read several #Rust2019 and I want to use this opportunity to agree with those that suggest to finish current core stuff.
Rust core developers can only do so much. Yes, it would be nice to spend more energy kickstarting the Web ecosystem, whether it is on server-side or in the Web platform using WebAssembly -- and making most of the stuff compatible with both. Improved tooling (mostly on the IDE) and faster compilation would be awesome as well. However, these are issues the broader community can help with, and in the spirit of collaboration improve the current state of affairs (e.g, in Web and tooling).
Core features are harder for outsiders to help with. In 2019, I would like the focus to be on completing core features and accepted RFCs.
Here are a bunch of core features I have needed or have bitten me:
I have been using nightly because async/await is a must have. This feature is great and has been working perfectly, but it is not done yet. It can be stabilized in its current form, but to enjoy the full experience of async/await I believe traits should be able to define async functions.
There are different reasons one would use async/await. Obviously, it makes the code much more readable, and helps people use asynchronous programming because it makes it look like regular blocking code. But in Rust, async/await also provides a better performance by allowing references across await boundaries and avoiding boxing/allocation. Having async functions in traits means this goodness can be mixed with higher-level abstractions.
async functions are planned in traits, but they are, as far as I know, blocked by the lack of GATs (Generic Associated Types). Then, I believe GATs should be a focus. I hear work on GATs is underway, through Chalk that will support them. Then I'd suggest even more focus on Chalk and integrating it into rustc :). As an outsider, I often have had the feeling that the Rust team is spread thin across too many subjects. This year should make sure GATs and complete support of async/await (including in traits) get stabilized (or close) .
Traits in Rust are very powerful, that's why it is so frustrating when they don't do something we feel they should.
Traits have come short a few times for me, while designing libraries rather than a binary (because then you can cover your types easily). I believe one category of problem would be solved by specialization and the other by Higher-Kinds.
- One example is when I had a generic implementation that worked for all cases save a few that needed particular handling or benefited from a better code path -- I had to rely on runtime type detection (using
std::any::Any) to handle that case that could have been handled by the compiler. This is frustrating because Rust's precision gives programmers a thirst for optimal call and static dispatch. Also, specialization is like pattern matching for types, and something we naturally come to expect after using Rust for a while. - Another example of an issue happened when I was providing a blanket implementation that conflicted with a more specific implementation. The blanket implementation was somewhat unrelated, but rustc could not tell because the difference was within the generics of the trait bounds themselves. I am not sure if specialization as it is suggested would have fixed that code, but it definitely would have been better written with Higher-Kinds.
Specialization's RFC has been merged (RFC1210) but the implementation is still in a very early stage. In the case of Higher-Kinds, there have been suggestions that GATs may provide ways to emulate them (even though I am wary of the boilerplate). Once again, GATs for 2019! :)
Having these features in stable would, it seems, also finally land TryFrom and TryInto in stable. These traits would be most welcome.
I think I have read core Rust developers describe these features as long-term features. I really think they should come as soon as possible. You see, I spent the most part of the last decade programming in Java, not in Haskell, yet I have found traits to be among the defining features in Rust, I have found them easy to use and powerful. Specialization and Higher-Kinds are not advanced features -- I think they would feel natural ; I'd rather say the lack of them feels unnatural. I look forwards to improving my APIs and code thanks to them; thinking they will land in a future too distant worries me as they feel like they should be a fundamental part of the trait system.
I believe Rust can grow helping community members collaborate through Working Groups and events. There are already many in place. Everything seems smooth.
Rust has come a long way since 2015. As more people learn of the language or feel it is ready for wider adoption and production, there will be many more contributions, crates, and the community will expand. The core teams should remain focused on core development, because it benefits us all, and delegate as much as possible to help channel the incoming energy.
Working Groups and a better "map" of the ecosystem and crates would help people avoid redundant work and capture the right abstractions to build different ecosystems on.