3 ms·

I gave up during the switch to the 2018 edition. Today, I still write 2015 code because I couldn't bother to decipher how paths and `extern crate` had changed.

I gave up during the switch to the 2018 edition. Today, I still write 2015 code because I couldn't bother to decipher how paths and `extern crate` had changed. The documentation on the differences was too sparse to relearn it (maybe there was enough documentation to start for scratch, I don't know). It was also a busy time with NLL (those changes were simple). Since then the 2015 edition hasn't stopped either: warnings popped up to use `dyn`, warnings that deprecated `std` functions, new feature gates added and old feature gates were removed. Libraries weren't spared: The minor releases of `rand` are so incompatible that they needs upgrade guides themselves. For 2018 I may learn it 'sometime', every change further delays. There's Futures, there's async now. I don't have time to decipher the types since I don't need it. However there was and is so much discussion that I'm already tired.

mjw1007 6y ago
It doesn't help that the Reference still hasn't been updated to describe how 'use' paths work nowadays (for well over a year now).
- steveklabnik 6y ago
  Are you sure? Is there a bug? As far as I know, https://doc.rust-lang.org/stable/reference/paths.html https://doc.rust-lang.org/stable/reference/paths.html is correct, though I haven't been doing a ton of reference work.
  - mjw1007 6y ago
    The bug is https://github.com/rust-lang/reference/issues/487 https://github.com/rust-lang/reference/issues/487 I'm not quite sure how it got to be that way, as the policy is that reference documentation is supposed to be written (if not actually in place) by the time a feature is stabilised. (I know you know this, because you wrote that policy.)
    - steveklabnik 6y ago
      Thanks! I wonder if it's been updated and the issue has not been closed, but I will take a look this week. Someone else wrote it actually! But, we ended up relaxing it recently, due to build system concerns. Polyrepos are hard :/
      - mjw1007 6y ago
        It has not been updated. use-declarations.md was updated three days ago to replace incorrect text with a note saying «Note: This section is incomplete» though. I understand why build system trouble meant the policy was changed from "the documentation must be in place" to "the documentation must be written". I do not understand why anything prevents the stabilisation process including a checklist item confirming that the documentation has been at least drafted.
        steveklabnik 6y ago
        I only glanced at it but saw a "differences from rust 2015" section and that would indicate to me that it got updated somehow. Regardless, I'll look into it for real, so we'll get it sorted either way. > I do not understand why anything prevents the stabilisation process including a checklist item confirming that the documentation has been at least drafted. Nothing really, but we have bigger designs for the RFC process ("staged RFCs") that would introduce this, and so I haven't pushed for it in the meantime as its own separate thing.
        mjw1007 6y ago
        It was updated for the half-way-house 2018-edition changes in Rust 1.31 (in December 2018). It wasn't updated for the further changes ("uniform paths") made six weeks later in Rust 1.32.
Ar-Curunir 6y ago
> new feature gates added and old feature gates were removed This is only a problem on nightly, which is a toolchain which explicitly makes no stability guarantees and is intended for experimentation? > For 2018 I may learn it 'sometime', every change further delays. There's Futures, there's async now. You don't have to interact with things that you don't use, though. For example I've been on Rust 2018 since day one, and I still haven't needed to learn about futures.
- worik 6y ago
  Reading code matters too. Languages are not just written
  - jjnoakes 6y ago
    Sure, but when reading code you didn't write, you have a whole list of things you need to spend extra time on - the style, the way functions are broken up, how data types are organized... if you come across one or two new language features in use as well, stopping to learn enough about them to reason about the code is not a big deal (to me at least).
- rrobukef 6y ago
  And one day, tokio or some other Future-library will be needed as a solution and I'll need to read a state-of-the-art codebase with all the newest features.
Rusky 6y ago
> I couldn't bother to decipher how paths and `extern crate` had changed. I don't know if you're looking for this, or if it will help, but here's the way I think of it: In 2015, `use` paths are relative to the root module of the crate, and `extern crate` adds dependencies as items there. In 2018, `use` paths are relative to one level above the root module of the crate, or "the root listing of all crates". That's it- if you think of them like file paths, the edition basically just did `mv /your_crate/{all extern crates} /`, or alternatively `mv /{all your items} /crate/`.
dralley 6y ago
The "2018 edition guide" covers this fairly well. https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html https://doc.rust-lang.org/edition-guide/rust-2018/module-sys...
worik 6y ago
I feel your pain. People are mossing the point, and instead of seeing that learning a moving target is a PITA they are "helping" you with solutions to your problems... I love Rust. I hope to get a chance to use it professionally. But I expect my C coding skills are more valuable for now, so it will remain a hobby....
Thiez 6y ago
> I gave up during the switch to the 2018 edition. Today, I still write 2015 code because I couldn't bother to decipher how paths and `extern crate` had changed. That exact same thing happened to me. When the 2018 edition came along and made a bunch of changes that seemed, from my perspective, arbitrary and unnecessary, I couldn't really be bothered to keep up anymore and lost a lot of enthusiasm for the future of language and the team in charge. I also think the addition of async is interesting and I may have to bite the bullet and really learn 2018. Although I hate the postfix `.await` keyword that looks like member access. The recent `try` block discussion seems to be adding additional sugar that increases the learning curve for dubious gains. Would that the goal of minimalism of the standard library also applied to the language itself.

