4 ms·

Why did you decide to use hard deadline project management? It seems like Rust's ideals of correctness and fixing fundamental C/C++ flaws are more aligned with

by blt 12y ago

Why did you decide to use hard deadline project management? It seems like Rust's ideals of correctness and fixing fundamental C/C++ flaws are more aligned with a "when it's done" release. On the other hand, the language needs a stable release to pick up many users. I'm guessing the latter was your motivator. And knowing that real world users will likely find problems with your design no matter how long you spent perfecting it. Just curious what went into the decision.

scott_s 12y ago
I think it's worth noting that 1.0 is a stable release, meaning that any 1.x future release will not introduce breaking changes. But that does not preclude them from eventually releasing a 2.0 which does break compatibility with 1.0. That allows them to tell people that, yes, they can depend on the fact that the language and API will not change from, say, 1.2 to 1.3. And that they will continue to support it for the foreseeable future. But I imagine that eventually they will want to make breaking changes, as they certainly won't get everything completely right with 1.0. But that will be clearly marked as an entirely new version.
- MichaelGG 12y ago
  Except the std lib isn't going stable for 1.0. They have a system that marks which APIs are stable, but a lot of stuff is still unstable/experimental. So it's very possible to write a Rust 1.0 program that won't work on 1.x, if you used those parts if the stdlib. Fortunately, the compiler can warn you of this so you know what you're getting into.
  - dbaupp 12y ago
    The plan is to have those unstable parts disabled in the stable compiler, so that any program that works with rustc 1.0 will work with rustc 1.x etc. One can use those parts via the nightly branch. The plan is also to try to have much of the most useful parts of the stdlib stable (at least the core functionality). More info: - https://github.com/rust-lang/rfcs/pull/507 https://github.com/rust-lang/rfcs/pull/507 - http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html
- zokier 12y ago
  > But that does not preclude them from eventually releasing a 2.0 which does break compatibility with 1.0. Which lets us relive the fun times of eg. Dlang 2.0 release or Py3k
  - scott_s 12y ago
    I can't think of a popular language which has not had breaking releases. C, C++ and Java all have.
