Rust focus for 2020

rust2020

In response to Rust's call for blogs about Rust development in 2020, here's a few of my own thoughts:

1. Improve Error ergonomics

For the love of all that is good about Rust, Error is *still* the single biggest pain-point when dealing with Rust.
Things are drastically improved with some of the changes to the Error trait, but it's still really unclear what 
the best way to deal with Error types for Rust. The old failure or error-chain crates have been abandoned, yet they're
still widely used in libraries. It's just still too difficult and there's not standardized way for a library to
easily create Error types (even error derive crates don't really seem to get things right imo), or for apps to
handle a bunch of different types of them easily. I know I often just end up with a lot of functions using
`-> Result<_, Box<dyn Error>>` which just feels...like it's not the right practice? There are some newer
error derive and like the anyhow trait that seem to be heading in the right direction here, but this kind of things
*NEEDS* to be folded into std or the language itself.

? tries and the Error trait fixes were both major improvements to Rust ergonomics, but I still
feel that this is the biggest area with room for improvement in Rust. I want to be able to easily create new error types
and then handle them in callers in a way I know is conforming to best practices, while still being ergonomic,
rather than having to implement a bunch of different traits in complicated configurations just to make things work out.

I would be entirely for any kind of syntactic sugar or macros in the standard library to improve error creation and handling.
Imagine #[derive(Error)] in Rust std. Or imagine some kind of `error!(MyError, ForeignErrorType1, ForeignErrorType2)` that
automatically creates a an encapsulation of multiple foreign Error types in other crates you're using for your app so you can
easily consume those APIs in your own, and that this was in std lib. These are things that external traits have tried to provide,
but all seem to have fundamental flaws of some kind, and aren't very standardized.

2. Stabilize existing approved features

From further planned expansion of async/await, to const generics, GAT, specialization, etc., there's a lot of
really useful features already approved. I think Rust should continue to try to stabilize and release these
features. Over the past year of 2019 it felt like there was very little movement (from a user point of view) on some
of these beyond async. This includes important updates and fixes to cargo, especially some of the pain points
around some dependency and feature configurations, and to std and core libraries, such as alloc and the like.

3. Stabilize more ecosystem libraries

I still end up seeing a great deal of 0.* crates in my compiles, even for relatively basic tasks. While Rust 2018
did a great job of organizing the community into stabilizing some of the core crates, I feel there's a lot more
libraries that could use some organized stabilization treatment to get them to some 1.0 releases. And these aren't
obscure crates I'm talking about here. They are top downloaded crates such as rand, log, etc., and especially
crates that have been adopted under rust-lang. I'm hoping will see some stabilization and consolidation of
the async & concurrency libraries now that async has been coming out.

Along these lines, trying to fill out gaps in the ecosystem in the various areas of usage would be great. While
progress has been made on https://areweasyncyet.rs/ it would be nice to see progress--if not outright affirmative
answers!--in areas such as http://areweguiyet.com/ http://arewegameyet.com/ and especially http://arewewebyet.org/

This also includes creating some new policy on crates.io about abandoned crates and name squatting. There's more than
a few 0.0.1 error crates that haven't been touched in years, some sitting on possibly important crate names for the
Rust ecosystem. Some are just outright squatting on a name, such as https://crates.io/crates/any. While some of these
can be resolved by contacting authors and transferring ownership in that way, I think there's enough abandoned
crates that a policy should be put in place, especially given crates.io lack of namespacing (which is otherwise not
a big deal imo). At the very least some of these crates should be transferred to the rust teamownership (possibly
a rust-lang-abandoned owner or some such) to let the community decide how the crate name should be used.

4. Rust 2021 edition

Do we need one? Aside from possibly the Error complaints above, I don't see much needing edition changes to be implemented.
While I'm all for a regular cadence of edition releases, unless there's some approved RFCs that
would require a new edition rn, I'm not sure how much use we'd get out of a new edition at this time?
Some time should be given over the next for async and some of the other features that need to be stabilized to permeate the
ecosystem and let libraries really use them as-is before deciding on what changes might be needed in a new
edition, if any.

That said, Rust 2021 edition might be a great opportunity to push for big new features&improvements in cargo/xargo,
RLS/analysis, or other development tools, just as 2018 was. For example, having clippy support get into stable rust
was a really big win of 2018 imo, so perhaps getting more tool integration improvements such as that (such as support
for more generic non-clippy tool attributes and the like).