But when is that sort of stability going to be achieved by Rust?
We keep hearing about how "it's happening" or it'll be there "soon". But yet we still see a language and standard libraries that are evolving significantly on an ongoing basis, breaking existing code along the way.
If Rust wants to be a viable option, at some point this indiscriminate change needs to stop. It may mean that this initial version of the language has some flaws, but at least it may also be usable for serious development at that point.
The sooner that happens the better. The longer Rust delays stability, the greater traction we see competitors like Go or even existing languages getting. Rust is starting to get a Perl 6-style reputation, where there's great promise and lots of hype, but never a version we can confidently use for software that's remotely serious.
There are already a lot of programming languages that made it to x.0 without making all the breaking changes they should have, leaving warts all over the language and the standard libraries. The fact that Rust is still making lots of breaking changes is good, IMO. They seem very cognizant of the fact that they should make all the breaking changes they can while they still can.
Absolutely. I'd hate to see Rust go through a Python 3 debacle, or deal with the .NET approach where half the framework libs are completely superseded by new libs in every major release.
Python 3 wasn't a "debacle" in any sense. In fact, it has proven to be an excellent approach. Users with large Python 2.x code bases haven't experienced any disruption. Users who needed Python 3's features were free to upgrade as soon as they wanted. Libraries and frameworks have gotten Python 3 support when it becomes feasible and worthwhile to do so. It may not be the fastest adoption possible, but it has been quite pain-free, and totally optional for those who have no need for it.
Besides, Rust should be happy to get anywhere near the number of users that Python and .NET have. That surely won't happen until there's a version of Rust that's stable for more than a couple of months.
And what makes you think that Rust still won't end up in a situation where some desired future functionality requires backward compatibility to be broken, regardless of how much effort they put in now?
> Python 3 wasn't a "debacle" in any sense. In fact, it has proven to be an excellent approach.
That's… not an opinion shared by anyone else I've heard of. Python 3 has been a disaster, mainly because it didn't offer enough of a reason for users to upgrade. In other words, Python's so entrenched that Python 2's warts are effectively staying with the language forever. That is hurting every user of the Python language, and is actually an argument for fixing Rust's flaws now, while we still have a chance to.
> Besides, Rust should be happy to get anywhere near the number of users that Python and .NET have. That surely won't happen until there's a version of Rust that's stable for more than a couple of months.
We explicitly don't want so many users right now that we can't break things. That's not to say we don't want users—we do, of course—but we need them to know that the language will be unstable until 1.0.
> And what makes you think that Rust still won't end up in a situation where some desired future functionality requires backward compatibility to be broken, regardless of how much effort they put in now?
You're arguing that we shouldn't bother fixing anything because Rust will not be perfect. Yet in many of your other comments you criticize the Web stack for its lack of forward thinking design in many areas. Do you see the cognitive dissonance here?
The time to fix things that can't be fixed later is now. Just because Rust will not be perfect at 1.0, and there will be things we wish we could have changed, doesn't mean we shouldn't do the best we can.
> It may mean that this initial version of the language has some flaws, but at least it may also be usable for serious development at that point.
Right now those "flaws" include "not memory safe", and we can't fix that without breaking existing code. We are hard at work on fixing that, but we can't freeze a language that's designed for safety that isn't safe.
Rust is moving very quickly now, but they clearly have a cutoff in sight, and their explicit goal is a stable language spec and standard library for 1.0.
They are also building on LLVM, which gives them a fairly solid base; in contrast to perl6 that was trying to make a multi-language VM while reinventing the language.
I would rather have a good 1.0 release than a quick one. If Go really is a better language for the applications Rust is aiming for, then it's fine for Rust to fall behind.
Very complicated things that require high performance. The main demo project is Servo, a web rendering engine on around the same level of abstraction as gecko or WebKit.
Java, C#, Ruby, and Python are all interpreted/VMed languages. I'm curious why you would liken Go to them. Other than garbage collection, I can't see any significant similarities in their design or usage.
Control over memory management is a major, major design point. In my opinion, it's a lot more significant than whether it runs in a VM or uses native code.
For one thing, running in a VM vs. native code is usually an implementation detail. But the only language I can think of where memory management appears to be an implementation detail is Ada.
