5 ms·

> What i find annoying about Rust's changes is that some of them are so trivial - they change the language for such small improvements. async/await is not in th

by sgift 7y ago

> What i find annoying about Rust's changes is that some of them are so trivial - they change the language for such small improvements. async/await is not in that category, for sure. But Ok-wrapping actually is. The need to Ok-wrap results is a minor annoyance at most. Ditto a bunch of the problems solved by match ergonomics changes. So what? Then don't use them. The whole point of full backward compatibility is that you don't have to use new features. This perceived need to always use the newest feature is only in the head of some developers. Neither in the blog post nor here do I see any reason to not make the experience better for people who want it. Even if it's just a "minor" (very subjective, I love the match ergonomics enhancements) annoyance that's fixed by it.

jfkebwjsbx 7y ago
It is not fully backwards compatible between editions, though.
- sgift 7y ago
  Editions are opt in. You don't opt in, nothing changes for your code.
MaulingMonkey 7y ago
Agreed. I know plenty of codebases still written in C++03 style and work fine. I'm still using 2015 edition Rust crates and they work fine. I won't say there's no cost to evolving idioms, but evolving idioms on this front means it's more of an affront to asthetics than it is to productivity or anything else actually important to business goals, IMO. The one exception perhaps being async/await, in that a bunch of crates are making breaking API changes to accomidate it and bumping their major versions - because it's bloody useful and a bit more than your typical syntactic sugar - which means changing your code if you want to keep getting patches.
umanwizard 7y ago
I can’t force other people not to use changes, which means I will always need the latest version of rustc installed if I want to be able to build a relatively complete selection of the corpus of Rust code, which in turn makes it very difficult if not impossible for rust software to be distributed in typical OS package managers. I.e., imagine how Debian or Ubuntu could package things if the definition of C++ changed every six weeks, given that the compiler version should change as little as possible during a major OS version cycle? This is a major blocker holding Rust back from mainstream adoption, IMO.
- whatshisface 7y ago
  Can't package managers distribute binaries? Besides, maybe the fact that a package can fall three years behind the stable release is a problem with package management, not the stable release.
  - steveklabnik 7y ago
    They can, but Rust doesn't have a stable ABI, so that doesn't really work this way.
adrianN 7y ago
You still need to know about the feature and understand how it works or eventually you'll only understand your own code as everybody else is using stuff you haven't learned.
karatestomp 7y ago
You still have to understand all the new stuff to read other people’s code. And the old way, so you can read older code. And if there are other ways to do something that are or have recently been in common use, those too. You end up memorizing a bunch of crap for one actual operation.
- jrochkind1 7y ago
  Yep. I think ruby (which in general I still love) has become a major offender of this. "If you don't like it don't use it" is not a good answer for exactly the reasons you explain.
  - sgift 7y ago
    I sense a goalpost moving here. The point of the blog post to which I answered to was: I have to redo all my programs to follow the "idiomatic" way. Now we are at "other programmers could use new features, so I still have to learn them". And yes, that is true. And that will always be true as long as a language has new releases. Even if all those releases were library changes and not syntax changes/additions. The only way to stop this would be to stop all language development.
    - setr 7y ago
      Even worse would be if someone pulled in a library... That requires much more cognitive load and doc-reading than something like try! -> ? Or the worst of all possible worlds -- pulling in a macro-based framework
- silon42 7y ago
  But you don't have to change your code unless it's an improvement to you. Somebody else may do it if they care, and you may accept OR reject the PR with no bad feelings.
travellingprog 7y ago
From my experience of trying to learn Rust (got almost halfway through the manual and then put it on hold), I would add that having all these ways of doing the same thing is also confusing from a beginner's perspective. As a noob, I have no idea what the timeline is of when feature A was introduced that does the same thing as feature B. Also, I kept having to dig around to see if feature A added any type of improvements (other than syntactic sugar) over feature B.
- pornel 7y ago
  • try!() has been replaced by ?. You don't even need to know — the compiler will tell you. • futures 0.1 has been replaced with std::futures. This is it. This is the exhaustive list of A->B feature changes in the last 42 releases of Rust. Now you know them all. Rust is aggressive with keeping everyone using the current stable release. In C++ you may need to keep track of feature history to know if something is too new or too old for your compiler/project. There's no such thing in Rust. If you know a feature exists, you can use it.

