5 ms·

It seems weird to think that Rust is changing too much. It's a young language and has a lot of catching up to do to cover all the use cases it's intended for a

by wffurr 7y ago

It seems weird to think that Rust is changing too much. It's a young language and has a lot of catching up to do to cover all the use cases it's intended for and bring in all the niceties we expect out of modern multi-paradigm programming languages: procedural, functional, and object-oriented techniques. C++ is from 1985 and standardized in 1998, and it's still changing at a fast clip: C++11, C++17, Concepts will be a big deal when they happen in C++2?. Rust wasn't announced until 2010 and didn't ship 1.0 until 2015. It's only had 5 years to bake since 1.0, vs the 22 for C++.

kccqzy 7y ago
Concepts already happened. In C++20 released earlier this year.
masklinn 7y ago
> C++ is from 1985 and standardized in 1998, and it's still changing at a fast clip: C++11, C++17, Concepts will be a big deal when they happen in C++2?. C++ pretty much didn't change between 1998 and 2011 though (2003 was mostly a bugfix and compatibility release). And these days it updates every 3 years (you forgot C++14 though it was a very minor release) which is a much slower pace than Rust's 6 weeks cycle.
- wffurr 7y ago
  Major C++ releases and Rust Editions are both on three year cycles.
  - masklinn 7y ago
    AFAIK rust editions are not on any schedule currently, there's no guarantee that there'll be a Rust 2021 edition.
    - steveklabnik 7y ago
      Yes. We have not technically committed to a Rust 2021 yet. We are going to decide this year.
- ChrisSD 7y ago
  I don't think the 6 weeks vs. 3 years tells the full story. C++ collects up a whole truck load of changes and waits up to 3 years then dumps all of them in one go. Whereas Rust releases them individually, waiting up to six weeks after they've done baking in the nightly compiler (though they've likely been in development for years before that). That's not to say Rust is necessarily slower paced than C++ either, just that a raw number on release dates aren't helpful by themselves.
- iknowstuff 7y ago
  Yup. If you read the linked article, you’ll notice the release schedule was addressed by the author.
  - masklinn 7y ago
    That an article about Rust changes talk about Rust's schedules has nothing to do with comparisons between C++ and Rust.
mdasen 7y ago
That's certainly reasonable, but I think it seems harder to keep up with when people compare it to languages like Go (first appeared November 2009) and Kotlin (first appeared July 2011). Those languages both seem really easy to keep up with by comparison. Of course, both of those languages are going along much more well trodden paths. I think the "Rust is changing too much" feeling comes from people really wanting to use Rust because it has a cool new way of managing memory and zero-cost abstractions, but also feeling like it just keeps moving a little too much on them. Languages like Go and Kotlin just aren't moving much on them. I think that another part of that feeling comes from the fact that Rust has two different pieces: a) the new way of dealing with memory and abstraction; and b) the syntax, sugar, etc. If you're looking for "a", Rust is the only game in town there. You can't just decide that you need the memory lifetimes and zero-cost abstractions, but don't want to deal with the rest of Rust's evolution. This might be easier to illustrate by contrast. If I want a statically-typed, garbage-collected language, I can choose Java, Kotlin, C#, Scala, Go, TypeScript, etc. I feel like I have a lot of choice. If I want a dynamic language, I can go with Python, Ruby, JS, PHP, etc. If I want a language that doesn't need GC while not having memory leaks...I'm left with Rust. I can't decide that I don't like the other parts of Rust or don't want to deal with Rust's evolution. If Kotlin were evolving quickly and breaking lots of things, I could just say "Kotlin is dumb and I'll just use Java or Scala or C# or Go". I can't say "Rust is dumb and I'll use..." When there aren't easy replacements, you're wedded to the decisions of the community. The easier the replacements, the less loud your complaints will be about a language. I think that Kotlin was pretty great for Java because it was highly compatible with Java and gave Java breathing room to figure out how it would evolve Java. Kotlin gave frustrated people a path; it gave Java breathing room to figure out its evolution; and it gave Java the opportunity to look at what worked well in Kotlin and figure out how it could apply that in Java. When we look at Go, there are often complaints because Go offers things unavailable elsewhere: fast compile times and to a certain extent its concurrency support. So if you really want fast compile times, you don't have an alternative. Rust is probably changing more than languages like Go and Kotlin which are similar aged. There's a good reason for that: Rust's brief is a lot more novel and expansive than those two languages. However, if you're sold on Rust's memory management and zero-cost abstractions, it might be annoying that it feels like more of a moving target than a language like Go or Kotlin - and you have no alternative to fill that void.

by wffurr 7y ago

kccqzy 7y ago

Concepts already happened. In C++20 released earlier this year.

masklinn 7y ago

> C++ is from 1985 and standardized in 1998, and it's still changing at a fast clip: C++11, C++17, Concepts will be a big deal when they happen in C++2?. C++ pretty much didn't change between 1998 and 2011 though (2003 was mostly a bugfix and compatibility release). And these days it updates every 3 years (you forgot C++14 though it was a very minor release) which is a much slower pace than Rust's 6 weeks cycle.

wffurr 7y ago
Major C++ releases and Rust Editions are both on three year cycles.
- masklinn 7y ago
  AFAIK rust editions are not on any schedule currently, there's no guarantee that there'll be a Rust 2021 edition.
  - steveklabnik 7y ago
    Yes. We have not technically committed to a Rust 2021 yet. We are going to decide this year.
ChrisSD 7y ago
I don't think the 6 weeks vs. 3 years tells the full story. C++ collects up a whole truck load of changes and waits up to 3 years then dumps all of them in one go. Whereas Rust releases them individually, waiting up to six weeks after they've done baking in the nightly compiler (though they've likely been in development for years before that). That's not to say Rust is necessarily slower paced than C++ either, just that a raw number on release dates aren't helpful by themselves.
iknowstuff 7y ago
Yup. If you read the linked article, you’ll notice the release schedule was addressed by the author.
- masklinn 7y ago
  That an article about Rust changes talk about Rust's schedules has nothing to do with comparisons between C++ and Rust.

mdasen 7y ago

That's certainly reasonable, but I think it seems harder to keep up with when people compare it to languages like Go (first appeared November 2009) and Kotlin (first appeared July 2011). Those languages both seem really easy to keep up with by comparison. Of course, both of those languages are going along much more well trodden paths. I think the "Rust is changing too much" feeling comes from people really wanting to use Rust because it has a cool new way of managing memory and zero-cost abstractions, but also feeling like it just keeps moving a little too much on them. Languages like Go and Kotlin just aren't moving much on them. I think that another part of that feeling comes from the fact that Rust has two different pieces: a) the new way of dealing with memory and abstraction; and b) the syntax, sugar, etc. If you're looking for "a", Rust is the only game in town there. You can't just decide that you need the memory lifetimes and zero-cost abstractions, but don't want to deal with the rest of Rust's evolution. This might be easier to illustrate by contrast. If I want a statically-typed, garbage-collected language, I can choose Java, Kotlin, C#, Scala, Go, TypeScript, etc. I feel like I have a lot of choice. If I want a dynamic language, I can go with Python, Ruby, JS, PHP, etc. If I want a language that doesn't need GC while not having memory leaks...I'm left with Rust. I can't decide that I don't like the other parts of Rust or don't want to deal with Rust's evolution. If Kotlin were evolving quickly and breaking lots of things, I could just say "Kotlin is dumb and I'll just use Java or Scala or C# or Go". I can't say "Rust is dumb and I'll use..." When there aren't easy replacements, you're wedded to the decisions of the community. The easier the replacements, the less loud your complaints will be about a language. I think that Kotlin was pretty great for Java because it was highly compatible with Java and gave Java breathing room to figure out how it would evolve Java. Kotlin gave frustrated people a path; it gave Java breathing room to figure out its evolution; and it gave Java the opportunity to look at what worked well in Kotlin and figure out how it could apply that in Java. When we look at Go, there are often complaints because Go offers things unavailable elsewhere: fast compile times and to a certain extent its concurrency support. So if you really want fast compile times, you don't have an alternative. Rust is probably changing more than languages like Go and Kotlin which are similar aged. There's a good reason for that: Rust's brief is a lot more novel and expansive than those two languages. However, if you're sold on Rust's memory management and zero-cost abstractions, it might be annoying that it feels like more of a moving target than a language like Go or Kotlin - and you have no alternative to fill that void.