> Another great PR from the illustrious ktt3ja, the compiler will now give suggestions on how to fix lifetime woes. This is an awesome usability improvement.
I'm really glad to see improvements like this. I know how I felt when I was learning C and trying to understand gcc's error messages. Rust is relatively new to everyone though, so having these features from the start is quite valuable.
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.
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 At least it was pretty easy to find/replace them, and http://rust-ci.org/ notifies you of any breakages. But yeah, early adoption isn't for the feint-of-heart.
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.
I hope it's okay if I go a little off-topic to talk about the design of this site...
Does anyone else have an issue with gray fonts and low font-weights? Gray text has been popular for a long time (HN has a heavy dose of it, for example), but the lightweight fonts seem to be a new trend. The contrast between text and background is just getting worse and worse, to the point that I need to have stylish installed just to make some sites readable. I feel like designers are designing for ideal setups like their own, and they're forgetting about people like me.
Hi! I picked this theme indeed because I thought it looked the best on my screen. Would using a heavier font help? Or maybe just setting the font color to true black?
Yeah, I toggled back and forth between the site and mobile Safari's Reader, and the low contrast between the text and the background is bothersome. When I switch Reader on, my eyes heave a sigh of relief.
I'm really glad to see improvements like this. I know how I felt when I was learning C and trying to understand gcc's error messages. Rust is relatively new to everyone though, so having these features from the start is quite valuable.