31–40 of 253 posts
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"?
[1] https://internals.rust-lang.org/t/announcing-the-cli-working...
I haven't played with Rust but I like the ecosystem and transparency.
Something that stands out is the Compatibility across editions section. Seems like they really thought this through:
> you can be on a different edition from your dependencies.
> Edition-related warnings...must be easily fixable via an automated migration tool (rustfix). Only a small minority of crates should require any manual work to opt in to a new edition
> the progression of new compiler versions is independent from editions; you can migrate at your leisure, and don’t have to worry about ecosystem compatibility; These are huge!
This really helps with ecosystem fragmentation. Other languages take note (please!)
Another thing that stood out was the embedded as first class citizen:
> Embedded devices. Rust has the potential to make programming resource-constrained devices much more productive—and fun! We want embedded programming to reach first-class status this year.
This seems like the only thing on the list that might not finish in time for the year or will be sub-par. I don't know how much more work they need to do but embedded programming requires fine-tune memory management and access to special registers on a per-hardware basis. A lot of times these things fly in the face of assumptions many programming languages (and compilers) make
Earlier quoted context omitted.
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.
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.
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…
> It's worth comparing this to the recent Firefox Quantum release
I don't think it's a fare comparison. Firefox Quantum doesn't involve much of breaking changes (if you don't consider deprecating the old plugins one, that is). And the changes are most drastic since early versions of FF. With Rust though, it's clearly improving every day, I don't see Q3 2018 as any sort of "quantum leap". At least for as long as it doesn't include the const generics :)
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.
It sounds like you're mostly worried about memory leaks, but the primary concern with trying to get two separate GCs to play nicely isn't leaking memory, it's double-frees (both GCs trying to collect the same resource) and use-after-free (code in one language trying to use a resource that's been accidentally collected by the GC of the other language).
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?
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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…
That's what I've been afraid of. When epochs were announced, I thought it is kinda nice to have backwards compatibility while introducing breaking changes. It's a good technical concept. Trying to change it's role into "marketing/communication/project management tool" out of a sudden is what puzzles me. > It's worth comparing this to the recent Firefox Quantum release I don't think it's a fare comparison. Firefox Qua…
That is what editions are, though (though as I keep insufferably emphasizing, all breakage is opt-in). Can you be more specific about what you're afraid of?
> Firefox Quantum doesn't involve much of breaking changes (if you don't consider deprecating the old plugins one, that is).
You must not have been on any web forum discussing Firefox 57 if you don't remember the cacophonous, world-ending drama that deprecating legacy add-ons created. :P