7 ms·

For those that assert Rust changes too much, I would submit the simple question "Why?" to them. "Too much" seems to imply that the language breaks their code to

by chungy 7y ago

For those that assert Rust changes too much, I would submit the simple question "Why?" to them. "Too much" seems to imply that the language breaks their code too often to make it worthwhile writing software, though this has been a thing Rust explicitly avoids since 1.0 happened. Rust 2018 took some liberties at breaking old code, but it only really matters if you explicitly upgrade to 2018, at which point you've already committed yourself to making potentially-significant changes. I imagine a future "big change" like Rust 2021 or whatever would do the same; I likewise hope that all N editions can interoperate no matter how many N editions exist. > However, maybe there’s a better way to surface “these are big changes” vs “this is a small thing,” or something like that. I’m not sure. It might be as hard, or even harder, to quantify this than even deciding what gets put into the release notes. What might be a big change for one person is absolutely insignificant for another, and vice-versa.

steveklabnik 7y ago
Every edition will interoperate the same as 2015 and 2018 do, this is a hard constraint of editions. We technically have not yet decided if there will be a Rust 2021. I think there should be, but it should be smaller than 2018.
- chungy 7y ago
  > this is a hard constraint of editions. That's pretty awesome! Should I assume this only applies if a "Rust 2.0" never happens, or is there a commitment to 2.0 never being a thing?
  - bluejekyll 7y ago
    At this point, what would a 2.0 be exactly? I guess dropping 2015 as a supported source edition?
  - steveklabnik 7y ago
    We have said there won't be a Rust 2.0. If course, in theory we could change our minds. Can't imagine a current scenario where it makes sense, though.
    - worik 7y ago
      It would make sense if Rust 2.0 was smaller and less capable. Every improvement added to rust makes it worse for me
dralley 7y ago
This is where I'm at. There is no need to read every new release notes and change your code every 6 weeks to use all the new features. It's a self-imposed mental overhead, not one which the language forces you to deal with. There's nothing wrong with simply reading the "edition guide" every couple of years and using the automated tooling to perform 90% of the minor adjustments that you otherwise would have had to perform manually. "cargo fix --edition-idioms" will perform many such adjustments for you. https://doc.rust-lang.org/edition-guide/editions/transitioning-an-existing-project-to-a-new-edition.html#writing-idiomatic-code-in-a-new-edition https://doc.rust-lang.org/edition-guide/editions/transitioni...
- wyldfire 7y ago
  Wow, that's a super cool feature. Didn't know it existed.
lumost 7y ago
The big challenge is in the open source libraries and code samples that most developers rely on every day. If the core syntax of the language changes faster than that corpus is updated it can make it difficult to learn and apply the language.
- steveklabnik 7y ago
  Yep! I have a line about this in the "future work" section; I think it's a really important question. I have not come up with a methodology to measure it though.
pritambarhate 7y ago
>> but it only really matters if you explicitly upgrade to 2018 This is OK for programmers who already know Rust. But for new programmers coming to the language, it presents a very difficult challenge. To give one anecdote, I was trying out Rust a few days ago. Just baby steps. I wanted to read a file. But since the try! the macro syntax is changed, almost every example I could find on the Internet was broken. Took me almost an hour to figure out what was going on. (I have programmed professionally for more than 10 years in Java, JS, Objective-C, PHP, Python and Go) Lost the interest to pursue it further. Another time, I thought I would read some small projects in Rust from Github to improve my understanding of Rust. I wanted to checkout "programs" and not libraries. So I went on exploring Rust projects on Github and tried out 2-3 smallish programs. But because of Rust version incompatibilities, I was not able to get them to build and run. Now I accept, if I had been dogged enough, maybe I could have found out the exact version of Rust required for the programs. But it was too much work for a weekend afternoon where I just wanted to learn something new in 2-3 hours. Rust community and senior Rust programmers might not accept this, but the Rust ecosystem has instability issues from a NewBie perspective. Edit: Sorry the problem I was facing about was related to writing a file and "unwrap" and "?" syntax. Not the try! macro syntax. (I think that surfaced some other time.) I just checked my example after posting this comment. But still keeping the comment here as it shows struggle a Rust noob faces while learning the language.
- ChrisSD 7y ago
  > I wanted to read a file. It's probably too late to help now but I recommend the official documentation[0] and book[1]. They both have examples. [0]: https://doc.rust-lang.org/std/fs/struct.File.html https://doc.rust-lang.org/std/fs/struct.File.html [1]: https://doc.rust-lang.org/stable/book/ch12-02-reading-a-file.html https://doc.rust-lang.org/stable/book/ch12-02-reading-a-file...
- dralley 7y ago
  I'm not saying your experience is invalid, but the first 5 google results I get for "read a file Rust" all return working code (I didn't look beyond the first 5).
- lordCarbonFiber 7y ago
jeffrallen 7y ago
It changes so fast that once you learn it, and then download a dependency, then look inside it to fix a bug, you discover that there's whole new syntaxes you never saw before. Or you want to use a dependency but can't because it uses nightly and you don't. Or it uses a different flavor of async io than your http client does, or, or, or etc. Rust is a toy for elite home code poets. And what beautiful things they craft! Those of us who are paid to program don't have the luxury of playing with it on work time.
- hermanradtke 7y ago
  Mozilla, Dropbox, Google, Microsoft, Buoyant and a lot of other companies empirically disagree that “Rust is toy for elite home code poets”.
  - bluejekyll 7y ago
    Amazon also has a substantial VM system in production. It looks like we can probably start adding Apple to that list as well.
    - FridgeSeal 7y ago
      Ooohh what is Apple doing with Rust?
      - steveklabnik 7y ago
        https://mobile.twitter.com/benwilliamson/status/1240113606374686721 https://mobile.twitter.com/benwilliamson/status/124011360637...
        FridgeSeal 7y ago
        Ooohh that’s so cool!
- worik 7y ago
  "you discover that there's whole new syntaxes you never saw before" That is the problem I have too.
epage 7y ago
> For those that assert Rust changes too much, I would submit the simple question "Why?" to them. There was a blog post a couple days ago that made the complaint. Not linking because even the author felt it was too easily misread. From my understanding, the crux of the complaint was that it is hard to "keep up" with Rust. I think the idea is similar to the complaints made here about Javascript frameworks and friends. This is where the current blog post comes in, trying to quantify things to see how much justification there is to the complaint. Personally, I don't think Rust is changing too much but it can easily be perceived that way and we can do stuff to help that perception. One goal of Editions was to provide a rolled up release announcement to catch everyone up. The current blog post calls out how feature announcements are different between releases and editions. So I feel there is something we can be doing better about Editions. Maybe we should always schedule them, even if there are divides where code breaks. This would build trust in the wider community that if they don't need something specific, they can watch the Edition releases from a distance. Another thought I had is that we can do a better job classifying changes. The current post talks about major, medium, and minor. My framing is from C++: pervasive vs library features. Right or wrong, some complain about complex C++ features and it gets excused as a feature the average developer can ignore because it is more targeted at the type of people who write boost libraries. We can be a lot clearer in the Rust community with what role a feature fills. Is it for a niche? What niche? How do we let people know if they should care or not?
- steveklabnik 7y ago
  So to be clear, I wanted to write this post for a long time. That post did spur me to finally write this, but it is not intended to be a “rebuttal.” I don’t think you can rebut subjective experience. This is an attempt to figure out why that experience was had. I suspect that library and ecosystem breakage contributes to this feeling much more than the core distribution, so this is the first step towards that. I don’t yet have a methodology to quantify ecosystem breakage...
- lumost 7y ago
  It could be an artifact of my interest areas, but all of the code I've worked on in rust and their dependent libs only work on rust nightly. The rust feature areas that I run into are - Function/closure serde - Futures/Async - WASM I'd be curious if part of the instability complaint is related to a problem of averages, the "average" program shouldn't be experiencing much change - but the average developer spends most of their time writing a non-average program, and will run into a stability issue related to some library/language feature.
twic 7y ago
> "Why?" Because the rate of change exceeds the community's rate of making good decisions. Letting things bake for 2-3 times longer would lead to better designs.
- steveklabnik 7y ago
  Do you have specific things in mind? I think stuff bakes a lot longer than you may think, but that’s just a hunch! It also might mean we think of “baked” in a different way.
- Ar-Curunir 7y ago
  Stuff bakes in nightly for ages, often to the frustration of people like me that want to use cutting-edge features like more expressive `const fn`s =P
- dralley 7y ago
  Most significant changes to the language "baked" for more than a year, usually 2+ years.
