14 ms·

Rust 2021 Roadmap

178 points by praveenperera 6y ago

gpm 6y ago
This feels like "rust 2021 governance roadmap", which is good and all but not particularly interesting to those of us only peripherally involved. I'd be much more interested to see "rust 2021 language/development/... roadmap" - I sort of expect I will be seeing this soon.
- nicoburns 6y ago
  Yeah, it looks like the project has grown to the point where they're splitting the roadmaps out by team.
- brundolf 6y ago
  The impression I got is that they're taking a year to focus on governance instead of any dramatic technical efforts, in the wake of the Mozilla shake-up and the formation of the Foundation (and continuing project growth). I could be wrong. Edit: This was just speculation and people with better information have weighed in elsewhere
  - steveklabnik 6y ago
    The core team is, yes, but that doesn't mean that improvements to other things won't happen. It's not like the compiler team will stop their work. But the core team is focusing on governance this year.
  - brabel 6y ago
    Frankly, I hope you're right... Rust is an impressive language as it is... if it needs any improvement it's outside the language itself IMHO... all I can think of to complain about is compiler speed, really! The rest is really good stuff.
- steveklabnik 6y ago
  What you're seeing is the project's growth. We're big enough now that we can't talk meaningfully about everything the project does in one roadmap, and given that it's set by the core team, we're more formally delegating most of the specifics to the individual teams. Beyond that, this meta-work is really needed, for the project overall. We've been bumping into limits here for a while. Rust is now large enough that if it were a startup, some people would argue that it's no longer a startup. (I should also note the roadmaps have been trending this way for a while. See the change over time for yourself: * 2020: https://github.com/rust-lang/rfcs/blob/master/text/2857-roadmap-2020.md https://github.com/rust-lang/rfcs/blob/master/text/2857-road... * 2019: https://github.com/rust-lang/rfcs/blob/master/text/2657-roadmap-2019.md https://github.com/rust-lang/rfcs/blob/master/text/2657-road... * 2018: https://github.com/rust-lang/rfcs/blob/master/text/2314-roadmap-2018.md https://github.com/rust-lang/rfcs/blob/master/text/2314-road... * 2017: https://github.com/rust-lang/rfcs/blob/master/text/1774-roadmap-2017.md https://github.com/rust-lang/rfcs/blob/master/text/1774-road... We didn't do this before 2017.)
  - cogman10 6y ago
    Is it fair to say that Mozilla's apparent step back from Rust is a major driver to needing to decide on future governance?
    - steveklabnik 6y ago
      Pretty much nothing to do with it, in the broad scheme of things. Mozilla was not directly involved in governance, and only employed a small number of people involved in project leadership, and those people didn't leave their positions when they left Mozilla. The closest thing to this is that the situation with Mozilla jumpstarted actually finally creating the Rust Foundation, and deciding its relationship to the project is a governance matter. But that's not in scope for this roadmap, and so has nothing directly to do with it.
- maeln 6y ago
  This is partly explained in the chapter unified project tracking [0]. In short: Too many Teams/Project and no current way to track them and their progress easily. It is something they want to address this year. [0] https://github.com/Mark-Simulacrum/rfcs/blob/roadmap-2021/text/0000-roadmap-2021.md#unified-project-tracking https://github.com/Mark-Simulacrum/rfcs/blob/roadmap-2021/te...
- turbinerneiter 6y ago
  I'm into rust 50% for language innovations and 50% for their work on open source governance models. Super important stuff.
- lr1970 6y ago
  > This feels like "rust 2021 governance roadmap", Please don't get me wrong -- governance is important. But concentrating on governance for the entirety of 2021 leaving technical roadmaps to the teams is surprising. What problems is this roadmap trying to solve? 1. Is the existing governance model inadequate and needs to be urgently fixed? 2. Is Rust becoming a "designed by committee" language? This model does not seem to work despite the best intentions. 3. It would be very useful to see not only "what" is in the roadmap but also "why". EDIT: formatting...
nynx 6y ago
Can we change this to link to the rendered copy? https://github.com/Mark-Simulacrum/rfcs/blob/roadmap-2021/text/0000-roadmap-2021.md https://github.com/Mark-Simulacrum/rfcs/blob/roadmap-2021/te...
- 3JPLW 6y ago
  Or how about just waiting until it gets merged and officially adopted?
jph 6y ago
Project health is a good goal. To help toward that, I suggest making it especially easy for people to donate money to Rust and to crate authors. This year, Mozilla laid off Rust developers. Other languages have massive corporate backing e.g. Google Go, Oracle Java, Microsoft C#, etc. I believe strongly in Rust, and also in professional programmers and companies doing funding for excellent software.
- steveklabnik 6y ago
  This would be the job of the foundation, not the project itself. Here's the current state of that: https://github.com/rust-lang/foundation-faq-2020/blob/main/FAQ.md#q-individual-donations https://github.com/rust-lang/foundation-faq-2020/blob/main/F...
  - rectang 6y ago
    I would like to see greater clarity in this document on limits on sponsor influence with regards to technical governance. For example, I'd like to know if technical governance is considered outside the scope of the Board of Directors. This is especially important since you have opted for a 501(c)(6), making it easy to be responsive to donors.
    - steveklabnik 6y ago
      Please open this as an issue on that repository, as that's the process there.
- archseer 6y ago
  AWS hired a whole bunch of core developers: https://aws.amazon.com/blogs/opensource/why-aws-loves-rust-and-how-wed-like-to-help/ https://aws.amazon.com/blogs/opensource/why-aws-loves-rust-a...
amelius 6y ago
https://www.areweguiyet.com/ https://www.areweguiyet.com/
- raphlinus 6y ago
  I'm not sure what you mean by posting just this link. But I'll repeat what I've been saying for a while. The Rust ecosystem is making significant advances toward building what I believe will be a world class GUI toolkit, but we do not yet have a mature, usable solution, and getting there will take time. There are no shortcuts either, though it is possible to get something working by lashing together existing pieces. I obviously consider Druid to to be one of the most promising approaches, but even that aside there are other projects that could become a solid GUI toolkit, including Iced. I also encourage people to look at Makepad, as it does a lot of innovative things and emphasizes priorities such as small binary size and fast compile time.
  - busterarm 6y ago
    As someone not at all involved in Rust but interested in its progress, I think this is an important milestone to hit. In most orgs that I've been a part of, no language tends to meet the standard for consideration until it has been the core of at least one very large public software project. A functioning GUI toolkit is likely a major barrier to that happening in Rust. Until then, we know it exists but doesn't pass inspection for inclusion. So far the largest things we know of built with it are Servo's CSS engine and the NPM authentication service.
    - steveklabnik 6y ago
      > In most orgs that I've been a part of, no language tends to meet the standard for consideration until it has been the core of at least one very large public software project. > So far the largest things we know of built with it are Servo's CSS engine and the NPM authentication service. Here are some others, for your consideration: * Dropbox's storage layer: https://dropbox.tech/infrastructure/extending-magic-pocket-innovation-with-the-first-petabyte-scale-smr-drive-deployment https://dropbox.tech/infrastructure/extending-magic-pocket-i... * CrosVM is an important part of ChromeOS https://chromium.googlesource.com/chromiumos/platform/crosvm/+/837b59f2d97b005ef84ac36efa97530c1bbf2a79/README.md https://chromium.googlesource.com/chromiumos/platform/crosvm... * Firecracker is the underlying tech of AWS Lambda and Fargate https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/ * More coming from Amazon I don't have the ability to easily cite just yet, I hope the re:Invent recordings go up somewhere sometime soon * "EdenSCM is the primary source control system used at Facebook,": https://github.com/facebookexperimental/eden https://github.com/facebookexperimental/eden There's a bunch of other stuff too, of course. Apple has been hiring, but I don't think their usage is public yet. Microsoft is hiring rustc hackers, and has some other stuff going on. And tons of other stuff that may count as "large" depending on how you define it.
deleted 6y ago
[deleted]
vijaybritto 6y ago
To the compiler folks: Can a language with memory safety and speed of rust be made with the compilation speed of Go? I'm just curios. I have no idea about this
- augusto-moura 6y ago
  Yes, of course is possible. This is a question with open definitions, there are dynamic languages with memory safety that can be as fast as Rust (or native code in general) in some cases. Also you could say that Go itself is mostly memory and can be as fast as Rust.
- MrBuddyCasino 6y ago
  For a language to reach the compilation speed of Go, it must have been designed with that goal in mind from the start. The best Rust can hope for is to make it largely irrelevant during dev by doing fine grained incremental compilation.
- pizza234 6y ago
  This question inappropriately assumes that the Rust compiling design and performance are fixed to what is today, and in particular, that they are entirely inherent to the language. There are a few interesting reasons why Rust compilation time is slow and Go's is fast. Here's a summary of the first: https://pingcap.com/blog/reasons-rust-compiles-slowly https://pingcap.com/blog/reasons-rust-compiles-slowly. In theory, with enough time and resources, Rust could see an efficient compiler, but this is something that can't be predicted, as it depends on its future success, or, to be clear, the backing it will have. In practice, the Rust Cranelift backend could provide enough speed (for debug builds) that compilation times won't be slow anymore. Something to consider is also that compilation is a tradeoff between compiling speed and runtime speed (Golang's favoring compiling speed), so one can't have both ends of the the spectrum at the same time.
  - mamcx 6y ago
    > and in particular, that they are entirely inherent to the language. But... this is true. The design of the language is biased to make slow compiling across the full pipeline. Is possible to get into a shout contest about this :), so just look at what Pascal(Delphi) do and how absurdly fast it is, despite the fact is still a "batch compiler". So in the presence of pascal (that is even more complex than Go, to be a really close to C/C++ in capabilities) is clear that Rust is MADE to be slow. And to the point, I used more than +12 languages already, super popular things like this: https://endler.dev/2020/rust-compile-times/ https://endler.dev/2020/rust-compile-times/ NOT exist for Delphi. The "how make delphi compile fast" is to just use delphi. It will compile fast.
