├── ISSUE_TEMPLATE └── README.md /ISSUE_TEMPLATE: -------------------------------------------------------------------------------- 1 | ## Point of contact 2 | 3 | ## Overview 4 | 5 | ## Status 6 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## Rust 2017 Roadmap 2 | 3 | As part of [RFC 1728](https://github.com/rust-lang/rfcs/pull/1728), each year 4 | the Rust community puts together a *roadmap* laying out a vision for 5 | improvements to Rust over the course of the year. The 2017 roadmap was decided 6 | in [RFC 1774](https://github.com/rust-lang/rfcs/pull/1774). 7 | 8 | The issues in this repository track the progress on our 2017 roadmap. 9 | 10 | **Only Rust subteam members should create new issues in this repo**. If you 11 | believe a project should be added within the tracker, please leave a comment on 12 | the appropriate "parent" issue, i.e. one of the issues linked below. And in 13 | general, feel free to use comments to ask questions, pitch ideas, or mention 14 | updates that need to be made! 15 | 16 | There are issues for each of the vision statements: 17 | 18 | * [Rust should have a lower learning curve](https://github.com/aturon/rust-roadmap/issues/3) 19 | * [Rust should have a pleasant edit-compile-debug cycle](https://github.com/aturon/rust-roadmap/issues/1) 20 | * [Rust should provide a solid, but basic IDE experience](https://github.com/aturon/rust-roadmap/issues/2) 21 | * [Rust should provide easy access to high quality crates](https://github.com/aturon/rust-roadmap/issues/9) 22 | * [Rust should be well-equipped for writing robust, high-scale servers](https://github.com/aturon/rust-roadmap/issues/10) 23 | * [Rust should have 1.0-level crates for essential tasks](https://github.com/aturon/rust-roadmap/issues/11) 24 | * [Rust should integrate easily into large build systems](https://github.com/aturon/rust-roadmap/issues/12) 25 | * [Rust's community should provide mentoring at all levels](https://github.com/aturon/rust-roadmap/issues/13) 26 | 27 | and for our two areas of exploration: 28 | 29 | * [Integration with other languages, running the gamut from C to JavaScript](https://github.com/aturon/rust-roadmap/issues/14) 30 | * [Usage in resource-constrained environments](https://github.com/aturon/rust-roadmap/issues/15) 31 | 32 | Each of the above issues link to a number of other *project* issues, which give 33 | points of contact and other information about the status of specific projects 34 | working to achieve one of our goals. You can see the list of all projects [here](https://github.com/aturon/rust-roadmap/issues?q=is%3Aissue+is%3Aopen+label%3AProject). 35 | 36 | Finally, each subteam has a dedicated roadmap issue, spelling out areas of 37 | activity beyond those included in the formal Rust roadmap: 38 | 39 | - [Lang team](https://github.com/aturon/rust-roadmap/issues/18) 40 | - [Libs team](https://github.com/aturon/rust-roadmap/issues/19) 41 | - [Compiler team](https://github.com/aturon/rust-roadmap/issues/21) 42 | - [Community team](https://github.com/aturon/rust-roadmap/issues/22) 43 | - [Docs team](https://github.com/aturon/rust-roadmap/issues/20) 44 | - [Tools team](https://github.com/aturon/rust-roadmap/issues/23) 45 | 46 | ## Roadmap rationale 47 | 48 | The full rationale for the roadmap is spelled out in 49 | [RFC 1774](https://github.com/rust-lang/rfcs/pull/1774), but we'll recap the 50 | high-level framing here. 51 | 52 | There's no end of possible improvements to Rust—so what do we use to guide our 53 | thinking? 54 | 55 | The core team has tended to view our strategy not in terms of particular features or 56 | aesthetic goals, but instead in terms of **making Rust successful while staying 57 | true to its core values**. This basic sentiment underlies much of the proposed 58 | roadmap, so let's unpack it a bit. 59 | 60 | ### Making Rust successful 61 | 62 | #### The measure of success 63 | 64 | What does it mean for Rust to be successful? There are a lot of good answers to 65 | this question, a lot of different things that draw people to use or contribute 66 | to Rust. But regardless of our *personal* values, there's at least one clear 67 | measure for Rust's broad success: **people should be using Rust in 68 | production and reaping clear benefits from doing so**. 69 | 70 | - Production use matters for the obvious reason: it grows the set of 71 | stakeholders with potential to invest in the language and ecosystem. To 72 | deliver on that potential, Rust needs to be part of the backbone of some major 73 | products. 74 | 75 | - Production use measures our *design* success; it's the ultimate reality 76 | check. Rust takes a unique stance on a number of tradeoffs, which we believe 77 | to position it well for writing fast and reliable software. The real test of 78 | those beliefs is people using Rust to build large, production systems, on 79 | which they're betting time and money. 80 | 81 | - The *kind* of production use matters. For Rust to truly be a success, there 82 | should be clear-cut reasons people are employing it rather than another 83 | language. Rust needs to provide crisp, standout benefits to the organizations 84 | using it. 85 | 86 | The idea here is *not* about "taking over the world" with Rust; it's not about 87 | market share for the sake of market share. But if Rust is truly delivering a 88 | valuable new way of programming, we should be seeing that benefit in "the real 89 | world", in production uses that are significant enough to help sustain Rust's 90 | development. 91 | 92 | That's not to say we should expect to see this usage *immediately*; there's a 93 | long pipeline for technology adoption, so the effects of our work can take a 94 | while to appear. The framing here is about our long-term aims. We should be 95 | making investments in Rust today that will position it well for this kind of 96 | success in the future. 97 | 98 | #### The obstacles to success 99 | 100 | At this point, we have a fair amount of data about how Rust is reaching its 101 | audience, through the [2016 survey], informal conversations, and explicit 102 | outreach to (pre-)production shops (writeup coming soon). The data from the 103 | survey is generally corroborated by these other venues, so let's focus on that. 104 | 105 | [2016 survey]: https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2016.html 106 | 107 | We asked both current and potential users what most stands in the way of their 108 | using Rust, and got some pretty clear answers: 109 | 110 | - 1 in 4: learning curve 111 | - 1 in 7: lack of libraries 112 | - 1 in 9: general “maturity” concerns 113 | - 1 in 19: lack of IDEs (1 in 4 non-users) 114 | - 1 in 20: compiler performance 115 | 116 | None of these obstacles is directly about the core language or `std`; people are 117 | generally happy with what the language offers today. Instead, the connecting 118 | theme is *productivity*—how quickly can I start writing real code? bring up a 119 | team? prototype and iterate? debug my code? And so on. 120 | 121 | In other words, our primary challenge isn't making Rust "better" in the 122 | abstract; it's making people *productive* with Rust. The need is most pronounced 123 | in the early stages of Rust learning, where we risk losing a large pool of 124 | interested people if we can't get them over the hump. Evidence from the survey 125 | and elsewhere suggests that once people do get over the initial learning curve, 126 | they tend to stick around. 127 | 128 | So how do we pull it off? 129 | 130 | #### Core values 131 | 132 | Part of what makes Rust so exciting is that it attempts to eliminate some 133 | seemingly fundamental tradeoffs. The central such tradeoff is between safety 134 | and speed. Rust strives for 135 | 136 | - uncompromising reliability 137 | - uncompromising performance 138 | 139 | and delivers on this goal largely thanks to its fundamental concept of 140 | ownership. 141 | 142 | But there's a problem: at first glance, "productivity" and "learnability" may 143 | seem at odds with Rust's core goals. It's common to hear the refrain that 144 | "fighting with the borrow checker" is a rite of passage for Rustaceans. Or that 145 | removing papercuts would mean glossing over safety holes or performance cliffs. 146 | 147 | To be sure, there are tradeoffs here. But as above, if there's one thing the 148 | Rust community knows how to do, it's bending the curve around tradeoffs—memory 149 | safety without garbage collection, concurrency without data races, and all the 150 | rest. We have many examples in the language where we've managed to make a 151 | feature pleasant to use, while also providing maximum performance and 152 | safety—closures are a particularly good example, but there are 153 | [others](https://internals.rust-lang.org/t/roadmap-2017-productivity-learning-curve-and-expressiveness/4097). 154 | 155 | And of course, beyond the core language, "productivity" also depends a lot on 156 | tooling and the ecosystem. Cargo is one example where Rust's tooling provides a 157 | huge productivity boost, and we've been working hard on other aspects of 158 | tooling, like the 159 | [compiler's error messages](https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html), 160 | that likewise have a big impact on productivity. There's so much more we can be 161 | doing in this space. 162 | 163 | In short, **productivity should be a core value of Rust**. By the end of 2017, 164 | let's try to earn the slogan: 165 | 166 | - Rust: fast, reliable, productive—pick three. 167 | --------------------------------------------------------------------------------