I'd rather it finish changing, then stabilize, than the other way around. Popularity is not that important.
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.
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.
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.
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.
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!!