rectang 6y ago
> ### How does this group make decisions? In the early days of the Apache Software Foundation, individual projects were expected to draft their own bylaws. This had the advantage of getting project members to think about hard about the content of the bylaws. However, it had the downside of producing a lot of sloppy bylaws with ambiguous or otherwise unworkable rules. For instance, some bylaws were written to require 3/4 of the all eligible voting members to change them, rather than 3/4 of those who vote — which can become a problem as members with voting privileges go inactive and become unreachable. Documenting processes by which conflicts are resolved is hard. If you're lucky, most of the time, the rules don't matter as people reach consensus without having to go through exacting, difficult negotiations. But when you really need a formal process to resolve conflict, then it matters if your process is borken and pathological. The best high-level design is to have the rules for resolving conflicts written by a few specialists who really care about precise drafting, and for most other entities within the organization to inherit those rules whenever possible.
- steveklabnik 6y ago
  The situation here is more about getting it written down at all than it is having conflicting systems; teams almost exclusively operate by full consensus among members, but that's through the sort of inheritance you refer to, rather than having it actually written down somewhere.
  - rectang 6y ago
    Most of the time, you want to bias for action and not require interacting with the rules to move forward. But "full consensus" has a problem with scale — the more eligible voting members you have, the more likely it is that you get a holdout on some issue. There needs to be a process by which the concerns of minority factions are heard, which gives the majority a chance to accommodate those concerns rather than steamroll, but then eventually to move on after establishing workable consensus (as opposed to full consensus) despite the holdout. How do you get there — a majority-rule vote, a super-majority rule vote of x% of those voting? How long does the vote run? What's the escalation process? What entity has final say on technical disputes? And so on. Rust is big enough and has been around long enough that it's certain many bitter disputes have arisen and been dealt with — there's surely an abundance of institutional expertise on resolving contentious issues. Nevertheless, it's in everyone's interest to avoid Balkanized, idiosyncratic, possibly suboptimal formal governance rules for the subgroups, so the process of "writing down the rules" should have the goal of producing one central set of canonical rules, possibly customizable, rather than many sets of potentially incompatible and superficially distinct rules.
some_furry 6y ago
This is a better page to read (although linking to the PR is appropriate for HN): https://github.com/rust-lang/rfcs/blob/256d1969753f23f1182d45dee0bad37900db7c54/text/0000-roadmap-2021.md https://github.com/rust-lang/rfcs/blob/256d1969753f23f1182d4...

Rust 2021 Roadmap

178 points by praveenperera 6y ago

gpm 6y ago

This feels like "rust 2021 governance roadmap", which is good and all but not particularly interesting to those of us only peripherally involved. I'd be much more interested to see "rust 2021 language/development/... roadmap" - I sort of expect I will be seeing this soon.

nicoburns 6y ago
Yeah, it looks like the project has grown to the point where they're splitting the roadmaps out by team.
brundolf 6y ago
The impression I got is that they're taking a year to focus on governance instead of any dramatic technical efforts, in the wake of the Mozilla shake-up and the formation of the Foundation (and continuing project growth). I could be wrong. Edit: This was just speculation and people with better information have weighed in elsewhere
- steveklabnik 6y ago
  The core team is, yes, but that doesn't mean that improvements to other things won't happen. It's not like the compiler team will stop their work. But the core team is focusing on governance this year.
- brabel 6y ago
  Frankly, I hope you're right... Rust is an impressive language as it is... if it needs any improvement it's outside the language itself IMHO... all I can think of to complain about is compiler speed, really! The rest is really good stuff.
steveklabnik 6y ago
What you're seeing is the project's growth. We're big enough now that we can't talk meaningfully about everything the project does in one roadmap, and given that it's set by the core team, we're more formally delegating most of the specifics to the individual teams. Beyond that, this meta-work is really needed, for the project overall. We've been bumping into limits here for a while. Rust is now large enough that if it were a startup, some people would argue that it's no longer a startup. (I should also note the roadmaps have been trending this way for a while. See the change over time for yourself: * 2020: https://github.com/rust-lang/rfcs/blob/master/text/2857-roadmap-2020.md https://github.com/rust-lang/rfcs/blob/master/text/2857-road... * 2019: https://github.com/rust-lang/rfcs/blob/master/text/2657-roadmap-2019.md https://github.com/rust-lang/rfcs/blob/master/text/2657-road... * 2018: https://github.com/rust-lang/rfcs/blob/master/text/2314-roadmap-2018.md https://github.com/rust-lang/rfcs/blob/master/text/2314-road... * 2017: https://github.com/rust-lang/rfcs/blob/master/text/1774-roadmap-2017.md https://github.com/rust-lang/rfcs/blob/master/text/1774-road... We didn't do this before 2017.)
- cogman10 6y ago
  Is it fair to say that Mozilla's apparent step back from Rust is a major driver to needing to decide on future governance?
  - steveklabnik 6y ago
    Pretty much nothing to do with it, in the broad scheme of things. Mozilla was not directly involved in governance, and only employed a small number of people involved in project leadership, and those people didn't leave their positions when they left Mozilla. The closest thing to this is that the situation with Mozilla jumpstarted actually finally creating the Rust Foundation, and deciding its relationship to the project is a governance matter. But that's not in scope for this roadmap, and so has nothing directly to do with it.
maeln 6y ago
This is partly explained in the chapter unified project tracking [0]. In short: Too many Teams/Project and no current way to track them and their progress easily. It is something they want to address this year. [0] https://github.com/Mark-Simulacrum/rfcs/blob/roadmap-2021/text/0000-roadmap-2021.md#unified-project-tracking https://github.com/Mark-Simulacrum/rfcs/blob/roadmap-2021/te...
turbinerneiter 6y ago
I'm into rust 50% for language innovations and 50% for their work on open source governance models. Super important stuff.
lr1970 6y ago
> This feels like "rust 2021 governance roadmap", Please don't get me wrong -- governance is important. But concentrating on governance for the entirety of 2021 leaving technical roadmaps to the teams is surprising. What problems is this roadmap trying to solve? 1. Is the existing governance model inadequate and needs to be urgently fixed? 2. Is Rust becoming a "designed by committee" language? This model does not seem to work despite the best intentions. 3. It would be very useful to see not only "what" is in the roadmap but also "why". EDIT: formatting...

nynx 6y ago

Can we change this to link to the rendered copy? https://github.com/Mark-Simulacrum/rfcs/blob/roadmap-2021/text/0000-roadmap-2021.md https://github.com/Mark-Simulacrum/rfcs/blob/roadmap-2021/te...

3JPLW 6y ago
Or how about just waiting until it gets merged and officially adopted?

jph 6y ago

Project health is a good goal. To help toward that, I suggest making it especially easy for people to donate money to Rust and to crate authors. This year, Mozilla laid off Rust developers. Other languages have massive corporate backing e.g. Google Go, Oracle Java, Microsoft C#, etc. I believe strongly in Rust, and also in professional programmers and companies doing funding for excellent software.

steveklabnik 6y ago
This would be the job of the foundation, not the project itself. Here's the current state of that: https://github.com/rust-lang/foundation-faq-2020/blob/main/FAQ.md#q-individual-donations https://github.com/rust-lang/foundation-faq-2020/blob/main/F...
- rectang 6y ago
  I would like to see greater clarity in this document on limits on sponsor influence with regards to technical governance. For example, I'd like to know if technical governance is considered outside the scope of the Board of Directors. This is especially important since you have opted for a 501(c)(6), making it easy to be responsive to donors.
  - steveklabnik 6y ago
    Please open this as an issue on that repository, as that's the process there.
archseer 6y ago
AWS hired a whole bunch of core developers: https://aws.amazon.com/blogs/opensource/why-aws-loves-rust-and-how-wed-like-to-help/ https://aws.amazon.com/blogs/opensource/why-aws-loves-rust-a...

amelius 6y ago

https://www.areweguiyet.com/ https://www.areweguiyet.com/

raphlinus 6y ago
I'm not sure what you mean by posting just this link. But I'll repeat what I've been saying for a while. The Rust ecosystem is making significant advances toward building what I believe will be a world class GUI toolkit, but we do not yet have a mature, usable solution, and getting there will take time. There are no shortcuts either, though it is possible to get something working by lashing together existing pieces. I obviously consider Druid to to be one of the most promising approaches, but even that aside there are other projects that could become a solid GUI toolkit, including Iced. I also encourage people to look at Makepad, as it does a lot of innovative things and emphasizes priorities such as small binary size and fast compile time.
- busterarm 6y ago
  As someone not at all involved in Rust but interested in its progress, I think this is an important milestone to hit. In most orgs that I've been a part of, no language tends to meet the standard for consideration until it has been the core of at least one very large public software project. A functioning GUI toolkit is likely a major barrier to that happening in Rust. Until then, we know it exists but doesn't pass inspection for inclusion. So far the largest things we know of built with it are Servo's CSS engine and the NPM authentication service.
  - steveklabnik 6y ago
    > In most orgs that I've been a part of, no language tends to meet the standard for consideration until it has been the core of at least one very large public software project. > So far the largest things we know of built with it are Servo's CSS engine and the NPM authentication service. Here are some others, for your consideration: * Dropbox's storage layer: https://dropbox.tech/infrastructure/extending-magic-pocket-innovation-with-the-first-petabyte-scale-smr-drive-deployment https://dropbox.tech/infrastructure/extending-magic-pocket-i... * CrosVM is an important part of ChromeOS https://chromium.googlesource.com/chromiumos/platform/crosvm/+/837b59f2d97b005ef84ac36efa97530c1bbf2a79/README.md https://chromium.googlesource.com/chromiumos/platform/crosvm... * Firecracker is the underlying tech of AWS Lambda and Fargate https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/ * More coming from Amazon I don't have the ability to easily cite just yet, I hope the re:Invent recordings go up somewhere sometime soon * "EdenSCM is the primary source control system used at Facebook,": https://github.com/facebookexperimental/eden https://github.com/facebookexperimental/eden There's a bunch of other stuff too, of course. Apple has been hiring, but I don't think their usage is public yet. Microsoft is hiring rustc hackers, and has some other stuff going on. And tons of other stuff that may count as "large" depending on how you define it.

deleted 6y ago

[deleted]

vijaybritto 6y ago

To the compiler folks: Can a language with memory safety and speed of rust be made with the compilation speed of Go? I'm just curios. I have no idea about this

augusto-moura 6y ago
Yes, of course is possible. This is a question with open definitions, there are dynamic languages with memory safety that can be as fast as Rust (or native code in general) in some cases. Also you could say that Go itself is mostly memory and can be as fast as Rust.
MrBuddyCasino 6y ago
For a language to reach the compilation speed of Go, it must have been designed with that goal in mind from the start. The best Rust can hope for is to make it largely irrelevant during dev by doing fine grained incremental compilation.
pizza234 6y ago
This question inappropriately assumes that the Rust compiling design and performance are fixed to what is today, and in particular, that they are entirely inherent to the language. There are a few interesting reasons why Rust compilation time is slow and Go's is fast. Here's a summary of the first: https://pingcap.com/blog/reasons-rust-compiles-slowly https://pingcap.com/blog/reasons-rust-compiles-slowly. In theory, with enough time and resources, Rust could see an efficient compiler, but this is something that can't be predicted, as it depends on its future success, or, to be clear, the backing it will have. In practice, the Rust Cranelift backend could provide enough speed (for debug builds) that compilation times won't be slow anymore. Something to consider is also that compilation is a tradeoff between compiling speed and runtime speed (Golang's favoring compiling speed), so one can't have both ends of the the spectrum at the same time.
- mamcx 6y ago
  > and in particular, that they are entirely inherent to the language. But... this is true. The design of the language is biased to make slow compiling across the full pipeline. Is possible to get into a shout contest about this :), so just look at what Pascal(Delphi) do and how absurdly fast it is, despite the fact is still a "batch compiler". So in the presence of pascal (that is even more complex than Go, to be a really close to C/C++ in capabilities) is clear that Rust is MADE to be slow. And to the point, I used more than +12 languages already, super popular things like this: https://endler.dev/2020/rust-compile-times/ https://endler.dev/2020/rust-compile-times/ NOT exist for Delphi. The "how make delphi compile fast" is to just use delphi. It will compile fast.

