[rust-dev] Today's Rust contribution ideas

People interested in Rust are often looking for ways to have a greater impact on its development, and while the issue tracker lists lots of stuff that one *could* work on, it's not always clear what one *should* work on. There is consistently an overwhelming number of very important tasks to do which nobody is tackling, so this is an effort to update folks on what high-impact, yet accessible, contribution opportunities are available. These are of varying difficulty, but progress on any of them is worthy of *extreme kudos*. # Break up libextra (#8784) Getting our library ecosystem in shape in critical for Rust 1.0. We want Rust to be a "batteries included" language, distributed with many crates for common uses, but the way our libraries are organized - everything divided between std and extra - has long been very unsatisfactory. libextra needs to be split up into a number of subject-specific crates, setting the precedent for future expansion of the standard libraries, and with the impending merging of #11787 the floodgates can be opened. This is simply a matter of identifing which modules in extra logically belong in their own libraries, extracting them to a directory in src/, and adding a minimal amount of boilerplate to the makefiles. Multiple people can work on this, coordinating on the issue tracker. # Improve the official cheatsheet We have the beginnings of a 'cheatsheet', documenting various common patterns in Rust code (http://static.rust-lang.org/doc/master/complement-cheatsheet.html), but there is so much more that could be here. This style of documentation is hugely useful for newcomers. There are a few ways to approach this: simply review the current document, editing and augmenting the existing examples; think of the questions you had about Rust when you started and add them; solicit questions (and answers!) from the broader community and them; finally, organize a doc sprint with several people to make some quick improvements over a few hours. # Implement the `Share` kind (#11781) Future concurrency code is going to need to reason about types that can be shared across threads. The canonical example is fork/join concurrency using a shared closure, where the closure environment is bounded by `Share`. We have the `Freeze` kind which covers a limited version of this use case, but it's not sufficient, and may end up completely supplanted by `Share`. This is quite important to have sorted out for 1.0 but the design is not done yet. Work with other developers to figure out the design, then once that's done the implementation - while involving a fair bit of compiler hacking and library modifications - should be relatively easy. # Remove `do` (#10815) Consensus is that the `do` keyword is no longer pulling its weight. Remove all uses of it, then remove support from the compiler. This is a 1.0 issue. # Experiment with faster hash maps (#11783) Rust's HashMap uses a cryptographically secure hash, and at least partly as a result of that it is quite slow. HashMap continues to show up very, very high in performance profiles of a variety of code. It's not clear what the solution to this is, but it is clear that - at least sometimes - we need a much faster hash map solution. Figure out how to create faster hash maps in Rust, potentially sacrificing some amount of DOS-resistance by using weaker hash functions. This is fairly open-ended and researchy, but a solution to this could have a big impact on the performance of rustc and other projects. # Replace 'extern mod' with 'extern crate' (#9880) Using 'extern mod' as the syntax for linking to another crate has long been a bit cringeworthy. The consensus here is to simply rename it to `extern crate`. This is a fairly easy change that involves adding `crate` as a keyword, modifying the parser to parse the new syntax, then changing all uses, either after a snapshot or using conditional compilation. This is a 1.0 issue. # Introduce a design FAQ to the official docs (#4047) There are many questions about languages' design asked repeatedly, so they tend to have documents simply explaining the rationale for various decisions. Particularly as we approach 1.0 we'll want a place to point newcomers to when these questions are asked. The issue on the bug tracker already contains quite a lot of questions, and some answers as well. Add a new Markdown file to the doc/ folder and the documentation index, and add as many of the answers as you can. Consider recruiting others in #rust to help.