I guess it's better that way than saying something broken is "ok" only because "I promised myself that I'll finish until next Monday". It's more like Ubisoft-style, or something, except deadlines really matter for them, because money depend on it, and they cannot just "move the deadline" because of all the advertising must be timed, people tend to buy games and go to cinema more on specific dates, etc.

For project like Rust deadline doesn't actually matter that much, grasping for it is almost stupid. The only thing that actually can suffer from breaking it is self-esteem, which should't worry a reasonable man much. But magic "1.0" number does matter a bit more than just deadline, because after it there's no "breaking changes".

So I'd be much happier if Rust wouldn't reach 1.0 for the next 2 years, but would actually become satisfying instead. Somehow "non-stable but working" is better suited for making software than "broken and stable". We have plenty of "broken and stable" out there already.

Rust is not seeking pure programming perfection, it is seeking to be useful and to fulfill its goals of safe systems programming, and it is fulfilling these goals with flying colors. There's absolutely no reason for this to push the release date. There was a bug in a stdlib API, and that issue was fixed weeks ago. Trying to pivot the language by taking a fundamental feature back to the drawing board for nebulous benefit would be utter foolishness at this point.

Please see my comment below (https://news.ycombinator.com/item?id=9447938). If this were a problem for Rust's basic memory safety guarantees, we'd certainly consider delaying release. There are also ways to pursue the `Leak` approach in the future backwards-compatibly.