- iknowstuff 7y ago
  Oh boy. The author of this post gave a speech about Rust’s journey to async/await: https://m.youtube.com/watch?v=lJ3NC-R3gSI https://m.youtube.com/watch?v=lJ3NC-R3gSI I highly recommend you skim it. It will show you how meticulous the core team is and how long it took to arrive at this incredible, best in class design.
rrobukef 7y 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. 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 7y 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 7y 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 7y 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 7y 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 :/

by chungy 7y ago

steveklabnik 7y ago

Every edition will interoperate the same as 2015 and 2018 do, this is a hard constraint of editions. We technically have not yet decided if there will be a Rust 2021. I think there should be, but it should be smaller than 2018.

chungy 7y ago
> this is a hard constraint of editions. That's pretty awesome! Should I assume this only applies if a "Rust 2.0" never happens, or is there a commitment to 2.0 never being a thing?
- bluejekyll 7y ago
  At this point, what would a 2.0 be exactly? I guess dropping 2015 as a supported source edition?
- steveklabnik 7y ago
  We have said there won't be a Rust 2.0. If course, in theory we could change our minds. Can't imagine a current scenario where it makes sense, though.
  - worik 7y ago
    It would make sense if Rust 2.0 was smaller and less capable. Every improvement added to rust makes it worse for me

dralley 7y ago

This is where I'm at. There is no need to read every new release notes and change your code every 6 weeks to use all the new features. It's a self-imposed mental overhead, not one which the language forces you to deal with. There's nothing wrong with simply reading the "edition guide" every couple of years and using the automated tooling to perform 90% of the minor adjustments that you otherwise would have had to perform manually. "cargo fix --edition-idioms" will perform many such adjustments for you. https://doc.rust-lang.org/edition-guide/editions/transitioning-an-existing-project-to-a-new-edition.html#writing-idiomatic-code-in-a-new-edition https://doc.rust-lang.org/edition-guide/editions/transitioni...

wyldfire 7y ago
Wow, that's a super cool feature. Didn't know it existed.

lumost 7y ago

The big challenge is in the open source libraries and code samples that most developers rely on every day. If the core syntax of the language changes faster than that corpus is updated it can make it difficult to learn and apply the language.

steveklabnik 7y ago
Yep! I have a line about this in the "future work" section; I think it's a really important question. I have not come up with a methodology to measure it though.

pritambarhate 7y ago

>> but it only really matters if you explicitly upgrade to 2018 This is OK for programmers who already know Rust. But for new programmers coming to the language, it presents a very difficult challenge. To give one anecdote, I was trying out Rust a few days ago. Just baby steps. I wanted to read a file. But since the try! the macro syntax is changed, almost every example I could find on the Internet was broken. Took me almost an hour to figure out what was going on. (I have programmed professionally for more than 10 years in Java, JS, Objective-C, PHP, Python and Go) Lost the interest to pursue it further. Another time, I thought I would read some small projects in Rust from Github to improve my understanding of Rust. I wanted to checkout "programs" and not libraries. So I went on exploring Rust projects on Github and tried out 2-3 smallish programs. But because of Rust version incompatibilities, I was not able to get them to build and run. Now I accept, if I had been dogged enough, maybe I could have found out the exact version of Rust required for the programs. But it was too much work for a weekend afternoon where I just wanted to learn something new in 2-3 hours. Rust community and senior Rust programmers might not accept this, but the Rust ecosystem has instability issues from a NewBie perspective. Edit: Sorry the problem I was facing about was related to writing a file and "unwrap" and "?" syntax. Not the try! macro syntax. (I think that surfaced some other time.) I just checked my example after posting this comment. But still keeping the comment here as it shows struggle a Rust noob faces while learning the language.

ChrisSD 7y ago
> I wanted to read a file. It's probably too late to help now but I recommend the official documentation[0] and book[1]. They both have examples. [0]: https://doc.rust-lang.org/std/fs/struct.File.html https://doc.rust-lang.org/std/fs/struct.File.html [1]: https://doc.rust-lang.org/stable/book/ch12-02-reading-a-file.html https://doc.rust-lang.org/stable/book/ch12-02-reading-a-file...
dralley 7y ago
I'm not saying your experience is invalid, but the first 5 google results I get for "read a file Rust" all return working code (I didn't look beyond the first 5).
lordCarbonFiber 7y ago

