5 ms·

> it's now slowly backfilling the missing features bit by bit This isn't slow. Java went three years, from December 1998 to February 2002, without any languag

by twic 7y ago

> it's now slowly backfilling the missing features bit by bit This isn't slow. Java went three years, from December 1998 to February 2002, without any language changes. And to be honest, even that wasn't that slow! > Every addition to the language is bikeshedded to death Not to death, because many of them don't die! 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. I think the root of the problem is that the changes are driven by a small core of Rust programmers - many working on Rust itself or some of its flagship projects - who are actively involved in the discussions around Rust. They tend to view change as natural, and the cost of change as low. I believe there is a larger group of Rust programmers who are not actively involved in these discussions, and are maybe not spending 100% of their time on Rust, for who the cost is higher. But we don't hear as much from them.

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.
ChrisSD 7y ago
`match` ergonomics don't affect already working code. Ok-wrapping isn't a change that's been made. At best it's a hypothetical change that one person wanted to have a calm, rational discussion about with the community. Instead we get this.
deleted 7y ago
[deleted]
hinkley 7y ago
> Java went three years, from December 1998 to February 2002 Oh hell no. Sun was widely criticized for that boneheaded move, and for the whiplash everyone experienced in Java 5 when they changed that policy too fast. The mass of changes in 5 left a lot of tools and thus people stuck in 1.4 for years. I started on a project a bit before 6 came out. It was processing data and I couldn’t use the collections API, because it had to run on an embedded system and Aicas was taking their sweet time catching up with all those changes. Four years later I was still using arrays for everything.
- lmilcin 7y ago
  One problem with not changing at all for a long time is that everybody forgets what it means to change. Teams stop planning for it, developers get too used for things being they way they got to know over the years. Then you get huge pills like Java 8 which took forever to be adopted in large corporations. I have witnessed most of Java history play out, starting with Java 1.3 in 2000. Looking back, I wish we had regular change cadence where new features are being slowly added at a regular pace so the versions don't feel like a completely new language and developers have time to digest the new possibilities. It is interesting when you spend multiple years on various projects, each being in a state of migrating from 1.6 to 8. Or coming to interviews and the first question being asked is "Which version of Java are you working on right now?".
- touisteur 7y ago
  Similar problem with Ada. 2012 standard came and for a long time only AdaCore supported it... Now going for 202x I'm thinking only advocating small changes that don't reduce ease of reading code...
rubber_duck 7y ago
> I believe there is a larger group of Rust programmers Is there ? This is a genuine question - I've tried rust back in 2013 and have been following it from the outside not using it for anything serious since I haven't had a use case. My impression is that it's still a niche language with and their user base seems to be very involved and engaged. It don't have the impression that there are a lot of companies that are "just doing their job with Rust and not making a lot of noise about it" - if a company is using Rust for something it's probably writing an engineering blogpost about it and the guy who spearheaded it is probably active within the community. I'm just basing this on the amount of Rust posts vs the amount of Rust use/job postings in those quiet, doing their thing companies.
- steveklabnik 7y ago
  https://news.ycombinator.com/item?id=22411324 https://news.ycombinator.com/item?id=22411324
  - rubber_duck 7y ago
    But that's my point - I knew about every one of those except discord just by following Rust marginally. Also Microsoft and Google etc. reported using it for various bits and peaces. My impression is that if a company does something in Rust there's going to be blogposts about it and the engineers involved are active community members. OP argued that there is a silent majority working along on Rust as is and getting caught unexpectedly with the changes - I'm just not seeing that.
    - twic 7y ago
      It's a legitimate question. I can't be sure there is such a silent majority. I do know there are a dozen people using Rust at my company, none well-known, and we haven't blogged about it or publicised it. > My impression is that if a company does something in Rust there's going to be blogposts about it and the engineers involved are active community members. You must recognise that this is pure availability bias, right?

by twic 7y ago

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.

ChrisSD 7y ago

`match` ergonomics don't affect already working code. Ok-wrapping isn't a change that's been made. At best it's a hypothetical change that one person wanted to have a calm, rational discussion about with the community. Instead we get this.

deleted 7y ago

[deleted]

hinkley 7y ago

> Java went three years, from December 1998 to February 2002 Oh hell no. Sun was widely criticized for that boneheaded move, and for the whiplash everyone experienced in Java 5 when they changed that policy too fast. The mass of changes in 5 left a lot of tools and thus people stuck in 1.4 for years. I started on a project a bit before 6 came out. It was processing data and I couldn’t use the collections API, because it had to run on an embedded system and Aicas was taking their sweet time catching up with all those changes. Four years later I was still using arrays for everything.

lmilcin 7y ago
One problem with not changing at all for a long time is that everybody forgets what it means to change. Teams stop planning for it, developers get too used for things being they way they got to know over the years. Then you get huge pills like Java 8 which took forever to be adopted in large corporations. I have witnessed most of Java history play out, starting with Java 1.3 in 2000. Looking back, I wish we had regular change cadence where new features are being slowly added at a regular pace so the versions don't feel like a completely new language and developers have time to digest the new possibilities. It is interesting when you spend multiple years on various projects, each being in a state of migrating from 1.6 to 8. Or coming to interviews and the first question being asked is "Which version of Java are you working on right now?".
touisteur 7y ago
Similar problem with Ada. 2012 standard came and for a long time only AdaCore supported it... Now going for 202x I'm thinking only advocating small changes that don't reduce ease of reading code...

rubber_duck 7y ago

> I believe there is a larger group of Rust programmers Is there ? This is a genuine question - I've tried rust back in 2013 and have been following it from the outside not using it for anything serious since I haven't had a use case. My impression is that it's still a niche language with and their user base seems to be very involved and engaged. It don't have the impression that there are a lot of companies that are "just doing their job with Rust and not making a lot of noise about it" - if a company is using Rust for something it's probably writing an engineering blogpost about it and the guy who spearheaded it is probably active within the community. I'm just basing this on the amount of Rust posts vs the amount of Rust use/job postings in those quiet, doing their thing companies.

steveklabnik 7y ago
https://news.ycombinator.com/item?id=22411324 https://news.ycombinator.com/item?id=22411324
- rubber_duck 7y ago
  But that's my point - I knew about every one of those except discord just by following Rust marginally. Also Microsoft and Google etc. reported using it for various bits and peaces. My impression is that if a company does something in Rust there's going to be blogposts about it and the engineers involved are active community members. OP argued that there is a silent majority working along on Rust as is and getting caught unexpectedly with the changes - I'm just not seeing that.
  - twic 7y ago
    It's a legitimate question. I can't be sure there is such a silent majority. I do know there are a dozen people using Rust at my company, none well-known, and we haven't blogged about it or publicised it. > My impression is that if a company does something in Rust there's going to be blogposts about it and the engineers involved are active community members. You must recognise that this is pure availability bias, right?