New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Rust 2018 Roadmap #2314

Merged
merged 10 commits into from Mar 5, 2018

Conversation

@aturon
Member

aturon commented Jan 30, 2018

This RFC sets the Rust 2018 Roadmap, in accordance with RFC 1728. This year's goals are:

  • Ship an epoch release: Rust 2018.
  • Build resources for intermediate Rustaceans.
  • Connect and empower Rust’s global community.
  • Grow Rust’s teams and new leaders within them.

In pursuing these goals, we will focus particularly on four target domains for Rust:

  • Web services.
  • WebAssembly.
  • CLI apps.
  • Embedded devices.

A hearty thank you to the 100-some people who wrote blog posts to help drive this process!

Rendered

@aturon aturon added the T-core label Jan 30, 2018

- **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

This comment has been minimized.

@mgattozzi

mgattozzi Jan 30, 2018

Contributor

Was this to be discussed during RFC or was it intended to be fleshed out before hand and discussed?

@mgattozzi

This comment has been minimized.

Contributor

mgattozzi commented Jan 30, 2018

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

- **Non-lexical lifetimes**. Currently in “alpha” state on nightly, with work ongoing.
- `**impl Trait**`. Nearing readiness for stabilization FCP.

This comment has been minimized.

@hawkw

hawkw Jan 30, 2018

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**`
@sgrif

This comment has been minimized.

Contributor

sgrif commented Jan 30, 2018

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!

> [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)

This comment has been minimized.

@sinistersnare

sinistersnare Jan 30, 2018

Why is this like this?

@nimtiazm

This comment has been minimized.

nimtiazm commented Jan 30, 2018

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?

continued mentoring:
> [I’d like to see a stronger focus [on] mentoring.](https://manishearth.github.io/blog/2018/01/10/rust-in-2018/) (@manishearth)

This comment has been minimized.

@Manishearth

Manishearth Jan 30, 2018

Member

note: the [on] is no longer necessary, i fixed the typo in my post and it now just says "on"

@aturon

This comment has been minimized.

Member

aturon commented Jan 30, 2018

@nimtiazm

Would it be a good idea to have them as fine-grained and deliverable 2018 targets?

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.

@kennytm

Just some nitpicks, since I see many links are broken up into pieces when viewing the rendered document 😝

> [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)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

Why this quote is broken up into 4 identical links 😄

#### Language
> [Rust 2018: Consolidation (](https://deterministic.space/rust-2018.html)@killercup)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

The ( should be outside of the link

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/)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

Empty link

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)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

Separated links

#### 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)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

Separated links

> [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)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

Separated links

> [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)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

Separated links

### 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)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

Separated links

> [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)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

Separated links

### 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)

This comment has been minimized.

@kennytm

kennytm Jan 30, 2018

Member

[the embedded community] should probably be *the embedded community*

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Jan 30, 2018

Continuing to improve compile times. By the end of the year, recompilations on large crates should be around 30s.

It’s very encouraging to see be a focus, but that second sentence is both vague and weirdly precise. How large is large? :)

@Lokathor

This comment has been minimized.

Lokathor commented Jan 30, 2018

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".

@retep998

This comment has been minimized.

Member

retep998 commented Jan 30, 2018

Continuing to improve compile times. By the end of the year, recompilations on large crates should be around 30s.

It’s very encouraging to see be a focus, but that second sentence is both vague and weirdly precise. How large is large? :)

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.

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Jan 30, 2018

On a higher level: it looks like 2018 will be a great year for Rust, I’m excited! 😄

@gnzlbg

This comment has been minimized.

Contributor

gnzlbg commented Jan 30, 2018

@SimonSapin

How large is large? :)

I hope @aturon meant rustc/servo kind of large.

@KasMA1990

This comment has been minimized.

KasMA1990 commented Jan 30, 2018

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?

> [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!

This comment has been minimized.

@mark-i-m

mark-i-m Jan 30, 2018

Contributor

Rust has already seem some production update...

I think this sentence is missing words?

@tehroot

This comment has been minimized.

tehroot commented Jan 30, 2018

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.

@Centril

This comment has been minimized.

Contributor

Centril commented Jan 30, 2018

Some thoughts of mine:

1. generic associated types

I 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 applications

Rust 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 Rust + HTML + CSS and driven with WebRender and Stylo while using WASM for sandboxing and plugin support. I think this can also interact nicely with what Mozilla is doing and the WASM domain.

3. a focus on testing frameworks

Rust has some good testing frameworks such as proptest and spectral. For 2018, I'd love for there to be a stable and solid way to run custom test runners with cargo integration. I'd also love if our testing frameworks went from good to great. Hopefully, we can even outshine Haskell and Erlang when it comes to testing by the end of this year. I believe this goal to be important because it benefits rustaceans across the board. In my view, main focus here should be on improving the testing frameworks themselves rather than cargo integration.

@glaebhoerl

This comment has been minimized.

Contributor

glaebhoerl commented Jan 30, 2018

(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...?)

@mark-i-m mark-i-m referenced this pull request Jan 30, 2018

Open

Tracking issue: declarative macros 2.0 #39412

9 of 19 tasks complete
@gnzlbg

This comment has been minimized.

Contributor

gnzlbg commented Jan 30, 2018

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:

  • Rust doesn't support LLVM's code coverage instrumentation (rust-lang/rust#34701), relying instead on gcov/kcov which are brittle, inaccurate, and doesn't work integrate well with Rust at all (e.g. documentation tests are broken rust-lang/rust#36956).
  • Rust code coverage is a pain to set up and use (although cargo-travis makes this easier). Obtaining code-coverage information should be as simple as cargo test --coverage and probably something that cargo test should actually report by default at least for debug builds.

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?

@withoutboats

This comment has been minimized.

Contributor

withoutboats commented Jan 30, 2018

(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...?)

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.

@eddyb

This comment has been minimized.

Member

eddyb commented Jan 30, 2018

@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.

@matthiasbeyer

This comment has been minimized.

matthiasbeyer commented Jan 30, 2018

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 Goals -> Libraries would be appropriate, I think.


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.

@aturon

This comment has been minimized.

Member

aturon commented Jan 30, 2018

@SimonSapin

Continuing to improve compile times. By the end of the year, recompilations on large crates should be around 30s.

It’s very encouraging to see be a focus, but that second sentence is both vague and weirdly precise. How large is large? :)

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.


@Lokathor

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.

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:

  • Scientific/numeric computing
  • Games
  • Mobile apps
  • Desktop apps

@retep998

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.

What would you hope to see?


@KasMA1990

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?

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.


@Centril

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.

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.

a focus on writing desktop applications

See my response to @Lokathor above re: additional domains.

a focus on testing frameworks

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?


@gnzlbg

I think it is sad that code coverage is not mentioned as an important missing piece of the tooling.

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?

@aturon

This comment has been minimized.

Member

aturon commented Jan 30, 2018

@matthiasbeyer

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)?

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.

@Centril

This comment has been minimized.

Contributor

Centril commented Jan 30, 2018

@aturon

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.

I'm making the subjective value judgement here that GAT is more important than those features (perhaps save for impl Trait) since it enables APIs that you can't even express without it and so it should take priority wrt. work, but that's just my opinion that y'all can disagree with =)

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.

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?

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.

@Lokathor

This comment has been minimized.

Lokathor commented Jan 30, 2018

I guess it's cool and all that we've already got momentum in X, Y, and Z areas, but just be sure to not get swept up in too much Survivor Bias, or we could easily get stuck in those areas. (This was covered in one of the rust2018 posts quite well)

@aturon

This comment has been minimized.

Member

aturon commented Feb 23, 2018

@LinearZoetrope thanks for writing in! FWIW, the Core Team also sees this area as having great potential for Rust. But at the same time, our focus for this year is on shipping what can reasonably be shipped within 2018, and given that const generics are vital in this space, but at the same time are blocked on various other work, it's simply not viable to promise even a stable foundation in 2018. Meanwhile, the four domains highlighted in the roadmap are ones where we feel like Rust can shine this year.

That said, I think a numerics WG in 2019 would be awesome, and we'd probably have enough of the foundational pieces in place by then for that to make sense.

@aturon

This comment has been minimized.

Member

aturon commented Feb 23, 2018

@mark-i-m

Are there plans to officially push harder on efforts like rust-lang/rust#46564 ?

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.

@nox

This comment has been minimized.

Contributor

nox commented Feb 25, 2018

I see this RFC has entered FCP but still doesn't mention compiler improvements in the first bullet list. Am I missing something?

@nox

This comment has been minimized.

Contributor

nox commented Feb 25, 2018

(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 guard a keyword in the next epoch, to revive the let...else RFC with a syntax similar to the one in Swift for that feature?

@kennytm

This comment has been minimized.

Member

kennytm commented Feb 25, 2018

@nox there's an IRLO thread for reserving keywords. https://internals.rust-lang.org/t/keywords-to-reserve-for-rust2018-epoch/6720

@rfcbot

This comment has been minimized.

rfcbot commented Feb 26, 2018

The final comment period is now complete.

@aturon

This comment has been minimized.

Member

aturon commented Mar 5, 2018

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.

@aturon

This comment has been minimized.

Member

aturon commented Mar 5, 2018

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!

@aturon aturon merged commit b00660e into rust-lang:master Mar 5, 2018

@DrizztVD

This comment has been minimized.

DrizztVD commented Mar 8, 2018

Perhaps Rust lang should propose to work with the Khronos Group (Vulkan) to do a Rust front end?

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Mar 8, 2018

@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.

@DrizztVD

This comment has been minimized.

DrizztVD commented Mar 8, 2018

@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?

@Lokathor

This comment has been minimized.

Lokathor commented Mar 8, 2018

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.

@DrizztVD

This comment has been minimized.

DrizztVD commented Mar 8, 2018

@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.

@Lokathor

This comment has been minimized.

Lokathor commented Mar 9, 2018

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.

@DrizztVD

This comment has been minimized.

DrizztVD commented Mar 9, 2018

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.

@skade

This comment has been minimized.

skade commented Mar 9, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment