4 ms·

> I need to now change my code in order to keep it idiomatic I'm not a Rust person so maybe I'm missing something, but why does the OP need to keep the code id

by kens 7y ago

> I need to now change my code in order to keep it idiomatic I'm not a Rust person so maybe I'm missing something, but why does the OP need to keep the code idiomatic? Can't the changing fashions in what's idiomatic be ignored?

davidcuddeback 7y ago
> Can't the changing fashions in what's idiomatic be ignored? They absolutely can, but you might be stuck on an older "edition" of Rust. I've stuck with `try!()` for error-handling, because I think error-handling deserves more prominence than a single character. But that means my code is stuck on Rust 2015. If something I need is added to Rust 2018 or a later edition, I'll be forced to update or backport.
- Izkata 7y ago
  > But that means my code is stuck on Rust 2015. ...can't you upgrade and choose not to make that change? Did something happen to make that not compile? (not a Rust user)
  - boardwaalk 7y ago
    It looks like they might need to use "r#try!(...)" in Rust 2018 (a trivial search replace, 'cargo fix' might do it too, not sure), but the macro is still available: https://doc.rust-lang.org/stable/std/macro.try.html https://doc.rust-lang.org/stable/std/macro.try.html It's trivial to implement yourself, too (if you, for example, wanted to give it a non-reserved name).
    - davidcuddeback 7y ago
      Thanks. Didn't know about the raw identifier syntax. That's kinda ugly, so I'd probably still go with copying it to all of my projects and giving it a new name if I were to update to Rust 2018.
      - alvarelle 7y ago
        On the other hand, you could argue that the r# gives you "more prominence" which is exactly the stated goal of using that macro.
  - davidcuddeback 7y ago
    > Did something happen to make that not compile? `try` became a reserved keyword in Rust 2018 and the `try!()` macro was dropped (edit: not dropped, see @boardwaalk's comment). I could copy the old macro to all of my code bases and give it a new name. The two things stopping me from doing that are (1) I don't have any reason to update to Rust 2018, and (2) I can't think of a good name for a replacement macro. I'm thinking `check!()`, but not sold on the name. > (not a Rust user) One thing to know about Rust 2015 vs 2018 vs future "editions" is that they're a distinct versioning mechanism from Rust 1.23, 1.24, etc. The latest version of the Rust compiler still supports Rust 2015 and I believe it's been promised to be supported in perpetuity. So it's not like I run a risk of being without a Rust 2015 compiler available.
    - gpm 7y ago
      Just to expand on the editions things, editions are local to the crate. A Rust 2015 crate can freely use a Rust 2018 crate and the reverse. So davidcuddeback isn't being locked out of using up to date dependencies either.
    - majewsky 7y ago
      > I can't think of a good name for a replacement macro What about do_or_do_not!(). After all, there is no try!(). ;)
      - davidcuddeback 7y ago
        Heh. That's the argument that was made against using Rails' `try()` method at my last place of work. Made me laugh. Thanks. :)
- deleted 7y ago
  [deleted]
- swalladge 7y ago
  > If something I need is added to Rust 2018 or a later edition, I'll be forced to update or backport. Should add that new editions with breaking changes are only expected to happen rarely (iirc every 3 years), a large difference to 6 weeks.
- fluffything 7y ago
  > If something I need is added to Rust 2018 or a later edition Most new language getting added to Rust, are added to the Rust 2015 edition (e.g. NLL). If you need a language feature that is added to a later edition only (like the `try` keyword), that's because the feature is incompatible with code being used in earlier editions (which declared a macro with the keyword name). You can continue using the macro by just using raw-literal syntax.. but my old Rust code tends to "just work", so I don't really need to update it. My crates are also very small, so if I'd ever need an update, it wouldn't take too long - but haven't had to do that yet, so can't comment. I tend to write most of my new code on new crates, so I default them to whatever edition was the default when I create them, and never look back. I have lot of 2015 crates in my dependency tree, and that works just fine.
typon 7y ago
I think its implied that having idiomatic code is better than not having idiomatic code.
- deleted 7y ago
  [deleted]
- justinclift 7y ago
  Unless it wastes people's time every x weeks, just to update to the latest hmmm... "fashion trend" for no practical benefit? :)
  - Ar-Curunir 7y ago
    And because that's not the case with Rust, there is no such problem =)
  - jeffparsons 7y ago
    Even if you do believe that it's for "no practical benefit", the value of _x_ in Rust's case is ~156. (I.e. roughly once every three years, when a new "edition" is stabilized.) And the transition is mostly automated. Speaking as somebody who has maintained several medium sized Rust code bases over the years, I can comfortably say that it's not a big deal. What _has_ been a big deal, on the other hand, is getting excited about what I can do with extremely unstable libraries, and then spending a lot of time keeping up with their breaking changes. But I'd be a bit silly to complain about this; in each case, I opted in to an immature ecosystem very early on because I was excited about being part of its early growth. I don't expect to have my cake and eat it, too.
bosswipe 7y ago
If you don't update over time there's a danger that you won't be able to interoperate with other software, or you might not be able to take advantage of new features. It's easier to make small changes over time then trying to do a big bang upgrade with several years of changes.
- anderskaseorg 7y ago
  Rust 2015 and Rust 2018 have no trouble interoperating with each other in both directions. If you want to update, that's great, and there are automatic tools to help you, but you don't need to feel compelled to do it by the pace of language development.
  - bluejekyll 7y ago
    Even with the Futures ecosystem having a massive change first with the std::future impls and then with async/await, there are backward compatible libraries that make it possible to inter-operate between the two. You probably don’t want to live like that forever, but it’s a way of not being “required” to upgrade large code bases.

