Despite the overwhelming success of the impl period, many of the features tackled are massive undertakings which could not possibly have been polished in such a short period of time. For this reason, I think a priority for 2018 shuold be the polishing and eventual stabilization of the new features which arose in 2017, before introducing any additional new features. The big ones on my radar at the moment are generic associated types, non-lexical lifetimes, specialization, const generics, arbitrary self types, and coroutines. These features may not be necessary for programming in Rust yet I have run into multiple cases where the best solution to a problem is to leverage one of them. They can save significant developer time, and in some cases they can replace macros, which is a win in my books because of how opaque macros can be.
These features are important to me because they expand Rust’s abstraction toolset. However, I’m a bit conflicted because it is difficult to understand the complete scope of what these features enable, particularly in combination. Often, when writing new or unfamiliar kinds of systems in Rust, I will go through a decent number of iterations before I come across what seems to be the correct solution. Rust pressures me towards the nicest solution, often because a required feature is impossible/impractical to add with the current design, the code becomes excessively verbose or because it would require
unsafe. Yes, it can be a hassle sometimes, but it feels great when you finally nail the design - and it is usually quite obvious once you have. Rust as it is today really pushes me towards that one true design which resonates with the language. Other languages may strive to have one true way to do things, but they generally acheive this through a well-constructed standard library and do not impose the same restrictions on user code. I’m not aware of any other language that constrains the layout of code yet enables sufficient abstraction in the way that Rust does.
My hope is that this beautiful aspect of Rust does not disappear with the introduction of an abundance of new abstractions. It’s hard enough as is to stumble across the correct design for a sufficiently complex problem, and I fear that increasing the size of this space will only make it easier to find a mostly correct abstraction, and harder to find the perfect abstraction. Of course, there is room for new features which do not interfere with this desire. I just urge caution, because we often find that advanced features can be used for cases completely unlike what they were originally intended for, such as with the Turing completeness of template metaprogramming in C++ (yes, I am aware Rust’s type system is also Turing complete, but it is much more awkward to abuse than in C++). Now don’t get me wrong, I love abusing template metaprogramming with a passion. But I usually come to regret it later.
Sometimes, nice code which took ages to write isn’t worth it. But this theme of clean code is prevalent all across the Rust language today. We are strongly encouraged by the syntax, the warnings, clippy, and the community to write concise code, safe code and performant code. Let’s continue in this direction and make 2018 a year of healthy abstraction.
P.S. A big thank you goes out to the core team, the contributors and the community. You are what makes Rust awesome. Keep it up!