Reinventing the first 90% of the wheel is quick. It's that last 10% that takes all the time.
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.
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?
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.
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.
Sure, the usual implementations all use a VM. So what?
> I'm curious why you would liken Go to them.
Because for many of the things people would consider using Go for, one or more of those languages would be the top competitor.
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.
And even Rob Pike admitted that most people come to Go from Python/Ruby, whereas he expected that to be from C++.
This year.
You can see the issues here: https://github.com/mozilla/rust/issues?milestone=20&page=1&s...
> 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.