4 ms·

No, it's nothing like C++. The only recent big change was async but how many other things have changed?

by adamnemecek 7y ago

jfkebwjsbx 7y ago
Almost the entire language since its early days. And there have been 2 major editions in the last 5 years.
- bschwindHN 7y ago
  I would only count language changes since its 1.0 release, there really haven't been that many.
  - jfkebwjsbx 7y ago
    That's fair, then 1 major edition. There have been a lot of added features, though. I am not sure why people downvoted me.
    - kibwen 7y ago
      In the parlance of the Rust developers, a "feature" is often just the addition of a single function to the standard library. The only remotely paradigm-shifting feature to be added since 1.0 was async/await; the other things mentioned in the blog post are minor QOL nice-to-haves.
- gamegoblin 7y ago
  I don't think it's really fair to talk about pre-1.0 language changes -- by definition, being pre-1.0 typically implies a lack of stability. One of the major editions you mention is the 1.0 release. So, there has been 1 new edition since 1.0, and, as the parent comment says, the only really groundbreaking change since 1.0 is the stabilization of async support. Other changes, such as the `dyn` keyword and match ergonomics are mostly superficial, and things such as NLL and additional lifetime elisions are just simple quality of life improvements that don't fundamentally change the language.
  - geofft 7y ago
    Not only is it unfair, it's counterproductive - the lesson future languages will learn is to not work in public and to not improve. Rust pre-1.0 was a mess and nobody would have been better off if it had gotten frozen with all the not-so-great stuff officially supported.
- iknowstuff 7y ago
  You mean pre-1.0. There has been one major edition afterwards, Rust 2018, which is optional but has awesome new features like non-lexical lifetimes, async/await keywords and I guess `dyn`.
- ekidd 7y ago
  I've been writing Rust since before 1.0, and I maintain at least once piece of 5-year-old production Rust code. In general, old Rust code continues to work almost completely unchanged. There have been 3 or 4 cases where I couldn't compile an ancient dependency because it was relying on something weird like a soundness bug. The fix was usually to update the dependency to the latest minor revision. Rust 2018 fixed a few minor syntactic issues, adding the "crate" keyword for imports from the current crate, and "dyn" in front of dynamically dispatched traits. These can both be updated using 'cargo fix' in about 20 minutes. Rust 2018 modules can use Rust 2015 modules almost completely seemlessly, even when macros are involved. Is it perfect? No. But updating older code is something I spend a day or two a year on.
  - jfkebwjsbx 7y ago
    That is fine, but note that 2 days a year is about 1% of work time, and that time increases as the code size increases. Moreover, in some companies you cannot simply update external dependencies without extra painful reviews.
- kccqzy 7y ago
  If by "its early days" you want to talk about pre-1.0 Rust, then I think a fair comparison is pre-C++98 C++, from the original Cfront. At that time C++ was just C with classes. It didn't have templates, namespaces, and plenty of other indispensable features in modern C++.
- artursapek 7y ago
  Bryan Cantrill's talk about Rust addresses when they removed green threads, and how much of a bold, disruptive change that was. He remarks on how that impressed him with the Rust community and made him follow the language more closely - had they been too scared to change the language in drastic ways, we would still be stuck with green threads. Sorry, I can't remember the timestamp right now but the entire thing is worth a listen: https://www.youtube.com/watch?v=LjFM8vw3pbU https://www.youtube.com/watch?v=LjFM8vw3pbU
  - steveklabnik 7y ago
    And to be clear, this was before 1.0; we cannot do this kind of thing these days.
ajross 7y ago
The linked article is literally a list of things that are changing too rapidly in Rust to keep up with. Maybe those don't qualify as "big" changes, but then most of C++'s evolution was an aggregation of features that were in isolation fairly small and focused.
- steveklabnik 7y ago
  The changes: * .await. This feature was in development for almost five years. Landed November 2019. This is a legit new feature, with significant ramifications on the language. * try!() -> ? . This feature was in development for two years, and landed in November 2016. This largely consists of the transformation "try!(x)" to "x?". * impl trait: this feature was in development for two years, and landed in May of 2018. This has two major parts: one that is very rarely used that is mostly sugar, and another that's pretty useful, and is a legit new feature. * dyn: this feature was in development for two years, and landed in June of 2018. This is largely optionally adding `dyn` in some places. You don't have to do this. You can turn a lint on that will tell you exactly where to do this, and it can be automatically added to your code. So that's four features. One of them three years ago, two two years ago, and one last year.
  - DeathArrow 7y ago
    That's awful hard. People have to learn an entire new feature each year? :D I don't get why people complain. C# is pumping features at a much higher rate and most people are glad. Those features do solve some issues or make it easier to solve them. If you don't have an use case for them, then you don't need to learn them.
  - ajross 7y ago
    Sure, but if you list out C++'s warts, you'll find a much longer list spread out over 30 years. The same effect holds, no?
    - steveklabnik 7y ago
      I mostly wrote C++98, or at least, C++ of that vintage, so I can't really speak to how hard it is to keep up with later C++ standards. Just providing more context for those specific list of changes, and their frequency.

No, it's nothing like C++. The only recent big change was async but how many other things have changed?

jfkebwjsbx 7y ago

Almost the entire language since its early days. And there have been 2 major editions in the last 5 years.

bschwindHN 7y ago
I would only count language changes since its 1.0 release, there really haven't been that many.
- jfkebwjsbx 7y ago
  That's fair, then 1 major edition. There have been a lot of added features, though. I am not sure why people downvoted me.
  - kibwen 7y ago
    In the parlance of the Rust developers, a "feature" is often just the addition of a single function to the standard library. The only remotely paradigm-shifting feature to be added since 1.0 was async/await; the other things mentioned in the blog post are minor QOL nice-to-haves.
gamegoblin 7y ago
I don't think it's really fair to talk about pre-1.0 language changes -- by definition, being pre-1.0 typically implies a lack of stability. One of the major editions you mention is the 1.0 release. So, there has been 1 new edition since 1.0, and, as the parent comment says, the only really groundbreaking change since 1.0 is the stabilization of async support. Other changes, such as the `dyn` keyword and match ergonomics are mostly superficial, and things such as NLL and additional lifetime elisions are just simple quality of life improvements that don't fundamentally change the language.
- geofft 7y ago
  Not only is it unfair, it's counterproductive - the lesson future languages will learn is to not work in public and to not improve. Rust pre-1.0 was a mess and nobody would have been better off if it had gotten frozen with all the not-so-great stuff officially supported.
iknowstuff 7y ago
You mean pre-1.0. There has been one major edition afterwards, Rust 2018, which is optional but has awesome new features like non-lexical lifetimes, async/await keywords and I guess `dyn`.
ekidd 7y ago
I've been writing Rust since before 1.0, and I maintain at least once piece of 5-year-old production Rust code. In general, old Rust code continues to work almost completely unchanged. There have been 3 or 4 cases where I couldn't compile an ancient dependency because it was relying on something weird like a soundness bug. The fix was usually to update the dependency to the latest minor revision. Rust 2018 fixed a few minor syntactic issues, adding the "crate" keyword for imports from the current crate, and "dyn" in front of dynamically dispatched traits. These can both be updated using 'cargo fix' in about 20 minutes. Rust 2018 modules can use Rust 2015 modules almost completely seemlessly, even when macros are involved. Is it perfect? No. But updating older code is something I spend a day or two a year on.
- jfkebwjsbx 7y ago
  That is fine, but note that 2 days a year is about 1% of work time, and that time increases as the code size increases. Moreover, in some companies you cannot simply update external dependencies without extra painful reviews.
kccqzy 7y ago
If by "its early days" you want to talk about pre-1.0 Rust, then I think a fair comparison is pre-C++98 C++, from the original Cfront. At that time C++ was just C with classes. It didn't have templates, namespaces, and plenty of other indispensable features in modern C++.
artursapek 7y ago
Bryan Cantrill's talk about Rust addresses when they removed green threads, and how much of a bold, disruptive change that was. He remarks on how that impressed him with the Rust community and made him follow the language more closely - had they been too scared to change the language in drastic ways, we would still be stuck with green threads. Sorry, I can't remember the timestamp right now but the entire thing is worth a listen: https://www.youtube.com/watch?v=LjFM8vw3pbU https://www.youtube.com/watch?v=LjFM8vw3pbU
- steveklabnik 7y ago
  And to be clear, this was before 1.0; we cannot do this kind of thing these days.

ajross 7y ago

The linked article is literally a list of things that are changing too rapidly in Rust to keep up with. Maybe those don't qualify as "big" changes, but then most of C++'s evolution was an aggregation of features that were in isolation fairly small and focused.

steveklabnik 7y ago
The changes: * .await. This feature was in development for almost five years. Landed November 2019. This is a legit new feature, with significant ramifications on the language. * try!() -> ? . This feature was in development for two years, and landed in November 2016. This largely consists of the transformation "try!(x)" to "x?". * impl trait: this feature was in development for two years, and landed in May of 2018. This has two major parts: one that is very rarely used that is mostly sugar, and another that's pretty useful, and is a legit new feature. * dyn: this feature was in development for two years, and landed in June of 2018. This is largely optionally adding `dyn` in some places. You don't have to do this. You can turn a lint on that will tell you exactly where to do this, and it can be automatically added to your code. So that's four features. One of them three years ago, two two years ago, and one last year.
- DeathArrow 7y ago
  That's awful hard. People have to learn an entire new feature each year? :D I don't get why people complain. C# is pumping features at a much higher rate and most people are glad. Those features do solve some issues or make it easier to solve them. If you don't have an use case for them, then you don't need to learn them.
- ajross 7y ago
  Sure, but if you list out C++'s warts, you'll find a much longer list spread out over 30 years. The same effect holds, no?
  - steveklabnik 7y ago
    I mostly wrote C++98, or at least, C++ of that vintage, so I can't really speak to how hard it is to keep up with later C++ standards. Just providing more context for those specific list of changes, and their frequency.