You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 14, 2018. It is now read-only.
Rust has taken a decidedly lean approach to its standard library, preferring for much of the typical "batteries included" functionality to live externally in the crates.io ecosystem. While there are a lot of benefits to that approach, it's important that we do in fact provide the batteries somewhere: we need 1.0-level functionality for essential tasks. To pick just one example, the rand crate has suffered from a lack of vision and has effectively stalled before reaching 1.0 maturity, despite its central importance for a non-trivial part of the ecosystem.
There are two basic strategies we might take to close these gaps.
The first is to identify a broad set of "essential tasks" by, for example, finding the commonalities between large "batteries included" standard libraries, and focus community efforts on bolstering crates in these areas. With sustained and systematic effort, we can probably help push a number of these crates to 1.0 maturity this year.
A second strategy is to focus specifically on tasks that play to Rust's strengths. For example, Rust's potential for fearless concurrency across a range of paradigms is one of the most unique and exciting aspects of the language. But we aren't fully delivering on this potential, due to the immaturity of libraries in the space. The response to work in this space, like the recent futures library announcement, suggests that there is a lot of pent-up demand and excitement, and that this kind of work can open a lot of doors for Rust. So concurrency/asynchrony/parallelism is one segment of the ecosystem that likely deserves particular focus (and feeds into the high-scale server goal as well); there are likely others.
@brson@aturon I would love to contribute to or discuss the "Effort toward 1.0-level crates", some community members have helped me to put some thought into the "essential tasks" stream (through reddit, issues, comments), I get the feeling that if nothing else the experimental list we're developing here https://github.com/production-rs/bikeshed could be a good seed to enable the libs team to find crates the community want at 1.0 level.
I'm probably stumbling blindly into a stream that already has had lots of thought though, so please feel free to send me home with my toys - no hard feelings either way :-)
@stephanbuys Thanks so much for reaching out! That does indeed look like a valuable resource for seeding this effort.
The libs team is in the midst of planning on this topic. Would you be interested in joining one of our weekly meetings (on Mondays)? If so, shoot me an email at [email protected]
@stephanbuys So, @brson is putting together the overall initiative from the libs team side, and he's planning to gather a number of stakeholders -- including yourself -- for a special meeting on the topic. You should expect to hear more soon!
@aturon - just to follow up, too, the commercial outreach portion to get a better understanding of crates being used by production users was approved by the community team this morning.
Overview
Rust has taken a decidedly lean approach to its standard library, preferring for much of the typical "batteries included" functionality to live externally in the crates.io ecosystem. While there are a lot of benefits to that approach, it's important that we do in fact provide the batteries somewhere: we need 1.0-level functionality for essential tasks. To pick just one example, the
rand
crate has suffered from a lack of vision and has effectively stalled before reaching 1.0 maturity, despite its central importance for a non-trivial part of the ecosystem.There are two basic strategies we might take to close these gaps.
The first is to identify a broad set of "essential tasks" by, for example, finding the commonalities between large "batteries included" standard libraries, and focus community efforts on bolstering crates in these areas. With sustained and systematic effort, we can probably help push a number of these crates to 1.0 maturity this year.
A second strategy is to focus specifically on tasks that play to Rust's strengths. For example, Rust's potential for fearless concurrency across a range of paradigms is one of the most unique and exciting aspects of the language. But we aren't fully delivering on this potential, due to the immaturity of libraries in the space. The response to work in this space, like the recent futures library announcement, suggests that there is a lot of pent-up demand and excitement, and that this kind of work can open a lot of doors for Rust. So concurrency/asynchrony/parallelism is one segment of the ecosystem that likely deserves particular focus (and feeds into the high-scale server goal as well); there are likely others.
Projects
The text was updated successfully, but these errors were encountered: