7 ms·

Lots of nice language improvements lined up for this year I haven't played with Rust but I like the ecosystem and transparency. Something that stands out is t

Lots of nice language improvements lined up for this year 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

steveklabnik 9y ago
Glad to hear your enthusiasm! > might not finish in time for the year or will be sub-par. Yeah, these areas of focus are where we think we can make substantial improvements, but it may be something like how the webs services goal: last year we shipped fundamentals, this year we're shipping end-to-end awesomeness. So we may only get the fundamentals in place for this year, and maybe we'll need to focus on it next year too. We'll see!
- shaklee3 9y ago
  Not sure if you'll see this, but I really appreciate all the time you spend on here and other places answering questions. It makes a huge difference in getting people interested.
  - steveklabnik 9y ago
    Thank you! I'm glad it's helpful.
masklinn 9y ago
Editions sound like an interesting riff on C/C++'s standards thing. The post isn't really clear what will be gated behind editions though, only non-BC syntactic changes (e.g. literally just new keywords)?
- steveklabnik 9y ago
  Yeah, this post is intended to be a high-level explanation, so we didn't dig into the details. I left a comment below about this: https://news.ycombinator.com/item?id=16569751 https://news.ycombinator.com/item?id=16569751
  - masklinn 9y ago
    OK so non-BC syntactic changes, and warning -> error transitions. Didn't think about the second one but that's way cool. Still, I think it's short and simple enough that it could have been noted in the section, which I feel currently talks about editions a lot but doesn't say much about them.
- Manishearth 9y ago
  Currently: - new keywords https://internals.rust-lang.org/t/keywords-to-reserve-for-rust2018-epoch/6720 https://internals.rust-lang.org/t/keywords-to-reserve-for-ru... . There are a lot, but not all of them may end up being used, this is conservatively reserving them. In case a crate on a previous edition has e.g. a method called `catch`, you can still call it via the "raw identifier syntax", `foo.r#catch()` - you can no longer call methods on raw pointers that do not have a fully concrete type in the new epoch. E.g. `foo.is_null()` won't work if `foo` is `const T` and `T` isn't fully known. (This paves the path for `self: const Self`, which may be introduced later).
- geezerjay 9y ago
  I assumed that the "edition" thing is just an indirect reference to v1.28 or v1.29, just like some linux distros tag the LTS acronym on long term support releases to differentiate them from subsequent intermediate releases. No jab needed, just a codename to refer to the minor version which will be handled as the most stable release and serve as a line in the sand regarding what represents the go-to version for long term projects.
moosingin3space 9y ago
> Only a small minority of crates should require any manual work to opt in to a new edition Is this going to be tracked through the system that catches compiler regressions against the entire crates.io ecosystem?
- steveklabnik 9y ago
  Maybe! Since it’s opt in, we’d assume that people wouldn’t update until it works. It would be interesting to see how people migrate though.

steveklabnik 9y ago

Glad to hear your enthusiasm! > might not finish in time for the year or will be sub-par. Yeah, these areas of focus are where we think we can make substantial improvements, but it may be something like how the webs services goal: last year we shipped fundamentals, this year we're shipping end-to-end awesomeness. So we may only get the fundamentals in place for this year, and maybe we'll need to focus on it next year too. We'll see!

shaklee3 9y ago
Not sure if you'll see this, but I really appreciate all the time you spend on here and other places answering questions. It makes a huge difference in getting people interested.
- steveklabnik 9y ago
  Thank you! I'm glad it's helpful.

masklinn 9y ago

Editions sound like an interesting riff on C/C++'s standards thing. The post isn't really clear what will be gated behind editions though, only non-BC syntactic changes (e.g. literally just new keywords)?

steveklabnik 9y ago
Yeah, this post is intended to be a high-level explanation, so we didn't dig into the details. I left a comment below about this: https://news.ycombinator.com/item?id=16569751 https://news.ycombinator.com/item?id=16569751
- masklinn 9y ago
  OK so non-BC syntactic changes, and warning -> error transitions. Didn't think about the second one but that's way cool. Still, I think it's short and simple enough that it could have been noted in the section, which I feel currently talks about editions a lot but doesn't say much about them.
Manishearth 9y ago
Currently: - new keywords https://internals.rust-lang.org/t/keywords-to-reserve-for-rust2018-epoch/6720 https://internals.rust-lang.org/t/keywords-to-reserve-for-ru... . There are a lot, but not all of them may end up being used, this is conservatively reserving them. In case a crate on a previous edition has e.g. a method called `catch`, you can still call it via the "raw identifier syntax", `foo.r#catch()` - you can no longer call methods on raw pointers that do not have a fully concrete type in the new epoch. E.g. `foo.is_null()` won't work if `foo` is `const T` and `T` isn't fully known. (This paves the path for `self: const Self`, which may be introduced later).
geezerjay 9y ago
I assumed that the "edition" thing is just an indirect reference to v1.28 or v1.29, just like some linux distros tag the LTS acronym on long term support releases to differentiate them from subsequent intermediate releases. No jab needed, just a codename to refer to the minor version which will be handled as the most stable release and serve as a line in the sand regarding what represents the go-to version for long term projects.

moosingin3space 9y ago

> Only a small minority of crates should require any manual work to opt in to a new edition Is this going to be tracked through the system that catches compiler regressions against the entire crates.io ecosystem?

steveklabnik 9y ago
Maybe! Since it’s opt in, we’d assume that people wouldn’t update until it works. It would be interesting to see how people migrate though.