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.
> 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.
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.
> 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=... We have also formalized an RFC process for language changes. That is a stabilization process and it is underway right now.
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/00897...
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!!
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.
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.