jeffrallen 7y ago

It changes so fast that once you learn it, and then download a dependency, then look inside it to fix a bug, you discover that there's whole new syntaxes you never saw before. Or you want to use a dependency but can't because it uses nightly and you don't. Or it uses a different flavor of async io than your http client does, or, or, or etc. Rust is a toy for elite home code poets. And what beautiful things they craft! Those of us who are paid to program don't have the luxury of playing with it on work time.

hermanradtke 7y ago
Mozilla, Dropbox, Google, Microsoft, Buoyant and a lot of other companies empirically disagree that “Rust is toy for elite home code poets”.
- bluejekyll 7y ago
  Amazon also has a substantial VM system in production. It looks like we can probably start adding Apple to that list as well.
  - FridgeSeal 7y ago
    Ooohh what is Apple doing with Rust?
    - steveklabnik 7y ago
      https://mobile.twitter.com/benwilliamson/status/1240113606374686721 https://mobile.twitter.com/benwilliamson/status/124011360637...
      - FridgeSeal 7y ago
        Ooohh that’s so cool!
worik 7y ago
"you discover that there's whole new syntaxes you never saw before" That is the problem I have too.

epage 7y ago

> For those that assert Rust changes too much, I would submit the simple question "Why?" to them. There was a blog post a couple days ago that made the complaint. Not linking because even the author felt it was too easily misread. From my understanding, the crux of the complaint was that it is hard to "keep up" with Rust. I think the idea is similar to the complaints made here about Javascript frameworks and friends. This is where the current blog post comes in, trying to quantify things to see how much justification there is to the complaint. Personally, I don't think Rust is changing too much but it can easily be perceived that way and we can do stuff to help that perception. One goal of Editions was to provide a rolled up release announcement to catch everyone up. The current blog post calls out how feature announcements are different between releases and editions. So I feel there is something we can be doing better about Editions. Maybe we should always schedule them, even if there are divides where code breaks. This would build trust in the wider community that if they don't need something specific, they can watch the Edition releases from a distance. Another thought I had is that we can do a better job classifying changes. The current post talks about major, medium, and minor. My framing is from C++: pervasive vs library features. Right or wrong, some complain about complex C++ features and it gets excused as a feature the average developer can ignore because it is more targeted at the type of people who write boost libraries. We can be a lot clearer in the Rust community with what role a feature fills. Is it for a niche? What niche? How do we let people know if they should care or not?

steveklabnik 7y ago
So to be clear, I wanted to write this post for a long time. That post did spur me to finally write this, but it is not intended to be a “rebuttal.” I don’t think you can rebut subjective experience. This is an attempt to figure out why that experience was had. I suspect that library and ecosystem breakage contributes to this feeling much more than the core distribution, so this is the first step towards that. I don’t yet have a methodology to quantify ecosystem breakage...
lumost 7y ago
It could be an artifact of my interest areas, but all of the code I've worked on in rust and their dependent libs only work on rust nightly. The rust feature areas that I run into are - Function/closure serde - Futures/Async - WASM I'd be curious if part of the instability complaint is related to a problem of averages, the "average" program shouldn't be experiencing much change - but the average developer spends most of their time writing a non-average program, and will run into a stability issue related to some library/language feature.

twic 7y ago

> "Why?" Because the rate of change exceeds the community's rate of making good decisions. Letting things bake for 2-3 times longer would lead to better designs.

steveklabnik 7y ago
Do you have specific things in mind? I think stuff bakes a lot longer than you may think, but that’s just a hunch! It also might mean we think of “baked” in a different way.
Ar-Curunir 7y ago
Stuff bakes in nightly for ages, often to the frustration of people like me that want to use cutting-edge features like more expressive `const fn`s =P
dralley 7y ago
Most significant changes to the language "baked" for more than a year, usually 2+ years.
iknowstuff 7y ago
Oh boy. The author of this post gave a speech about Rust’s journey to async/await: https://m.youtube.com/watch?v=lJ3NC-R3gSI https://m.youtube.com/watch?v=lJ3NC-R3gSI I highly recommend you skim it. It will show you how meticulous the core team is and how long it took to arrive at this incredible, best in class design.

rrobukef 7y 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. 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 7y 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 7y 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 7y 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 7y 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 :/