by sgift 7y ago

jfkebwjsbx 7y ago

It is not fully backwards compatible between editions, though.

sgift 7y ago
Editions are opt in. You don't opt in, nothing changes for your code.

MaulingMonkey 7y ago

Agreed. I know plenty of codebases still written in C++03 style and work fine. I'm still using 2015 edition Rust crates and they work fine. I won't say there's no cost to evolving idioms, but evolving idioms on this front means it's more of an affront to asthetics than it is to productivity or anything else actually important to business goals, IMO. The one exception perhaps being async/await, in that a bunch of crates are making breaking API changes to accomidate it and bumping their major versions - because it's bloody useful and a bit more than your typical syntactic sugar - which means changing your code if you want to keep getting patches.

umanwizard 7y ago

I can’t force other people not to use changes, which means I will always need the latest version of rustc installed if I want to be able to build a relatively complete selection of the corpus of Rust code, which in turn makes it very difficult if not impossible for rust software to be distributed in typical OS package managers. I.e., imagine how Debian or Ubuntu could package things if the definition of C++ changed every six weeks, given that the compiler version should change as little as possible during a major OS version cycle? This is a major blocker holding Rust back from mainstream adoption, IMO.

whatshisface 7y ago
Can't package managers distribute binaries? Besides, maybe the fact that a package can fall three years behind the stable release is a problem with package management, not the stable release.
- steveklabnik 7y ago
  They can, but Rust doesn't have a stable ABI, so that doesn't really work this way.

adrianN 7y ago

You still need to know about the feature and understand how it works or eventually you'll only understand your own code as everybody else is using stuff you haven't learned.

karatestomp 7y ago

You still have to understand all the new stuff to read other people’s code. And the old way, so you can read older code. And if there are other ways to do something that are or have recently been in common use, those too. You end up memorizing a bunch of crap for one actual operation.

jrochkind1 7y ago
Yep. I think ruby (which in general I still love) has become a major offender of this. "If you don't like it don't use it" is not a good answer for exactly the reasons you explain.
- sgift 7y ago
  I sense a goalpost moving here. The point of the blog post to which I answered to was: I have to redo all my programs to follow the "idiomatic" way. Now we are at "other programmers could use new features, so I still have to learn them". And yes, that is true. And that will always be true as long as a language has new releases. Even if all those releases were library changes and not syntax changes/additions. The only way to stop this would be to stop all language development.
  - setr 7y ago
    Even worse would be if someone pulled in a library... That requires much more cognitive load and doc-reading than something like try! -> ? Or the worst of all possible worlds -- pulling in a macro-based framework
silon42 7y ago
But you don't have to change your code unless it's an improvement to you. Somebody else may do it if they care, and you may accept OR reject the PR with no bad feelings.

travellingprog 7y ago

From my experience of trying to learn Rust (got almost halfway through the manual and then put it on hold), I would add that having all these ways of doing the same thing is also confusing from a beginner's perspective. As a noob, I have no idea what the timeline is of when feature A was introduced that does the same thing as feature B. Also, I kept having to dig around to see if feature A added any type of improvements (other than syntactic sugar) over feature B.

pornel 7y ago
• try!() has been replaced by ?. You don't even need to know — the compiler will tell you. • futures 0.1 has been replaced with std::futures. This is it. This is the exhaustive list of A->B feature changes in the last 42 releases of Rust. Now you know them all. Rust is aggressive with keeping everyone using the current stable release. In C++ you may need to keep track of feature history to know if something is too new or too old for your compiler/project. There's no such thing in Rust. If you know a feature exists, you can use it.