6 ms·

I feel that the changes to date haven't been that significant. Adding `dyn` was almost completely automated, removing the need for `extern crate` was welcome an

by roca 7y ago

I feel that the changes to date haven't been that significant. Adding `dyn` was almost completely automated, removing the need for `extern crate` was welcome and very easy to apply, likewise `try!()` to `?`. The changes to futures were a bit of a pain but futures were always known to be in flux. `impl Trait` is useful but failing to use it where you could is not ugly enough to irritate. There are some upcoming improvements --- that I'd like to see! --- that are bigger and thus may be more challenging: -- Better `const fn` will make many existing `lazy_static`s become unidiomatic. Worth it, but annoying. -- Const generics will make a lot of existing code non-idiomatic. Again, well worth it, but annoying. -- Generic Associated Types ... probably similar. The question is, if people decided those important features don't belong in Rust because they would cause too much churn in code that wants to be idiomatic ... then what? That would almost guarantee a new language --- perhaps a fork of Rust, perhaps not --- would eventually fill that niche. Wouldn't everyone be better off if that language was Rust itself, and people who don't want to write that "modern code" ... don't?

swalladge 7y ago
> Wouldn't everyone be better off if that language was Rust itself, and people who don't want to write that "modern code" ... don't? Agreed. The author's whole argument of not wanting "having to make these superficial changes again and again" doesn't make sense. There isn't any requirement for all code to follow the latest and greatest idioms. Rust guarantees backwards compatibility, and the author even acknowledges that in the article. It would be pretty sad if the reason for no new features or syntax in Rust was due to programmers not wanting to feel like their code was no longer idiomatic.
- sedatk 7y ago
  Wow, he said he got stuck with Rust 2015 and I thought Rust wasn’t keeping backwards compatibility, like earlier Swift. Not cool.
  - fluffything 7y ago
    I've been using Rust since 2015 and never had to update anything. The Rust "language version" is a per translation unit setting, and Rust supports having multiple library versions in a binary. So when I want to use a new language feature, or want to use a new library or library updated to use a new language feature, I just do so in the next translation unit I create. Creating a new translation unit always defaults it to the latest language version (unless you specify otherwise), so this is a quite laidback low-friction approach. I tend to create at least one translation unit per month. If I had to update all my code to use the latest language features I wouldn't be doing anything else full time. This has nothing to do with Rust. I also use C++, Javascript, ... I don't think I would manage.
- hinkley 7y ago
  I think it depends on whether you are working full time in Rust or as a hobbyist trying to break in. I gave up on EmberJS around the same time because I only got a five hour chunk of time every couple of weeks and they were making semantic changes so frequently then that it felt like I spent half of my time upgrading my code to work with the changes. It ended up being a major factor in killing that project for me and I’m just now getting back to it.
  - roca 7y ago
    Low-investment hobbyist Rust projects don't need to be idiomatic. Rust hasn't broken backwards compatibility except for a few soundness fixes that broke hardly anyone. It sounds like your EmberJS experience was pretty different.
lmm 7y ago
> The question is, if people decided those important features don't belong in Rust because they would cause too much churn in code that wants to be idiomatic ... then what? That would almost guarantee a new language --- perhaps a fork of Rust, perhaps not --- would eventually fill that niche. Wouldn't everyone be better off if that language was Rust itself, and people who don't want to write that "modern code" ... don't? A lot of these things feel like cases where Rust isn't really advancing the state of the art and could have just followed what existing languages do. Like, Rust takes some inspiration from OCaml, but OCaml already had good answers to these questions (railway-oriented-programming style composition for error handling, LWT for async, first-class modules for existentials). If Rust had been designed more wholeheartedly as "OCaml but replace garbage collection with a borrow checker", I think it would have got to a pretty similar place to where it is now (not in terms of the specific approaches, but in terms of how good the language is at solving those problems) more quickly and with less churn. Over the years I've concluded that the correct number of major innovations in a new language is one; Rust's is the borrow checker, so it really doesn't need to also try to reinvent error handling from the ground up. At a more specific level, if the language put more effort into making it easier to manipulate first-class functions (while handling ownership correctly) rather than language-level control flow keywords, then a lot of this churn could have happened "in userspace": different approaches to async or error handling would be library changes rather than language changes.
- fluffything 7y ago
  It took 20 years to get OCaml where it is. You can always wait another 20 years, and only start using Rust then. Otherwise, it seems to me that what you are asking is "Why didn't the Rust developers ship a 20 year old language on day 1?".
  - lmm 7y ago
    The way I see it, Rust's day-1 error handling story was significantly worse than that of most recent languages (e.g. Swift, Typescript, Kotlin, Dart, just going down Wikipedia's list of significant languages). And it's not clear what Rust gains from that - after a lot of a churn it's not come up with a significantly better error-handling paradigm than what was already out there. So it just feels like a waste.