kibwen 12y ago
I didn't decide the deadline, I ain't a Rust dev. :P If anything I would have wanted the deadline to be January 20th, to mark the three-year anniversary of Rust 0.1. But in an attempt to answer your question, I see Rust development as an application of simulated annealing (https://en.wikipedia.org/wiki/Simulated_annealing https://en.wikipedia.org/wiki/Simulated_annealing). In all honesty, we could probably spend another two years toying around and seeking a "more optimal" solution... but I personally agree with the devs that we have reached a point where the value of seeking backwards-incompatible solutions no longer justifies the time spent unable to cultivate a growing stable of third-party libraries. That said, Rust won't be standing still post-1.0. Not even close. There are lots of language improvements that will be arriving backwards-compatibly in the coming year (e.g. improvements to dynamically-sized types, improvements to closure type inference, various improvements to the trait system like negative bounds, and so on.). Longer-term, I expect Rust to look into a design for higher-kinded types, which could eventually allow for generic monads in the vein of Haskell (though this should be considered a very far-future goal, perhaps even worthy of a Rust 2.0).
bryanlarsen 12y ago
The date for the alpha is hard, but the final release of 1.0 is not. That seems like a good compromise.
Gankro 12y ago
The 1.0 stable release will be pushed back as far as is deemed necessary. Ideally it will be in 14 weeks, but if there's still critical work to be done when we hit that point, we'll wait another 6 weeks. And another. And another. We're not just going to push out whatever we have.
- Juan_Shapiro 12y ago
  This is becoming very problematic for those of us who want to use Rust, but who aren't in a position to be constantly updating code we wrote last week so that it works with whatever changes were made to Rust this week. We really, really, really NEED a stable release of Rust. Earlier in 2014 we were hearing that we'd have it by the end of 2014. Earlier this month we were hearing that we'd have it by the end of March 2015. Now we hear it may be much later than that. It's not at all encouraging!
  - dbaupp 12y ago
    The team is 100% focused on getting 1.0 out; I've been in the meetings, I've been sitting next to other core devs: they are putting their heart and soul into making sure 1.0 is soon and is high-quality. Pushing it out before we think it is ready just because some people want to use it will result in stabilising a suboptimal language and so trade-off the long-term experience for the 5 years (or 5 decades?) for some short-term gratification.
  - blt 12y ago
    And end up with bad design choices for the sake of speed? No thanks. I'd rather wait as long as needed to perfect the design. Rust won't succeed unless its benefits over C++ are dramatic, obvious, and uncontroversial. I'm fine using C++ for a few more years if it means Rust will be amazing and not just OK.

by blt 12y ago

scott_s 12y ago

I think it's worth noting that 1.0 is a stable release, meaning that any 1.x future release will not introduce breaking changes. But that does not preclude them from eventually releasing a 2.0 which does break compatibility with 1.0. That allows them to tell people that, yes, they can depend on the fact that the language and API will not change from, say, 1.2 to 1.3. And that they will continue to support it for the foreseeable future. But I imagine that eventually they will want to make breaking changes, as they certainly won't get everything completely right with 1.0. But that will be clearly marked as an entirely new version.

MichaelGG 12y ago
Except the std lib isn't going stable for 1.0. They have a system that marks which APIs are stable, but a lot of stuff is still unstable/experimental. So it's very possible to write a Rust 1.0 program that won't work on 1.x, if you used those parts if the stdlib. Fortunately, the compiler can warn you of this so you know what you're getting into.
- dbaupp 12y ago
  The plan is to have those unstable parts disabled in the stable compiler, so that any program that works with rustc 1.0 will work with rustc 1.x etc. One can use those parts via the nightly branch. The plan is also to try to have much of the most useful parts of the stdlib stable (at least the core functionality). More info: - https://github.com/rust-lang/rfcs/pull/507 https://github.com/rust-lang/rfcs/pull/507 - http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html
zokier 12y ago
> But that does not preclude them from eventually releasing a 2.0 which does break compatibility with 1.0. Which lets us relive the fun times of eg. Dlang 2.0 release or Py3k
- scott_s 12y ago
  I can't think of a popular language which has not had breaking releases. C, C++ and Java all have.

kibwen 12y ago

I didn't decide the deadline, I ain't a Rust dev. :P If anything I would have wanted the deadline to be January 20th, to mark the three-year anniversary of Rust 0.1. But in an attempt to answer your question, I see Rust development as an application of simulated annealing (https://en.wikipedia.org/wiki/Simulated_annealing https://en.wikipedia.org/wiki/Simulated_annealing). In all honesty, we could probably spend another two years toying around and seeking a "more optimal" solution... but I personally agree with the devs that we have reached a point where the value of seeking backwards-incompatible solutions no longer justifies the time spent unable to cultivate a growing stable of third-party libraries. That said, Rust won't be standing still post-1.0. Not even close. There are lots of language improvements that will be arriving backwards-compatibly in the coming year (e.g. improvements to dynamically-sized types, improvements to closure type inference, various improvements to the trait system like negative bounds, and so on.). Longer-term, I expect Rust to look into a design for higher-kinded types, which could eventually allow for generic monads in the vein of Haskell (though this should be considered a very far-future goal, perhaps even worthy of a Rust 2.0).

bryanlarsen 12y ago

The date for the alpha is hard, but the final release of 1.0 is not. That seems like a good compromise.

Gankro 12y ago

The 1.0 stable release will be pushed back as far as is deemed necessary. Ideally it will be in 14 weeks, but if there's still critical work to be done when we hit that point, we'll wait another 6 weeks. And another. And another. We're not just going to push out whatever we have.

Juan_Shapiro 12y ago
This is becoming very problematic for those of us who want to use Rust, but who aren't in a position to be constantly updating code we wrote last week so that it works with whatever changes were made to Rust this week. We really, really, really NEED a stable release of Rust. Earlier in 2014 we were hearing that we'd have it by the end of 2014. Earlier this month we were hearing that we'd have it by the end of March 2015. Now we hear it may be much later than that. It's not at all encouraging!
- dbaupp 12y ago
  The team is 100% focused on getting 1.0 out; I've been in the meetings, I've been sitting next to other core devs: they are putting their heart and soul into making sure 1.0 is soon and is high-quality. Pushing it out before we think it is ready just because some people want to use it will result in stabilising a suboptimal language and so trade-off the long-term experience for the 5 years (or 5 decades?) for some short-term gratification.
- blt 12y ago
  And end up with bad design choices for the sake of speed? No thanks. I'd rather wait as long as needed to perfect the design. Rust won't succeed unless its benefits over C++ are dramatic, obvious, and uncontroversial. I'm fine using C++ for a few more years if it means Rust will be amazing and not just OK.