> For a language that's supposed to have its 1.0 release later this year, these sure sound like pretty significant breaking changes.
And that is why I think Rust is one of the most exciting new languages out there. They have not been stubbornly sticking to their original plan when they found out that it wasn't really a good idea after all.
For example the change from N:M thread scheduling to native threading.
The language and the compiler have been serving as pretty nice research vehicles for advancing practical and useful programming language and compiler design.
Don't get me wrong, change to make things truly better is probably worth it. But I'm not convinced that's what we're really seeing with Rust any longer.
Many of the recent changes seem to be what I'd call "oscillation".
So a problem is noted with some specific functionality or feature of an existing programming language. A different approach is initially taken when implementing something similar for Rust. Yet problems are found with this new approach, so a different approach is tried. And problems are found with this, so something else is tried.
The matter discussed in the article appears very much to be yet another example of this.
Continually searching for some vague "optimal" solution seriously impacts the usability of the language, especially when there might not even be a solution with satisfactory trade-offs. It's disappointing when code written a week ago suddenly needs significant updates due to language and library changes, especially when the language is supposedly "stabilizing".
Rust doesn't exist in a bubble. It's facing some stiff competition from languages like C++11, C++14, Go, Scala, and even Java. Maybe they aren't as "perfect" as Rust aims to be, but they offer many of its core benefits, and they let people get work done today, while still undergoing improvement. Rust, on the other hand, appears to be stumbling around, searching in vain for some vague notion of "perfection", while being unusable to real-world developers who need at least some stability.
You are not convinced, but most Rust users are convinced. I guess time will tell.
I started using Rust from Rust 0.5 (December 2012). I saw zero oscillation so far. From what I can see, Rust is converging, rapidly.
Consider this: you can observe these at all because Rust is developed in the open. I think you would have similar reaction if you could observe Go development done behind the closed door before the release.
Actually, there are a few things in which Rust has recently gone back to old behaviour (though “oscillation” would be a bit strong as a description of it). Nested block comments is one that was removed a year or two back as unnecessary and reinstated a few months ago. I can’t think of any of the bigger ones off the top of my head; calling them oscillations could also be a bit strong too, as they tend to end up subtly different when they come back—different and superior.
I think to be "oscillation" they'd have to change their minds three times or more. chrismorgan in this subthread mentions "Nested block comments is one that was removed a year or two back as unnecessary and reinstated a few months ago.
That's trying out something both ways, and after experience deciding one is best. That they changed their minds twice just means their initial first cut turned out to be "right" after all.
Now, if they're doing X -> Y -> X -> Y that would be cause for concern.
I think your concern for "stiff competition" is perhaps overblown, I only see C and C++ as being a real competitor, I don't see Go or anything based on the JVM as being even in the same category, you're a lot further from the metal. Personally, after doing plenty of C++ in the '90s I've decided it's no fun at all (a supremely dangerous language), am defaulting to C at the moment and will at some point decide if Rust meets my requirements and is likely to be viable for a long time. I gather I'm not the only one.
I draw a different conclusion from the "stiff competition". Your conclusion is along the lines of "my god! they need to hurry up and finish it or they'll lose the future!", whereas mine is more "what's the rush? there are good alternatives right now, and there will always be more code that needs writing in the future".
By the way, it is actually very possible to write real software in rust already - none of the changes in the last 6 months or so have really required all that much surgery to get up to date. Even this change sounds like it would have a fairly straightforward update path. The only big frustration for me is the lack of a mostly-implemented and "blessed" package manager. I'm watching progress on that front with much more interest than these language changes.
Yeah, in some sense, these are all just endgames. To me, the last hard change was @-removal and interior mutability, which happened in October and November 2013. So your "last 6 months" comment is exactly correct.
Yeah, I guess a more recent biggish one was having to re-do a good deal of vector usage as those apis moved around and changed. But I would say my recent experience has been >90% crate moves and renames, which are really easy to deal with, especially with the right mindset of "I'm using pre-alpha software".
I also agree with whoever it was (you?) who pointed out elsewhere that the only reason people are even able to gripe about this stuff is that the development has been way more collaboratively open than other languages. That openness has its pros and cons!
"Oscillation" is definitely the wrong word---I haven't seen any real instance of reverting to previous behavior without a good reason and a general consensus to settle on the one behavior. Although this mut thing has me nervous.
On the other hand, at least as far as I can see, "convergence" is also not a particularly good description. Admittedly, the code I have played with was written to exercise Rust's unique features, but going from 0.5 to 0.9[1] I got hit with a fair number of major changes. Take the M:N -> 1:N threading thing (and no, I still have very serious doubts about the long-term stability of "let's do both!"); that's almost completely transparent most code, but it's still the only significant difference between Java and Erlang.
[1] Yeah, I really need to find some time to catch up again.
Well it can have all the breaking changes it wants, since it's not 1.0 yet. Which is kind of the point - show a unified, logical interface to the programmer that still covers memory safety without mandatory GC, concurrency without data races, speed, functional programming.
Most of the changes that have happened in the last year have been either to simplify the language, or to remove superfluous features. This is a good thing, especially for a language that is carving out a new domain. By the time 1.0 is out, the developers will be confident that the language is good, and they'll be less likely to change it down the line.
