Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's 2018 roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

21–30 of 253 posts

Re: Rust's 2018 roadmap

#21

Post by geofft »

kibwen wrote: post #9
pknopf wrote: post #4

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

I'm not just being diplomatic when I say that hopefully we can avoid the Rust vs. Go debate here. :P WASM is a bid to help future-proof the relevancy of the web in the face of mobile app stores, and seeing many languages embrace it is a good thing, no matter what those languages are. Heck, since WASM is sandboxed anyway it doesn't even matter if you choose C or C++ over Go or Rust, since memory unsafety shouldn't be…

Well, it's not exploitable to get out of the sandbox, but there's still interesting data inside the sandbox. For instance, if some website's wasm is parsing the URL to read the URL fragment or something, you could imagine an attacker sending me to a malformed URL, hoping to overflow the URL parser and gain execution with all the cookies of that web page.

Re: Rust's 2018 roadmap

#22

Post by username223 »

kibwen wrote: post #5
the_mitsuhiko wrote: post #3

Earlier quoted context omitted.

What happened to "era"?!

The bikeshed works in mysterious ways. :P

Era, epoch, edition, excretion, excrescence,... I'm looking forward to watching Rust's continued evolution in the new... whatever they decide to call it.

Re: Rust's 2018 roadmap

#23

Post by squiguy7 »

steveklabnik wrote: post #2

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

> You can use old editions indefinitely on new compilers; editions are opt-in.

This is great to hear! A best-effort backwards compatibility guarantee is important to have for a language that has a lot of development.

Re: Rust's 2018 roadmap

#24

Post by steveklabnik »

pknopf wrote: post #12
woah wrote: post #6

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

> What will the interop with Rust and JavaScript look like? How will pointers be managed?

First, a disclaimer: all of this is extremely early days, and subject to change.

There's two questions hidden here: "what does the workflow look like?" and "how does this work technically?"

Currently, "what does the workflow look like" is this: https://github.com/ashleygwilliams/wasm-pack#%EF%B8%8F--how-...

"how does this work technically" is this: https://github.com/alexcrichton/wasm-bindgen

The former provides a nice workflow that's fundamentally built on the latter.

Re: Rust's 2018 roadmap

#25

Post by aturon »

pknopf wrote: post #4

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

I think the domains of use will be quite different. Since Rust doesn't require a GC or other runtime support, we envision it being used in specific modules to provide a boost to code otherwise written in JS. See https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with... for example.

By contrast, for a language like Go, it's probably more practical to ship entire apps, rather than embedding in libraries, because there's significantly more overhead in terms of runtime system support.

Re: Rust's 2018 roadmap

#26

Post by aturon »

cesarb wrote: post #17
steveklabnik wrote: post #2

You 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"?

Yes, it could! There aren't plans to do so yet, but it'd be worth spinning up a thread on internals about this.

Re: Rust's 2018 roadmap

#27

Post by kibwen »

steveklabnik wrote: post #16
kvark wrote: post #13

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

> Both of these things are "breaking."

Though to re-emphasize the OP, all such breakage is opt-in (via compiler flags and/or Cargo.toml), and crates on different editions can be mixed freely. There's no enforced migration or involuntary backwards-incompatibility.

Re: Rust's 2018 roadmap

#28

Post by the_mitsuhiko »

pknopf wrote: post #19
the_mitsuhiko wrote: post #15

Earlier quoted context omitted.

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.

Not entirely sure what you are referring to or how it relates to the issue here. If you have two separate heaps (what you have between go and JS) then they will be collected separately. As such you need to somehow keep objects on the other side alive. Worst: in Go the language does not guarantee that the GC won't compact (it doesn't do correctly though). As such you can't even pass pointers to JavaScript, you need to create handles.

I played around with both Go and Rust from Python and the garbage collection made things harder not easier. Now we write lots of Rust modules for Python and managing memory is pretty easy. We have Python wrapper objects that keep one pointer alive.

Re: Rust's 2018 roadmap

#30

Post by the_mitsuhiko »

username223 wrote: post #22
kibwen wrote: post #5

Earlier quoted context omitted.

The bikeshed works in mysterious ways. :P

Era, epoch, edition, excretion, excrescence,... I'm looking forward to watching Rust's continued evolution in the new... whatever they decide to call it.

Should have been "cycle" with a fancy name instead of number.
Post reply on HN