[rust-dev] Today's Rust contribution ideas
matthieu.monrocq at gmail.com
Mon Jan 27 09:33:46 PST 2014
On Mon, Jan 27, 2014 at 3:39 AM, Brian Anderson <banderson at mozilla.com>wrote:
> 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.
You might be interested by a serie of articles by Joaquín M López Muñoz who
maintains the Boost.MultiIndex library. He did a relatively comprehensive
overview of the hash-maps implementation of Dirkumware (MSVC), libstdc++
and libc++ on top of Boost.MultiIndex, and a lot of benchmarks showing the
performance for insertion/removal/search in a variety of setup.
One of the last articles:
> # 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
> Rust-dev mailing list
> Rust-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev