4 ms·

Wow - some of those are pretty major changes. https://github.com/mozilla/rust/pull/12815 https://github.com/mozilla/rust/pull/12815 - even if that's not a majo

Wow - some of those are pretty major changes. https://github.com/mozilla/rust/pull/12815 https://github.com/mozilla/rust/pull/12815 - even if that's not a major change grammatically, is a huge change linguistically. That's one of the things about Rust... It looks like a lot of fun, and I can't wait to actually spend some time learning it - but it's still changing so much. When it does stabilise, though, it's certainly going to be an interesting language.

thirsteh 13y ago
I'd rather it finish changing, then stabilize, than the other way around. Popularity is not that important.
- Pacabel 13y ago
  I think it's obvious that it's good to "get things right" as much as possible before deciding to limit further changes. However, at some point it needs to be realized that perfection will never be achieved. This is especially true for a programming language that aims to be a "practical language" (as it prominently states on its web page). Practicality requires usability. Usability requires stability. We keep hearing about how Rust 1.0 is supposedly going to be released sometime later this year. Yet instead of seeing things stabilize, we're still seeing breaking changes like the one mentioned here. It starts to make some people skeptical about when Rust will actually be seriously usable.
  - dbaupp 13y ago
    The changes are generally changing in nature (from language to library changes) and scope (normally just renaming/moving).
  - bjz_ 13y ago
    Most of the changes now are to refining and fleshing out library APIs. The RFC process is also being refined to make more significant changes more disciplined as the language moves towards 1.0: https://mail.mozilla.org/pipermail/rust-dev/2014-March/008973.html https://mail.mozilla.org/pipermail/rust-dev/2014-March/00897...
  - pcwalton 13y ago
    > We keep hearing about how Rust 1.0 is supposedly going to be released sometime later this year. Yet instead of seeing things stabilize, we're still seeing breaking changes like the one mentioned here. It starts to make some people skeptical about when Rust will actually be seriously usable. It's better to get the breaking changes out of the way soon rather than delay them to later. We intentionally front-load all breaking changes precisely because we want stability soon; that is why there are so many of them recently. You keep posting this same exact comment over and over in every Mozilla-related thread (even ones unrelated to Rust), without any more evidence that Rust is not headed toward stability.
    - Pacabel 13y ago
      Patrick, in your first paragraph you admit that there are breaking changes to Rust. Yet in your second paragraph you ask for evidence of the lack of stability? Your first paragraph provides the evidence that you're looking for! Had I (or anyone else) written code a mere week ago using the old Chan and Port conventions, we'd already have to be updating our code. That's not stability. I think it'll be safe to say that Rust is headed toward stability once you've committed to not making any more breaking language or library changes, you have a separate code branch receiving only fixes, there are releases available, and at least some assurance is given that any issues that do arise will at least be investigated for a reasonably long period of time. Until we actually get at least one of those releases, I don't think we can consider Rust to be moving toward stability. We'll have to consider it a moving target, and we'll have to continue inquiring as to when it will start to stabilize.
      - pcwalton 13y ago
        > Patrick, in your first paragraph you admit that there are breaking changes to Rust. Yet in your second paragraph you ask for evidence of the lack of stability? Your first paragraph provides the evidence that you're looking for! No, your first comment was saying that Rust will not stabilize this year. Your evidence is that Rust is not stable now. Of course Rust is not stable now; as I said, we're making the biggest breaking changes now so that we don't have to make them later. > I think it'll be safe to say that Rust is headed toward stability once you've committed to not making any more breaking language or library changes, you have a separate code branch receiving only fixes, there are releases available, and at least some assurance is given that any issues that do arise will at least be investigated for a reasonably long period of time. That's called "1.0". Which is not finalized yet, but has a target date for this year. > We'll have to consider it a moving target, and we'll have to continue inquiring as to when it will start to stabilize. No, you will keep doing that because you're trolling. But most people can tell the difference between "stable now" and "in the process of stabilization". We have a set of issues for the 1.0 bug tracker and triage them regularly: https://github.com/mozilla/rust/issues?direction=asc&labels=&milestone=20&sort=created&state=open https://github.com/mozilla/rust/issues?direction=asc&labels=... We have also formalized an RFC process for language changes. That is a stabilization process and it is underway right now.
  - kazagistar 13y ago
    C, C++, D, Go, etc already exist, so there is no urgent need to satisfy or void to fill. They can take their time.
    - renox 13y ago
      In theory, you're right, in practice it seems that the computer world is very much like a fashion industry where people won't look at things because "they're old".. Proof: you didn't put Ada in your list, even though if you want to have a "secure" program, this ought to be a computer language to evaluate.. That said, I agree with you, Rust devs must take their time, I think that Rust 'fans' underestimate the amount of work which remains, from IRG logs apparently there isn't even a proper way to do a "unit type" (meters, seconds, etc) library in Rust!!
  - flogic 13y ago
    This week's list of breaking changes seems smaller than most while total merged pull requests seems about average. One week is too small a sample to go off but hopefully it's a downward trend as things sort themselves out.
bjz_ 13y ago
> https://github.com/mozilla/rust/pull/12815 https://github.com/mozilla/rust/pull/12815 - even if that's not a major change grammatically, is a huge change linguistically. They were renamed because we were constantly forgetting the difference between Ports and Chans. It was a difficult decision choosing the right replacement however. See the huge discussion here: https://github.com/mozilla/rust/issues/11765 https://github.com/mozilla/rust/issues/11765 At least it was pretty easy to find/replace them, and http://rust-ci.org/ http://rust-ci.org/ notifies you of any breakages. But yeah, early adoption isn't for the feint-of-heart.
- Alphasite_ 13y ago
  Why not Sender and Receiver? TX and RX are obviously equivalent, but i take it there are downsides that I'm missing?
  - cmrx64 13y ago
    It is Sender and Receiver now. TX and RX aren't obvious to non-English-speakers

thirsteh 13y ago

I'd rather it finish changing, then stabilize, than the other way around. Popularity is not that important.

Pacabel 13y ago
I think it's obvious that it's good to "get things right" as much as possible before deciding to limit further changes. However, at some point it needs to be realized that perfection will never be achieved. This is especially true for a programming language that aims to be a "practical language" (as it prominently states on its web page). Practicality requires usability. Usability requires stability. We keep hearing about how Rust 1.0 is supposedly going to be released sometime later this year. Yet instead of seeing things stabilize, we're still seeing breaking changes like the one mentioned here. It starts to make some people skeptical about when Rust will actually be seriously usable.
- dbaupp 13y ago
  The changes are generally changing in nature (from language to library changes) and scope (normally just renaming/moving).
- bjz_ 13y ago
  Most of the changes now are to refining and fleshing out library APIs. The RFC process is also being refined to make more significant changes more disciplined as the language moves towards 1.0: https://mail.mozilla.org/pipermail/rust-dev/2014-March/008973.html https://mail.mozilla.org/pipermail/rust-dev/2014-March/00897...
- pcwalton 13y ago
  > We keep hearing about how Rust 1.0 is supposedly going to be released sometime later this year. Yet instead of seeing things stabilize, we're still seeing breaking changes like the one mentioned here. It starts to make some people skeptical about when Rust will actually be seriously usable. It's better to get the breaking changes out of the way soon rather than delay them to later. We intentionally front-load all breaking changes precisely because we want stability soon; that is why there are so many of them recently. You keep posting this same exact comment over and over in every Mozilla-related thread (even ones unrelated to Rust), without any more evidence that Rust is not headed toward stability.
  - Pacabel 13y ago
    Patrick, in your first paragraph you admit that there are breaking changes to Rust. Yet in your second paragraph you ask for evidence of the lack of stability? Your first paragraph provides the evidence that you're looking for! Had I (or anyone else) written code a mere week ago using the old Chan and Port conventions, we'd already have to be updating our code. That's not stability. I think it'll be safe to say that Rust is headed toward stability once you've committed to not making any more breaking language or library changes, you have a separate code branch receiving only fixes, there are releases available, and at least some assurance is given that any issues that do arise will at least be investigated for a reasonably long period of time. Until we actually get at least one of those releases, I don't think we can consider Rust to be moving toward stability. We'll have to consider it a moving target, and we'll have to continue inquiring as to when it will start to stabilize.
    - pcwalton 13y ago
      > Patrick, in your first paragraph you admit that there are breaking changes to Rust. Yet in your second paragraph you ask for evidence of the lack of stability? Your first paragraph provides the evidence that you're looking for! No, your first comment was saying that Rust will not stabilize this year. Your evidence is that Rust is not stable now. Of course Rust is not stable now; as I said, we're making the biggest breaking changes now so that we don't have to make them later. > I think it'll be safe to say that Rust is headed toward stability once you've committed to not making any more breaking language or library changes, you have a separate code branch receiving only fixes, there are releases available, and at least some assurance is given that any issues that do arise will at least be investigated for a reasonably long period of time. That's called "1.0". Which is not finalized yet, but has a target date for this year. > We'll have to consider it a moving target, and we'll have to continue inquiring as to when it will start to stabilize. No, you will keep doing that because you're trolling. But most people can tell the difference between "stable now" and "in the process of stabilization". We have a set of issues for the 1.0 bug tracker and triage them regularly: https://github.com/mozilla/rust/issues?direction=asc&labels=&milestone=20&sort=created&state=open https://github.com/mozilla/rust/issues?direction=asc&labels=... We have also formalized an RFC process for language changes. That is a stabilization process and it is underway right now.
- kazagistar 13y ago
  C, C++, D, Go, etc already exist, so there is no urgent need to satisfy or void to fill. They can take their time.
  - renox 13y ago
    In theory, you're right, in practice it seems that the computer world is very much like a fashion industry where people won't look at things because "they're old".. Proof: you didn't put Ada in your list, even though if you want to have a "secure" program, this ought to be a computer language to evaluate.. That said, I agree with you, Rust devs must take their time, I think that Rust 'fans' underestimate the amount of work which remains, from IRG logs apparently there isn't even a proper way to do a "unit type" (meters, seconds, etc) library in Rust!!
- flogic 13y ago
  This week's list of breaking changes seems smaller than most while total merged pull requests seems about average. One week is too small a sample to go off but hopefully it's a downward trend as things sort themselves out.

bjz_ 13y ago

> https://github.com/mozilla/rust/pull/12815 https://github.com/mozilla/rust/pull/12815 - even if that's not a major change grammatically, is a huge change linguistically. They were renamed because we were constantly forgetting the difference between Ports and Chans. It was a difficult decision choosing the right replacement however. See the huge discussion here: https://github.com/mozilla/rust/issues/11765 https://github.com/mozilla/rust/issues/11765 At least it was pretty easy to find/replace them, and http://rust-ci.org/ http://rust-ci.org/ notifies you of any breakages. But yeah, early adoption isn't for the feint-of-heart.

Alphasite_ 13y ago
Why not Sender and Receiver? TX and RX are obviously equivalent, but i take it there are downsides that I'm missing?
- cmrx64 13y ago
  It is Sender and Receiver now. TX and RX aren't obvious to non-English-speakers