Skip to content

Instantly share code, notes, and snippets.

@samsieber
Created October 4, 2020 05:34
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save samsieber/e976664ba333fd8a0b5f3b0ba167cb76 to your computer and use it in GitHub Desktop.
Save samsieber/e976664ba333fd8a0b5f3b0ba167cb76 to your computer and use it in GitHub Desktop.

Rust 2021: lowering barriers

First, thanks for a great year, and there's a lot of great stuff in the works too.

Compiler

There have been a couple of great calls for making the Compiler more approachable from the contribution POV. That's great, I endorse that 100%.

I'd also like to point out (as has been noted before) that nightly usage is down because you all have stabilized a lot of things. That's great but it makes stable less stable. I'm not confident in any solution. Part of me thinks it'd be great for people to be able to contribute results from private results to crater somehow.

Language contributions (macro edition)

I'd like to empower macros more. Right now they have a huge ergonomic hit during consumption - compile time and IDE support. Watt goes a long way to address those, but I wonder if we can do more.

One idea I've been kicking around are typed macros - they use some sort of declarative language that would expose the expected type information without actually having to run. It'd be quite the undertaking and just a thought (ie. I understand it might not be feasible).

The other idea is to let macros opt in to dependency tracking to help with incremental compilation (and compile avoidance)

All in all I think if we make macros even more friendly, there will be more experimentation with language features in macro form because more people will be willing to use them.

Ecosystem

I like the rust cookbook but I think a bigger version and promoting it more heavily would do wonders for newbies.

I also pine for a package namespace system that would let people curate packages into a facade without having just a single version (e.g. pass through the versions of what they proxy). This isn't possible but would facilate a de-facto, extended, community maintained std.

Speaking of std (this is an idea that needs to bake more), could we crate-ify the std so that we can finally making breaking changes to std. It seems doable, albeit with limited scope. E.g. you couldn't break traits between editions, but you could change defaults if the std being imported is actually a version specific wrapper of std.

Conclusion

Sorry that my thoughts are so terse - I wish I had found more time this month, but at the beginning I didn't feel like I had much to contribute, or a good way to organize what I had.

I feel like these points are uncommon enough that I'd like to out them out anyway.

Thanks for taking the time to read, and you contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment