Looks neat. Any notes on const generics e.g.`Array[T, N]`?
The tracking issue for const generics is here: https://github.com/rust-lang/rust/issues/44580
Rust's 2018 roadmap
11–20 of 253 posts
Re: Rust's 2018 roadmap
#12Go is making a large push to wasm as well. There is a branch/fork with a near complete wasm Go compiler. I'm interested in seeing how Rust and Go will compare in the future of the web. Who will win? ;)
Do they ship a GC with every webpage then or am I misunderstanding how it works?
Each module has to have it's own GC.
In my experience, it's been easier to integrate two languages that have GC (JavaScript and Go) than two languages where only one is GC'd (JavaScript and Rust).
What will the interop with Rust and JavaScript look like? How will pointers be managed?
Re: Rust's 2018 roadmap
#13What I'm missing here is why we need to market it as a distinct Rust 2018 release. Do we have breaking changes that require a new epoch/edition? The "Language improvements" section doesn't clarify that. I just hope there is substance in this push, a real technical reason for a new release, not a marketing one.
Re: Rust's 2018 roadmap
#14Looks neat. Any notes on const generics e.g.`Array[T, N]`?
The tracking issue for const generics is here: https://github.com/rust-lang/rust/issues/44580
One of the biggest issues with looking at tracking issues for me is that it's impossible to judge either priority or complexity. This one for instance is a good one. Tags say implemented and approved, the checklist is mostly docs. Yet it looks like from the discussion that this issue is closer to not landing at all in this form than landing.
Re: Rust's 2018 roadmap
#15Earlier quoted context omitted.
Do they ship a GC with every webpage then or am I misunderstanding how it works?
Each module has to have it's own GC. In my experience, it's been easier to integrate two languages that have GC (JavaScript and Go) than two languages where only one is GC'd (JavaScript and Rust). What will the interop with Rust and JavaScript look like? How will pointers be managed?
Since JS and Go do not have the same GC you have the same issue there.
Re: Rust's 2018 roadmap
#16What I'm missing here is why we need to market it as a distinct Rust 2018 release. Do we have breaking changes that require a new epoch/edition? The "Language improvements" section doesn't clarify that. I just hope there is substance in this push, a real technical reason for a new release, not a marketing one.
Marketing reasons are just as "real" as technical reasons.
Editions can do two things:
* add new keywords
* make lints go from warn to deny
Both of these things are "breaking." An example of the former is the "catch" keyword, allowing you to use ? inside a block rather than for the whole function body. An example of the latter is the module changes; the older style will be a warning in 2015 and an error in 2018.
Re: Rust's 2018 roadmap
#17You may have noticed a subtle change: what was previously called “epochs” is now “editions.” Lots of great stuff coming this year! As always, happy to answer any questions.
Could this be used to add an "Ord::clamp" or similar to the stdlib such that it's invisible (and thus wouldn't cause any conflict) to crates with an older "edition"?
Re: Rust's 2018 roadmap
#18Looks neat. Any notes on const generics e.g.`Array[T, N]`?
The design of const generics is fine, but there's underlying technical work in the compiler to be done. We expect const generics to land in nightly this year, but they're unlikely to make it to stable before 2019.
Re: Rust's 2018 roadmap
#19Earlier quoted context omitted.
Each module has to have it's own GC. In my experience, it's been easier to integrate two languages that have GC (JavaScript and Go) than two languages where only one is GC'd (JavaScript and Rust). What will the interop with Rust and JavaScript look like? How will pointers be managed?
Since JS and Go do not have the same GC you have the same issue there.
GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. You can't do that with C/C++ without something like glib.
Re: Rust's 2018 roadmap
#20What I'm missing here is why we need to market it as a distinct Rust 2018 release. Do we have breaking changes that require a new epoch/edition? The "Language improvements" section doesn't clarify that. I just hope there is substance in this push, a real technical reason for a new release, not a marketing one.
There are changes that require a new edition, particularly around new keywords.
However, to be clear, editions are primarily a marketing/communication/project management tool. They give us a way to try to bring together a number of threads of work into a coherent whole, with a high level of polish across the board (including docs and tooling), and then to present that work to the world with a clear story.
It's worth comparing this to the recent Firefox Quantum release, which was likewise a singled out release on the normal train process that brought together a number of important changes, marketing/communication, and a high level of polish.