RFC: Rust 2018 Roadmap #2314
RFC: Rust 2018 Roadmap #2314
Conversation
aturon
added
the
T-core
text/0000-roadmap-2018.md
Outdated
|
|
||
|
|
||
| - **SIMD**. The core SIMD intrinsics are nearing readiness for stabilization, and with luck we may be able to stabilize some vendor-agnostics primitives as well. | ||
| - **Custom allocators**. TODO |
There was a problem hiding this comment.
Was this to be discussed during RFC or was it intended to be fleshed out before hand and discussed?
|
I have no complaints with what's laid out here personally. Let's make 2018 a boring year and ship some real nice features! :D |
text/0000-roadmap-2018.md
Outdated
|
|
||
|
|
||
| - **Non-lexical lifetimes**. Currently in “alpha” state on nightly, with work ongoing. | ||
| - `**impl Trait**`. Nearing readiness for stabilization FCP. |
There was a problem hiding this comment.
Very minor nit, but this is misformatted; I think for the markdown to render correctly, the backticks should go inside the asterisks:
**`impl Trait`**
rather than
`**impl Trait**`
|
I'm surprised and excited to hear that both generators and macros 2.0 are expected to be stabilized this year. This is an excellent road map, and I'm looking forward to seeing the end result! |
text/0000-roadmap-2018.md
Outdated
| > [Mentorship does a lot to help underrepresented groups of people.](https://medium.com/@blackdjikstra/rust-in-2018-d6c0be87cba8) (@blackdjikstra) | ||
|
|
||
|
|
||
| > [“What can](https://willmurphyscode.net/2018/01/18/how-can-i-help-stabilize-things/) [I](https://willmurphyscode.net/2018/01/18/how-can-i-help-stabilize-things/)[, or other people not one the core team, do to help stabilize Rust?”](https://willmurphyscode.net/2018/01/18/how-can-i-help-stabilize-things/) (willmurphyscode) |
|
All stated goals are actually great targets to achieve for better outreach and adoption of Rust. However, IMHO, they're still quite high-level. For example "Web Services". There are so many things to do there like from complete (tokio based?) async server/client libs to database connectors to rotating file loggers and what not. Would it be a good idea to have them as fine-grained and deliverable 2018 targets? |
text/0000-roadmap-2018.md
Outdated
| continued mentoring: | ||
|
|
||
|
|
||
| > [I’d like to see a stronger focus [on] mentoring.](https://manishearth.github.io/blog/2018/01/10/rust-in-2018/) (@manishearth) |
There was a problem hiding this comment.
note: the [on] is no longer necessary, i fixed the typo in my post and it now just says "on"
|
@nimtiazm
Absolutely! There are a couple ways that could happen. We could talk more up front, on this thread, to try to flesh some of these pieces out. Alternatively -- and this is what I was expecting -- we can agree on the broad direction, and then leave it to the working groups to start making things more concrete and consulting with the community as things develop. |
text/0000-roadmap-2018.md
Outdated
|
|
||
| > [Aiming for a major product release gives us an opportunity, as a community, to come together and do something](http://aturon.github.io/blog/2018/01/09/rust-2018/) [big](http://aturon.github.io/blog/2018/01/09/rust-2018/) [that goes well beyond the usual six week cycle.](http://aturon.github.io/blog/2018/01/09/rust-2018/) | ||
| > | ||
| > [Releasing “Rust 2018” gives us a chance to say to the world that “Rust has taken a major step since 1.0; it’s time to take another look”.](http://aturon.github.io/blog/2018/01/09/rust-2018/) (@aturon) |
There was a problem hiding this comment.
Why this quote is broken up into 4 identical links 😄
text/0000-roadmap-2018.md
Outdated
| #### Language | ||
|
|
||
|
|
||
| > [Rust 2018: Consolidation (](https://deterministic.space/rust-2018.html)@killercup) |
There was a problem hiding this comment.
The ( should be outside of the link
text/0000-roadmap-2018.md
Outdated
|
|
||
| The most prominent language work in the pipeline stems from [2017’s ergonomics initiative](https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html). Almost all of the accepted RFCs from the initiative are available on nightly, but polish, testing, and consensus work will take time: | ||
|
|
||
| [](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/) |
text/0000-roadmap-2018.md
Outdated
| The most prominent language work in the pipeline stems from [2017’s ergonomics initiative](https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html). Almost all of the accepted RFCs from the initiative are available on nightly, but polish, testing, and consensus work will take time: | ||
|
|
||
| [](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/) | ||
| > [I’d like to reach a final decision to ship or drop all of the ergonomics RFCs that were accepted. I hope to see this completed over the next several mont](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/)[h](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/)[s . . . I hope we can have a clearer (and more spaced out) schedule for this so that their FCPs are staggered.](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/) (@withoutboats) |
text/0000-roadmap-2018.md
Outdated
| #### Libraries | ||
|
|
||
|
|
||
| > [It is often stated that rust’s ecosystem is immature. While this is somewhat true, the real issue is in](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [finding](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [and](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [using](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [the pieces you need.](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) (@vitiral) |
text/0000-roadmap-2018.md
Outdated
| > [We think it’s time to trumpet from the mountaintops what the Rust community has known for a while: Rust is production ready.](http://integer32.com/2018/01/05/more-rust-in-2018.html) (Integer 32) | ||
|
|
||
|
|
||
| > [We should have a polished web site that works for both engineers](http://aturon.github.io/blog/2018/01/09/rust-2018/) [and](http://aturon.github.io/blog/2018/01/09/rust-2018/) [CTOs, offering white papers and directing companies to sources of training, consulting, and support.](http://aturon.github.io/blog/2018/01/09/rust-2018/) (@aturon) |
text/0000-roadmap-2018.md
Outdated
| > [I believe that WebAssembly is about to take off in a big way.](https://dirkjan.ochtman.nl/writing/2018/01/14/rust-in-2018.html) (@djc) | ||
|
|
||
|
|
||
| > [We're poised to be](https://mgattozzi.com/rust-wasm) [THE](https://mgattozzi.com/rust-wasm) [language of choice for wasm.](https://mgattozzi.com/rust-wasm) (@mgattozzi) |
text/0000-roadmap-2018.md
Outdated
| ### CLI apps | ||
|
|
||
|
|
||
| > [Rust is a fantastic language for writing a Command Line Application (CLI). For the ergonomics of hacking, it has one of the best argument parsers ever, has seriously the best serialization library ever and it compiles to almost any target and goes](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [fast](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [when it runs.](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) (@vitiral) |
text/0000-roadmap-2018.md
Outdated
| > [Rust should actively be seeking out diversity.](https://medium.com/@softprops/rust2018-75393b4a086f) (@softprops) | ||
|
|
||
|
|
||
| > [While we talk about “the Rust community”, the reality is that there are](http://aturon.github.io/blog/2018/01/09/rust-2018/) [many](http://aturon.github.io/blog/2018/01/09/rust-2018/) [Rust communities, separated by geography and by language. We need to do much more to connect these communities.](http://aturon.github.io/blog/2018/01/09/rust-2018/)(@aturon) |
text/0000-roadmap-2018.md
Outdated
| ### Embedded “bare metal” devices | ||
|
|
||
|
|
||
| > [In 2018, I simply wish [the embedded community] could switch to beta or even stable!](https://medium.com/pollenrobotics/rust-for-robotics-and-embedded-systems-in-2018-96e9be8464) (Pierre Rouanet) |
There was a problem hiding this comment.
[the embedded community] should probably be *the embedded community*
It’s very encouraging to see be a focus, but that second sentence is both vague and weirdly precise. How large is large? :) |
|
You don't mention games, or game development, or anything of the sort. The word "game" appears once, and not in the context of actually writing video games. This is a shame. Let's take a moment to consider the fact that C++, despite being basically cancer for the soul, dominates the video game space. Because so much new talent wants to get into programming to program video games, they learn C++ first. Or maybe seconds, as their "get serious about programming language". I say we should cut that off! We should be the language that you go to when you want to get into the latest new stuff with game development. We're not even close at the moment, but I think we're going to get there sooner or later. We should make it sooner if we can. And this isn't too far off from the already-stated goals. Games are basically like an Embedded program that has a little more wiggle room. SIMD is key of course. A WebAsm story would let us make the case for being the next cool way to make games run in a browser. All we have to do, compared to what's already written, is to keep in mind "how would this let us write a video game?" as we're picking specific lower-level goals to satisfy the high level goals. Something like "We want to make WebAsm work well from start to finish, and our driving mini-project for the Rust+WebAsm tutorial will be a WebGL demo that can animate a spinning cube and has user keyboard/mouse input". |
I'll be impressed if incremental compilation manages to be faster at all than a clean build of winapi. Also is there any point in me complaining about the lack of attention being paid to Windows in this roadmap? Not to be constantly pessimistic about it but I'm constantly pessimistic about it. |
|
On a higher level: it looks like 2018 will be a great year for Rust, I’m excited! 😄 |
I hope @aturon meant rustc/servo kind of large. |
|
This seems like a great roadmap! It should be another good year :D One thing I'm curious about though, is the inclusion of CLI applications as a target domain. I agree that Rust and CLI is a great match, and there's already lots of good stuff happening there. But I'm not sure what the difference it will make for the core teams to consider CLI in its work this year; will it do anything the community isn't already accomplishing on its own? Because it seems to me that CLI applications are doing very well already, which means we might be better off putting the core teams' effort elsewhere. Or am I missing anything? |
text/0000-roadmap-2018.md
Outdated
|
|
||
| > [Rust is a fantastic language for writing a Command Line Application (CLI). For the ergonomics of hacking, it has one of the best argument parsers ever, has seriously the best serialization library ever and it compiles to almost any target and goes fast when it runs.](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) (@vitiral) | ||
|
|
||
| Rust has also seem some production update in the CLI space, for which it is very well-suited. This is a space where Rust’s portability, reliability, and ability to produce static binaries make it extremely attractive. We also have a number of excellent libraries already. This year, we will improve this ecosystem and pull it together into a polished, coherent package for people checking out Rust. Read [@vitiral’s post](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) and [@killercup’s crate](https://github.com/killercup/quicli) for some inspiration! |
There was a problem hiding this comment.
Rust has already seem some production update...
I think this sentence is missing words?
|
I look forward to seeing improvements to embedded particularly. A C/C++ alternative I would be free to work with more easily is good news. |
|
Some thoughts of mine: 1. generic associated typesI would love it if generic associated types (GATs) were scheduled for stabilization in 2018.. I believe it is a massive enabler and probably the biggest gain in language expressiveness for a long while. While GATs are not in nightly yet, I believe we should still focus on it and try to squeeze it into a stable release in 2018. I think this will also be important for the ability to get some crates into version 1.0. 2. a focus on writing desktop applicationsRust is among other things a systems programming language. As such, it is in particular useful for writing low latency and responsive desktop applications such as Firefox. Taking the gains made from the Servo project and Project Quantum, I'd love for the ecosystem to feature a platform for writing performance, cross-platform, and polished applications such as Slack, Spotify, VSCode, etc. In short, a community effort behind an Electron-like framework would be neat. This could be based on 3. a focus on testing frameworksRust has some good testing frameworks such as |
|
(Kind of an in-the-weeds question for a roadmap thread, but: I remember one of the ideas motivating GATs (as opposed to other potential features related to higher kinds) was that the compiler basically already has to support them under the hood due to generic methods, so their implementation would be straightforward. Apparently this hasn't turned out to be the case...?) |
|
I think it is sad that code coverage is not mentioned as an important missing piece of the tooling. The Rust ecosystem is built on top of safe abstraction around unsafe code and the safety of the ecosystem depends on the safety of these abstractions. Yet the only tools we currently have to verify these abstractions are based on run-time instrumentation (valgrind, asan, tsan, miri, etc.), but these tools can't verify anything if the tests don't exercise the code. So, in my head at least, accurate and easy to obtain code coverage information is a critical piece of the tooling in our ecosystem, yet Rust's code coverage story is pretty bad:
crates.io is full of little green badges stating "build: passing" but to me at least, all those badges are completely meaningless because "if I don't write any tests, all tests always pass" and most projects don't have adjacent badges stating how much of their code is actually covered by the tests. Does anybody have hard numbers about the code covered by tests in the standard library, rustc, crossbeam, rayon, servo, ...? Is this information generated and reviewed periodically, e.g., on a pull-request basis? I just tried to find this information for these projects and I can't find anything. Am I the only one that finds this worrying? |
More straightforward than higher kinded type parameters doesn't mean easy. I don't know the compiler internals well, but I think a rough approximation is that the way of resolving associated types and the way of resolving methods have been distinct and need to be brought together. This is a part of the chalk inspired refactoring - chalk has supported GATs since day 1. |
|
@withoutboats AFAIK resolution doesn't actually need to change - all you need is the definition site in the impl, regardless of type parameters being present. There's probably subtler things though. |
|
This sounds like an awesome roadmap. I want to ask a question here. Some days ago I proposed to have a "crates team" via a blog article. This was discussed both on users.rust-lang and reddit and there were some nice comments on both. Would that be an idea to lay out in the Roadmap (at least the overall incentive)? If yes, the section On a sidenote, I would love to contribute into this direction. I have to note, though, that I also want such a team for my own advantage, because I will be off the grid from May 2018 until early 2019 if everything works out - and that's why I think a lot about this idea. |
Hah yeah, I think this needs some iteration. The idea is that rather than just looking for XX% improvements in compile time, we should be focusing on the absolute time needed on a variety of project sizes. @nikomatsakis and @michaelwoerister should be able to help polish this language.
That's correct; it's not one of the proposed domains to track this year. The ones that are proposed are ones which (1) represent significant near-term market opportunities for Rust and (2) already have significant momentum. This is based in part on the extensive survey information about domains of use. Note also the tie-in with the general theme of shipping: the proposed domains are all ones in which we believe we can ship a meaningful end-to-end story in 2018. There are several domains that didn't make the cut this year based on those factors:
What would you hope to see?
Note that the proposal doesn't mean that the core team focuses on these domains directly. On the contrary, the idea is to spin up dedicated working groups for each of these, made up of people already participating in these subcommunities, with a goal of consolidating and shipping a coherent product story in each domain. IOW, I largely agree with what you're saying, and the goal of the roadmap is to formalize that community work a bit more and add some key deliverables related to the website and Rust 2018.
It's quite possible this will happen! But given the amount of work needed to push the other, existing features to stability for the epoch release, it's just not clear that we'll reach that point in time.
See my response to @Lokathor above re: additional domains.
I agree, we should consider bumping up the level of commitment here. Maybe @nrc can say a bit about how things are shaping up within the Dev Tools team on this topic?
Thanks for raising this! To continue harping on a theme: the roadmap is largely about shipping the work we've already been doing, rather than building major new pieces. Do we think we can take on this additional work without threatening the success of the other areas mentioned? |
Yes! Right now the roadmap is pretty vague about how we want to approach the broader library ecosystem, and it'd be great to flesh that out a bit. I've also been hoping to talk with @KodrAus and @vitiral about this. I will figure out some venue to bring these conversations together, work out a rough plan, and then we can update the roadmap accordingly. |
I'm making the subjective value judgement here that GAT is more important than those features (perhaps save for If we are to compare things, generators haven't even gone through a normal RFC yet (only e-RFC) while macros 2.0 went through a very short and under-specified one while declaring that more RFCs were to come. PS: I hope we can stabilize everything important in 2018 including generators and macros 2.0. I don't want it thought that I think those features are unimportant.
That's great and I hope we will! I've been involved in the discussions wrt. the cargo integration a bit, but my focus is mostly on the side of things that are the responsibility of T-Libs, and I think that our focus should mainly be on the libs side of things here. |
I missed this before, but yes! There's an ongoing internals thread about this. More generally, the plan is to set up a dedicated compiler performance working group, led by @michaelwoerister. |
|
I see this RFC has entered FCP but still doesn't mention compiler improvements in the first bullet list. Am I missing something? |
|
(Probably the wrong issue to comment on this but I can't find the issue or PR for what to put in the next epoch:) Could we make |
|
@nox there's an IRLO thread for reserving keywords. https://internals.rust-lang.org/t/keywords-to-reserve-for-rust2018-epoch/6720 |
|
The final comment period is now complete. |
|
The RFC has now been updated with more emphasis and significantly more text around compiler performance. @michaelwoerister will be heading up a working group on this topic. |
|
This RFC has been merged! There is not a tracking issue for the roadmap; we are still iterating on our approach to tracking, but see the github project page for one possibility. More on the tracking front soon! |
|
Perhaps Rust lang should propose to work with the Khronos Group (Vulkan) to do a Rust front end? |
|
@DrizztVD You may want to get it touch with the gfx-rs project: https://github.com/gfx-rs/gfx. Whether that matches what you have in mind or not, this probably doesn’t need to be within the Rust project. |
|
@SimonSapin I was following on generally from @Lokathor above. The point is to make Rust for game dev more prominent since I see Khronos promoting C and Cpp which is like using a steam train when you could use an electric truck. The question is why can't Rust be the flag bearer? |
|
They only want to focus on issues that can be delivered by the end of this year. How we will tackle multi-year issues in the future is left to be seen, but I suppose the idea is that hopefully someone will randomly get things to the point where they're less than one year to complete, and then they can get the official focus. |
|
@Lokathor That's thinking about things the wrong way around. The idea is to create a sales pitch that can convince some industry folks to add their own resources to Rust. I've sent emails to companies randomly pitching ideas to them. The success rate is just higher if you find the right contact. |
|
I don't entirely disagree with you, but those are the goals that they've committed to. Nothing much is actually stopping you from getting 1st class support for rust into the official vulkan distribution, you just have to do it yourself is all :P Note that we already have the vulkano lib, and I expect that it will get support for the new vulkan release very soon. |
|
Understood. But, my point is centred on the premise that marketing efforts are a direct benefit to a product. Hence, why should the Github community defer such aspects? Any company will budget well for marketing, thus, it may be useful and 'profitable' to have a focus on building industry relations directly. Such an effort can only occur successfully through the community as an entity, not by any one member. |
|
@DrizztVD In general, this RFC describes what we - from the perspective of beginning of 2018 - can commit to with the resources that we have and the demands that we get. It's an action plan, not a wish or idea list. As you may see, we consciously decided to not commit to a polished story for games this year. Note that this doesn't say we won't support. The reasons are manifold, but one of the core things is: we just don't have people driving that effort and team bandwidth to make it happen. The project you describe would be a complete pivot, if we would take that on as a project. We would have to move people away from things that are currently in flight and need to be finished. Also, the RFC factors in a lot of community feedback from more roughly 100 posts and this factors into the focus. It's tough to decide which things to cut for this year and what not. But having a lot of interesting things unfinished is - on a large scale - worse then having half of them done. The Roadmap for 2018 is about finishing things that we can. Some of that might not be obvious: WASM for example may seem like a Mozilla pet project, but there's actually HUGE demand from production users and it isn't very far from delivering a good story. However, and that's crucial: we won't stand in anyones way and support with the resources that we have. There are, for example, people driving the adoption of Rust within the Free Desktop project, which does get engineering support. But that means that we need a player to commit to a certain subject. If you have contacts to Khronos and they are thinking about adoption, we can totally talk things through, connect interested people and find a roadmap. But there has to more then just an idea to make it on the Roadmap. |
This RFC sets the Rust 2018 Roadmap, in accordance with RFC 1728. This year's goals are:
In pursuing these goals, we will focus particularly on four target domains for Rust:
A hearty thank you to the 100-some people who wrote blog posts to help drive this process!
Rendered