mjw1007 6y ago

It doesn't help that the Reference still hasn't been updated to describe how 'use' paths work nowadays (for well over a year now).

steveklabnik 6y ago
Are you sure? Is there a bug? As far as I know, https://doc.rust-lang.org/stable/reference/paths.html https://doc.rust-lang.org/stable/reference/paths.html is correct, though I haven't been doing a ton of reference work.
- mjw1007 6y ago
  The bug is https://github.com/rust-lang/reference/issues/487 https://github.com/rust-lang/reference/issues/487 I'm not quite sure how it got to be that way, as the policy is that reference documentation is supposed to be written (if not actually in place) by the time a feature is stabilised. (I know you know this, because you wrote that policy.)
  - steveklabnik 6y ago
    Thanks! I wonder if it's been updated and the issue has not been closed, but I will take a look this week. Someone else wrote it actually! But, we ended up relaxing it recently, due to build system concerns. Polyrepos are hard :/
    - mjw1007 6y ago
      It has not been updated. use-declarations.md was updated three days ago to replace incorrect text with a note saying «Note: This section is incomplete» though. I understand why build system trouble meant the policy was changed from "the documentation must be in place" to "the documentation must be written". I do not understand why anything prevents the stabilisation process including a checklist item confirming that the documentation has been at least drafted.
      - steveklabnik 6y ago
        I only glanced at it but saw a "differences from rust 2015" section and that would indicate to me that it got updated somehow. Regardless, I'll look into it for real, so we'll get it sorted either way. > I do not understand why anything prevents the stabilisation process including a checklist item confirming that the documentation has been at least drafted. Nothing really, but we have bigger designs for the RFC process ("staged RFCs") that would introduce this, and so I haven't pushed for it in the meantime as its own separate thing.
        mjw1007 6y ago
        It was updated for the half-way-house 2018-edition changes in Rust 1.31 (in December 2018). It wasn't updated for the further changes ("uniform paths") made six weeks later in Rust 1.32.

Ar-Curunir 6y ago

> new feature gates added and old feature gates were removed This is only a problem on nightly, which is a toolchain which explicitly makes no stability guarantees and is intended for experimentation? > For 2018 I may learn it 'sometime', every change further delays. There's Futures, there's async now. You don't have to interact with things that you don't use, though. For example I've been on Rust 2018 since day one, and I still haven't needed to learn about futures.

worik 6y ago
Reading code matters too. Languages are not just written
- jjnoakes 6y ago
  Sure, but when reading code you didn't write, you have a whole list of things you need to spend extra time on - the style, the way functions are broken up, how data types are organized... if you come across one or two new language features in use as well, stopping to learn enough about them to reason about the code is not a big deal (to me at least).
rrobukef 6y ago
And one day, tokio or some other Future-library will be needed as a solution and I'll need to read a state-of-the-art codebase with all the newest features.

Rusky 6y ago

> I couldn't bother to decipher how paths and `extern crate` had changed. I don't know if you're looking for this, or if it will help, but here's the way I think of it: In 2015, `use` paths are relative to the root module of the crate, and `extern crate` adds dependencies as items there. In 2018, `use` paths are relative to one level above the root module of the crate, or "the root listing of all crates". That's it- if you think of them like file paths, the edition basically just did `mv /your_crate/{all extern crates} /`, or alternatively `mv /{all your items} /crate/`.

dralley 6y ago

The "2018 edition guide" covers this fairly well. https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html https://doc.rust-lang.org/edition-guide/rust-2018/module-sys...

worik 6y ago

I feel your pain. People are mossing the point, and instead of seeing that learning a moving target is a PITA they are "helping" you with solutions to your problems... I love Rust. I hope to get a chance to use it professionally. But I expect my C coding skills are more valuable for now, so it will remain a hobby....

Thiez 6y ago

> I gave up during the switch to the 2018 edition. Today, I still write 2015 code because I couldn't bother to decipher how paths and `extern crate` had changed. That exact same thing happened to me. When the 2018 edition came along and made a bunch of changes that seemed, from my perspective, arbitrary and unnecessary, I couldn't really be bothered to keep up anymore and lost a lot of enthusiasm for the future of language and the team in charge. I also think the addition of async is interesting and I may have to bite the bullet and really learn 2018. Although I hate the postfix `.await` keyword that looks like member access. The recent `try` block discussion seems to be adding additional sugar that increases the learning curve for dubious gains. Would that the goal of minimalism of the standard library also applied to the language itself.