rectang 6y ago

> ### How does this group make decisions? In the early days of the Apache Software Foundation, individual projects were expected to draft their own bylaws. This had the advantage of getting project members to think about hard about the content of the bylaws. However, it had the downside of producing a lot of sloppy bylaws with ambiguous or otherwise unworkable rules. For instance, some bylaws were written to require 3/4 of the all eligible voting members to change them, rather than 3/4 of those who vote — which can become a problem as members with voting privileges go inactive and become unreachable. Documenting processes by which conflicts are resolved is hard. If you're lucky, most of the time, the rules don't matter as people reach consensus without having to go through exacting, difficult negotiations. But when you really need a formal process to resolve conflict, then it matters if your process is borken and pathological. The best high-level design is to have the rules for resolving conflicts written by a few specialists who really care about precise drafting, and for most other entities within the organization to inherit those rules whenever possible.

steveklabnik 6y ago
The situation here is more about getting it written down at all than it is having conflicting systems; teams almost exclusively operate by full consensus among members, but that's through the sort of inheritance you refer to, rather than having it actually written down somewhere.
- rectang 6y ago
  Most of the time, you want to bias for action and not require interacting with the rules to move forward. But "full consensus" has a problem with scale — the more eligible voting members you have, the more likely it is that you get a holdout on some issue. There needs to be a process by which the concerns of minority factions are heard, which gives the majority a chance to accommodate those concerns rather than steamroll, but then eventually to move on after establishing workable consensus (as opposed to full consensus) despite the holdout. How do you get there — a majority-rule vote, a super-majority rule vote of x% of those voting? How long does the vote run? What's the escalation process? What entity has final say on technical disputes? And so on. Rust is big enough and has been around long enough that it's certain many bitter disputes have arisen and been dealt with — there's surely an abundance of institutional expertise on resolving contentious issues. Nevertheless, it's in everyone's interest to avoid Balkanized, idiosyncratic, possibly suboptimal formal governance rules for the subgroups, so the process of "writing down the rules" should have the goal of producing one central set of canonical rules, possibly customizable, rather than many sets of potentially incompatible and superficially distinct rules.

some_furry 6y ago

This is a better page to read (although linking to the PR is appropriate for HN): https://github.com/rust-lang/rfcs/blob/256d1969753f23f1182d45dee0bad37900db7c54/text/0000-roadmap-2021.md https://github.com/rust-lang/rfcs/blob/256d1969753f23f1182d4...