4 ms·

Of course I welcome removal of GC syntax, but I am getting in doubt on when Rust language specification can be stabilized. Version 0.9 seems it must be stable n

by eonil 13y ago

Of course I welcome removal of GC syntax, but I am getting in doubt on when Rust language specification can be stabilized. Version 0.9 seems it must be stable now, but they're still putting big changes on the language.

panzi 13y ago
In general: One cannot expect a 0.x version to be stable/won't be followed by a incompatible version. A 1.x version is a different story.
- Pacabel 13y ago
  Well, it's understandable where the concern is coming from. We've seen 0.x releases of Rust for nearly two full years now, and even the most recent ones have had significant changes. While we've heard that a 1.0 release is planned for sometime during 2014, there's little to suggest that things are actually stabilizing. It isn't Perl 6 yet, but the ongoing lack of stability is making some potential Rust users become skeptical.
  - pcwalton 13y ago
    There have been fewer and fewer breaking language changes over time. The migration from 0.8 to 0.9 was less of a burden than the migration from 0.7 to 0.8, and so on. There is also a lot of progress on making a list of blocking issues, and at this point if anything can be added backwards compatibly it is almost always not a priority for 1.0. Making a safe programming language that doesn't require GC or a runtime (while allowing allocation) has literally never been done before in industry. It has taken time to get something usable. The current overall design seems pretty workable now, as evidenced by all the projects people are starting to write, so I think it's basically just a matter of finishing off rough edges at this point.
    - steveklabnik 13y ago
      If anyone's curious, here's all it took me to update Rust for Rubyists from 0.8 to 0.9: https://github.com/steveklabnik/rust_for_rubyists/commit/ae27bcfc349450e3491e420c71f93357fb4c0f6d https://github.com/steveklabnik/rust_for_rubyists/commit/ae2...
      - mitchty 13y ago
        Thats actually a lot less than i'd expect. Kinda curious on the do N.times -> for foo in range(0, N) changes. I thought I remember a recent post from you about that. Any reason for the switch? (I ask as someone thats used ruby too much myself and is currently switching cold turkey to plain old C while rust gets a bit more mature)
        lifthrasiir 13y ago
        It's since `do` now does not apply to stack closures [1]. `Do` still supports owned closures (that's what used to be called `~once fn()` in 0.8 and renamed to `proc()`) but they can be called only once which defeats the whole point of `times` (unless you are fine with `N.times(|| { ... })` syntax). [1] https://github.com/mozilla/rust/issues/10815 https://github.com/mozilla/rust/issues/10815
        mitchty 13y ago
        Very interesting thanks!
koenigdavidmj 13y ago
Either they do this now, or they get stuck being unable to do it after 1.0.
nnethercote 13y ago
Indeed, in the entire history of humankind there has never been a stabilized release of Rust. History is clearly against them. More seriously, look at the release rate. It's pretty frequent. There's clearly heaps of work going on. It's not a moribund project.

by eonil 13y ago

panzi 13y ago

In general: One cannot expect a 0.x version to be stable/won't be followed by a incompatible version. A 1.x version is a different story.

Pacabel 13y ago
Well, it's understandable where the concern is coming from. We've seen 0.x releases of Rust for nearly two full years now, and even the most recent ones have had significant changes. While we've heard that a 1.0 release is planned for sometime during 2014, there's little to suggest that things are actually stabilizing. It isn't Perl 6 yet, but the ongoing lack of stability is making some potential Rust users become skeptical.
- pcwalton 13y ago
  There have been fewer and fewer breaking language changes over time. The migration from 0.8 to 0.9 was less of a burden than the migration from 0.7 to 0.8, and so on. There is also a lot of progress on making a list of blocking issues, and at this point if anything can be added backwards compatibly it is almost always not a priority for 1.0. Making a safe programming language that doesn't require GC or a runtime (while allowing allocation) has literally never been done before in industry. It has taken time to get something usable. The current overall design seems pretty workable now, as evidenced by all the projects people are starting to write, so I think it's basically just a matter of finishing off rough edges at this point.
  - steveklabnik 13y ago
    If anyone's curious, here's all it took me to update Rust for Rubyists from 0.8 to 0.9: https://github.com/steveklabnik/rust_for_rubyists/commit/ae27bcfc349450e3491e420c71f93357fb4c0f6d https://github.com/steveklabnik/rust_for_rubyists/commit/ae2...
    - mitchty 13y ago
      Thats actually a lot less than i'd expect. Kinda curious on the do N.times -> for foo in range(0, N) changes. I thought I remember a recent post from you about that. Any reason for the switch? (I ask as someone thats used ruby too much myself and is currently switching cold turkey to plain old C while rust gets a bit more mature)
      - lifthrasiir 13y ago
        It's since `do` now does not apply to stack closures [1]. `Do` still supports owned closures (that's what used to be called `~once fn()` in 0.8 and renamed to `proc()`) but they can be called only once which defeats the whole point of `times` (unless you are fine with `N.times(|| { ... })` syntax). [1] https://github.com/mozilla/rust/issues/10815 https://github.com/mozilla/rust/issues/10815
        mitchty 13y ago
        Very interesting thanks!

koenigdavidmj 13y ago

Either they do this now, or they get stuck being unable to do it after 1.0.

nnethercote 13y ago

Indeed, in the entire history of humankind there has never been a stabilized release of Rust. History is clearly against them. More seriously, look at the release rate. It's pretty frequent. There's clearly heaps of work going on. It's not a moribund project.