CJefferson 7y ago
async is huge, and I'm worried about future similar changes. Suddenly "x.y" means member access.. except for x.await, which has a magic different meaning I still don't really understand. And adding 'await' to a function declaration magicly mangles it in various ways.
- hamaluik 7y ago
  If you’re interested, I found this blog post [1] a really solid introduction to what async / await are in Rust, and how they’re used. [1] https://os.phil-opp.com/async-await/ https://os.phil-opp.com/async-await/
- red75prime 7y ago
  You can always write `fn foo() -> impl Future` and mangle your code manually, using future combinators, though.
- roca 7y ago
  Honestly I haven't found those things to be problems at all. ".await" really isn't confusing. I think you meant "adding 'async'" to a function declaration --- it seems fine, but I personally don't use it.
  - CJefferson 7y ago
    The .await is another thing one needs to teach, and fairly early on so that people reading code examples don't get confused by where the "await" member of structures are. It just seems like a really bizarre break in what was fairly clean notation.
    - majewsky 7y ago
      For me, it helps that ".await" appears as a keyword because of syntax highlighting. It is an odd syntax, but the alternative way of making await a prefix operator instead of a postfix operator would have been way worse for readability. Compare let bar = list_foos().await.first().list_bars().await.first(); vs. let bar = (await (await list_foos()).first().list_bars()).first();
hinkley 7y ago
I missed it myself but have heard that people had to torture some of their code to deal with the object lifetime limitations in older versions. I’m sure that echoes of this still show up as quirkiness in various libraries.
mlindner 7y ago
They do belong in Rust, but they don't belong in a minor version release. There was Rust 2015, and then there was Rust 2018, we can put them in Rust 2021 (assuming 3 year cycle). Don't put major new forward compatibility breaking features in a minor release.
- roca 7y ago
  How would putting them in a new edition help in practice?

by roca 7y ago

swalladge 7y ago

> Wouldn't everyone be better off if that language was Rust itself, and people who don't want to write that "modern code" ... don't? Agreed. The author's whole argument of not wanting "having to make these superficial changes again and again" doesn't make sense. There isn't any requirement for all code to follow the latest and greatest idioms. Rust guarantees backwards compatibility, and the author even acknowledges that in the article. It would be pretty sad if the reason for no new features or syntax in Rust was due to programmers not wanting to feel like their code was no longer idiomatic.

sedatk 7y ago
Wow, he said he got stuck with Rust 2015 and I thought Rust wasn’t keeping backwards compatibility, like earlier Swift. Not cool.
- fluffything 7y ago
  I've been using Rust since 2015 and never had to update anything. The Rust "language version" is a per translation unit setting, and Rust supports having multiple library versions in a binary. So when I want to use a new language feature, or want to use a new library or library updated to use a new language feature, I just do so in the next translation unit I create. Creating a new translation unit always defaults it to the latest language version (unless you specify otherwise), so this is a quite laidback low-friction approach. I tend to create at least one translation unit per month. If I had to update all my code to use the latest language features I wouldn't be doing anything else full time. This has nothing to do with Rust. I also use C++, Javascript, ... I don't think I would manage.
hinkley 7y ago
I think it depends on whether you are working full time in Rust or as a hobbyist trying to break in. I gave up on EmberJS around the same time because I only got a five hour chunk of time every couple of weeks and they were making semantic changes so frequently then that it felt like I spent half of my time upgrading my code to work with the changes. It ended up being a major factor in killing that project for me and I’m just now getting back to it.
- roca 7y ago
  Low-investment hobbyist Rust projects don't need to be idiomatic. Rust hasn't broken backwards compatibility except for a few soundness fixes that broke hardly anyone. It sounds like your EmberJS experience was pretty different.

lmm 7y ago

> The question is, if people decided those important features don't belong in Rust because they would cause too much churn in code that wants to be idiomatic ... then what? That would almost guarantee a new language --- perhaps a fork of Rust, perhaps not --- would eventually fill that niche. Wouldn't everyone be better off if that language was Rust itself, and people who don't want to write that "modern code" ... don't? A lot of these things feel like cases where Rust isn't really advancing the state of the art and could have just followed what existing languages do. Like, Rust takes some inspiration from OCaml, but OCaml already had good answers to these questions (railway-oriented-programming style composition for error handling, LWT for async, first-class modules for existentials). If Rust had been designed more wholeheartedly as "OCaml but replace garbage collection with a borrow checker", I think it would have got to a pretty similar place to where it is now (not in terms of the specific approaches, but in terms of how good the language is at solving those problems) more quickly and with less churn. Over the years I've concluded that the correct number of major innovations in a new language is one; Rust's is the borrow checker, so it really doesn't need to also try to reinvent error handling from the ground up. At a more specific level, if the language put more effort into making it easier to manipulate first-class functions (while handling ownership correctly) rather than language-level control flow keywords, then a lot of this churn could have happened "in userspace": different approaches to async or error handling would be library changes rather than language changes.

fluffything 7y ago
It took 20 years to get OCaml where it is. You can always wait another 20 years, and only start using Rust then. Otherwise, it seems to me that what you are asking is "Why didn't the Rust developers ship a 20 year old language on day 1?".
- lmm 7y ago
  The way I see it, Rust's day-1 error handling story was significantly worse than that of most recent languages (e.g. Swift, Typescript, Kotlin, Dart, just going down Wikipedia's list of significant languages). And it's not clear what Rust gains from that - after a lot of a churn it's not come up with a significantly better error-handling paradigm than what was already out there. So it just feels like a waste.

CJefferson 7y ago

async is huge, and I'm worried about future similar changes. Suddenly "x.y" means member access.. except for x.await, which has a magic different meaning I still don't really understand. And adding 'await' to a function declaration magicly mangles it in various ways.

hamaluik 7y ago
If you’re interested, I found this blog post [1] a really solid introduction to what async / await are in Rust, and how they’re used. [1] https://os.phil-opp.com/async-await/ https://os.phil-opp.com/async-await/
red75prime 7y ago
You can always write `fn foo() -> impl Future` and mangle your code manually, using future combinators, though.
roca 7y ago
Honestly I haven't found those things to be problems at all. ".await" really isn't confusing. I think you meant "adding 'async'" to a function declaration --- it seems fine, but I personally don't use it.
- CJefferson 7y ago
  The .await is another thing one needs to teach, and fairly early on so that people reading code examples don't get confused by where the "await" member of structures are. It just seems like a really bizarre break in what was fairly clean notation.
  - majewsky 7y ago
    For me, it helps that ".await" appears as a keyword because of syntax highlighting. It is an odd syntax, but the alternative way of making await a prefix operator instead of a postfix operator would have been way worse for readability. Compare let bar = list_foos().await.first().list_bars().await.first(); vs. let bar = (await (await list_foos()).first().list_bars()).first();

hinkley 7y ago

I missed it myself but have heard that people had to torture some of their code to deal with the object lifetime limitations in older versions. I’m sure that echoes of this still show up as quirkiness in various libraries.

mlindner 7y ago

They do belong in Rust, but they don't belong in a minor version release. There was Rust 2015, and then there was Rust 2018, we can put them in Rust 2021 (assuming 3 year cycle). Don't put major new forward compatibility breaking features in a minor release.

roca 7y ago
How would putting them in a new edition help in practice?