by kens 7y ago

davidcuddeback 7y ago

> Can't the changing fashions in what's idiomatic be ignored? They absolutely can, but you might be stuck on an older "edition" of Rust. I've stuck with `try!()` for error-handling, because I think error-handling deserves more prominence than a single character. But that means my code is stuck on Rust 2015. If something I need is added to Rust 2018 or a later edition, I'll be forced to update or backport.

Izkata 7y ago
> But that means my code is stuck on Rust 2015. ...can't you upgrade and choose not to make that change? Did something happen to make that not compile? (not a Rust user)
- boardwaalk 7y ago
  It looks like they might need to use "r#try!(...)" in Rust 2018 (a trivial search replace, 'cargo fix' might do it too, not sure), but the macro is still available: https://doc.rust-lang.org/stable/std/macro.try.html https://doc.rust-lang.org/stable/std/macro.try.html It's trivial to implement yourself, too (if you, for example, wanted to give it a non-reserved name).
  - davidcuddeback 7y ago
    Thanks. Didn't know about the raw identifier syntax. That's kinda ugly, so I'd probably still go with copying it to all of my projects and giving it a new name if I were to update to Rust 2018.
    - alvarelle 7y ago
      On the other hand, you could argue that the r# gives you "more prominence" which is exactly the stated goal of using that macro.
- davidcuddeback 7y ago
  > Did something happen to make that not compile? `try` became a reserved keyword in Rust 2018 and the `try!()` macro was dropped (edit: not dropped, see @boardwaalk's comment). I could copy the old macro to all of my code bases and give it a new name. The two things stopping me from doing that are (1) I don't have any reason to update to Rust 2018, and (2) I can't think of a good name for a replacement macro. I'm thinking `check!()`, but not sold on the name. > (not a Rust user) One thing to know about Rust 2015 vs 2018 vs future "editions" is that they're a distinct versioning mechanism from Rust 1.23, 1.24, etc. The latest version of the Rust compiler still supports Rust 2015 and I believe it's been promised to be supported in perpetuity. So it's not like I run a risk of being without a Rust 2015 compiler available.
  - gpm 7y ago
    Just to expand on the editions things, editions are local to the crate. A Rust 2015 crate can freely use a Rust 2018 crate and the reverse. So davidcuddeback isn't being locked out of using up to date dependencies either.
  - majewsky 7y ago
    > I can't think of a good name for a replacement macro What about do_or_do_not!(). After all, there is no try!(). ;)
    - davidcuddeback 7y ago
      Heh. That's the argument that was made against using Rails' `try()` method at my last place of work. Made me laugh. Thanks. :)
deleted 7y ago
[deleted]
swalladge 7y ago
> If something I need is added to Rust 2018 or a later edition, I'll be forced to update or backport. Should add that new editions with breaking changes are only expected to happen rarely (iirc every 3 years), a large difference to 6 weeks.
fluffything 7y ago
> If something I need is added to Rust 2018 or a later edition Most new language getting added to Rust, are added to the Rust 2015 edition (e.g. NLL). If you need a language feature that is added to a later edition only (like the `try` keyword), that's because the feature is incompatible with code being used in earlier editions (which declared a macro with the keyword name). You can continue using the macro by just using raw-literal syntax.. but my old Rust code tends to "just work", so I don't really need to update it. My crates are also very small, so if I'd ever need an update, it wouldn't take too long - but haven't had to do that yet, so can't comment. I tend to write most of my new code on new crates, so I default them to whatever edition was the default when I create them, and never look back. I have lot of 2015 crates in my dependency tree, and that works just fine.

typon 7y ago

I think its implied that having idiomatic code is better than not having idiomatic code.

deleted 7y ago
[deleted]
justinclift 7y ago
Unless it wastes people's time every x weeks, just to update to the latest hmmm... "fashion trend" for no practical benefit? :)
- Ar-Curunir 7y ago
  And because that's not the case with Rust, there is no such problem =)
- jeffparsons 7y ago
  Even if you do believe that it's for "no practical benefit", the value of _x_ in Rust's case is ~156. (I.e. roughly once every three years, when a new "edition" is stabilized.) And the transition is mostly automated. Speaking as somebody who has maintained several medium sized Rust code bases over the years, I can comfortably say that it's not a big deal. What _has_ been a big deal, on the other hand, is getting excited about what I can do with extremely unstable libraries, and then spending a lot of time keeping up with their breaking changes. But I'd be a bit silly to complain about this; in each case, I opted in to an immature ecosystem very early on because I was excited about being part of its early growth. I don't expect to have my cake and eat it, too.

bosswipe 7y ago

If you don't update over time there's a danger that you won't be able to interoperate with other software, or you might not be able to take advantage of new features. It's easier to make small changes over time then trying to do a big bang upgrade with several years of changes.

anderskaseorg 7y ago
Rust 2015 and Rust 2018 have no trouble interoperating with each other in both directions. If you want to update, that's great, and there are automatic tools to help you, but you don't need to feel compelled to do it by the pace of language development.
- bluejekyll 7y ago
  Even with the Futures ecosystem having a massive change first with the std::future impls and then with async/await, there are backward compatible libraries that make it possible to inter-operate between the two. You probably don’t want to live like that forever, but it’s a way of not being “required” to upgrade large code bases.