4 ms·

Reinventing the first 90% of the wheel is quick. It's that last 10% that takes all the time.

bjz_ 13y ago
Indeed. There is a ton of polish that has to be sunk into the language and the libraries to get them to a state where 1.0 can finally be declared.
- Pacabel 13y ago
  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.
  - heydenberk 13y ago
    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.
    - Pxtl 13y ago
      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.
      - Pacabel 13y ago
        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?
        pcwalton 13y ago
        > 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.
  - sp332 13y ago
    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.
    - namelezz 13y ago
      What kind of applications are Rust aiming for?
      - bjz_ 13y ago
        Kernels, runtimes, embedded systems, user facing apps like web browsers, mobile apps and games.
      - andrewflnr 13y ago
        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.
  - jeffdavis 13y ago
    I'm surprised by the comparison to perl6. 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.
  - DasIch 13y ago
    Go is not a competitor to Rust. In fact Rust has effectively no competitor except for C and C++.
    - slowmover 13y ago
      Which languages would you say are competitors to Go?
      - bjz_ 13y ago
        Probably Java, C#, Ruby, Python. Perhaps C++ in some instances when it is used on the server.
        slowmover 13y ago
        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.
        dragonwriter 13y ago
        > Java, C#, Ruby, and Python are all interpreted/VMed languages. 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.
        jeffdavis 13y ago
        "Other than garbage collection..." 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.
        coldtea 13y ago
  - pcwalton 13y ago
    > But when is that sort of stability going to be achieved by Rust? This year. You can see the issues here: https://github.com/mozilla/rust/issues?milestone=20&page=1&state=open 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.

bjz_ 13y ago

Indeed. There is a ton of polish that has to be sunk into the language and the libraries to get them to a state where 1.0 can finally be declared.

Pacabel 13y ago
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.
- heydenberk 13y ago
  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.
  - Pxtl 13y ago
    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.
    - Pacabel 13y ago
      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?
      - pcwalton 13y ago
        > 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.
- sp332 13y ago
  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.
  - namelezz 13y ago
    What kind of applications are Rust aiming for?
    - bjz_ 13y ago
      Kernels, runtimes, embedded systems, user facing apps like web browsers, mobile apps and games.
    - andrewflnr 13y ago
      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.
- jeffdavis 13y ago
  I'm surprised by the comparison to perl6. 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.
- DasIch 13y ago
  Go is not a competitor to Rust. In fact Rust has effectively no competitor except for C and C++.
  - slowmover 13y ago
    Which languages would you say are competitors to Go?
    - bjz_ 13y ago
      Probably Java, C#, Ruby, Python. Perhaps C++ in some instances when it is used on the server.
      - slowmover 13y ago
        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.
        dragonwriter 13y ago
        > Java, C#, Ruby, and Python are all interpreted/VMed languages. 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.
        jeffdavis 13y ago
        "Other than garbage collection..." 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.
        coldtea 13y ago
- pcwalton 13y ago
  > But when is that sort of stability going to be achieved by Rust? This year. You can see the issues here: https://github.com/mozilla/rust/issues?milestone=20&page=1&state=open 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.