I’ve used Rust a couple times at work for small tools, and written a couple of experiments in Rust. So before saying what I want out of Rust, I’d just like to say thanks to the wonderful community.

I liked the Rust 2019 progress, and I can put most of my wants for 2020 under two main labels.

Embrace

The 2019 roadmap was great. We got a good start, but it seems like most areas still need work. Let’s embrace what we did and polish it up. The bits I’m particularly interested in that are currently underway:

  • Macro hygiene for Rocket on stable
  • GAT for async traits
  • Const generics for better math libraries
  • Rust analyzer - IDE support (and eventually faster copmiler?)
  • Copmiler speed micro optimizations
  • Polonious - better lifetimes

Extend

There are two ways to extend Rust, and both seem to be suffering. I’d love to see improvements in the extensibility of Rust.

The first route is new features that go through the rfc -> implementation -> stabilitzation route. You could say that these features are the std of features - immortal and more-or-less unchanging once added.

I see two ways this process breaks down. When a feature is high profile, the RFC process becomes contentious and less effective. On the other hand, less popular features don’t get the feedback they need through nightly usage. Now perhaps these are signs of Rust’s maturity, or at least grow, but it does make getting important things, both high and low profile, out the door.

The alternative I’d like to focus on macros. They are userspace features, and allow for rapid iteration. They can be versioned. And the better they are, the more prototyping you can do of feature you really do want at the language level, without having to resort to modifying the compiler and using nightly.

And while they are great, they’ve been getting worse. Not in absolute terms, but in relative terms. Macros block incremental compilation. Macros don’t allow for auto-complete in them. (Proc) macros bring in lots of dependencies.

Those are problems worth fixing, and they have started receiving some attention, mostly in user space, not language space (Watt, I’m looking at you :hat_tip:).

Watt

Watt (proc macros distruted as wasm binaires), as I see it, brings a couple of key benefits:

  • Proc macros can be run in process safely. This is a benefit for the IDE story
  • Distributed proc macros don’t have to bring in quite so many dependencies
  • Proc macros are faster

I’d love to see some first class support here, eventually transitioning watt out of userland space, especially for security/auditing reasons.

IDE/Hinting Support

Right now, macros are very opaque. I’d love to somehow give them autocomplete support. My initial guess is that we’d need some sort of secondary, generative language for describing what the inputs of our proc macro looks like. But then using that could allow for better rust-analyzer usage inside of macros.

I see a couple of basic categories that would greatly benefit from this:

  • Custom derives - these shouldn’t have to mess up incremental compilation. Let’s find a way to communicate what traits for which types when a custom derive is added
  • Function level transformation - these are things where you want to be able to write ordinary rust, but the proc macro modifyings somethings and changes or wraps the return types
  • List functions - stuff like println are a good example of this. That one would be a little harder as you’d want to emit suggestions based on the first argument (the format string)

Type holes could be useful too, if a macro could define what it needed as a bare minimum to output code full of proper type holes. Or maybe it’s not quite type holes, but rather the ability to emit an error saying that a certain type needs to go here, that rust-analyzer of something else has tied back to a macro span, allowing for auto-complete suggestions.

Disclaimer: I’m biased about this. I hacked together rubber-duck, a crate for named-argument function calling, and I’d love to find a way to make it auto-completeable. If there was a way, I’d probably polish it up quite a bit and get it more production worthy. I feel that the lack of IDE support for this particular macro decreases its utility a lot.

Misc

I’d love better tooling around dependencies. It seems mostly like a userspace issue though that progress is being made on. The only exception might be cargo support for grouping together crates. Sort of meta-crates or something like that to allow for individual crates as units of compilation, while making groups of crates the unit of auditing.

Conclusion

That’s all! If I had to sum up, I’d say lets copy over the 2019 roadmap as well as bring macros up to speed with the other improvements Rust has seen.