4 ms·

This comment is very strange. Go was made public when it was stable (or maybe shortly before?), Rust was made public long before it was. Rust will be stable in

This comment is very strange. Go was made public when it was stable (or maybe shortly before?), Rust was made public long before it was. Rust will be stable in 4 weeks, Go was stable several years ago. So what? If we judged languages by how early they were stable, we would all be writing Fortran 57, Algol 58, and COBOL 60.

andrewchambers 12y ago
I'm not judging the language, I'm just warning people to be careful in choosing to build a product with it. The team still seems to be changing stuff like crazy even after the "stable beta" release.
- dbaupp 12y ago
  I think you have the wrong impression about the recent changes, e.g. a recent "regression report"[1] found only two regressions between nightly and the original released beta. Furthermore, several changes have been rejected due to being breaking. The team is seriously committed to stability. [1]: http://internals.rust-lang.org/t/regression-report-beta-2015-04-03-vs-nightly-2015-04-10/1860 http://internals.rust-lang.org/t/regression-report-beta-2015...
  - andrewchambers 12y ago
    You can be sure if more people used rust, there would be many more detected breakages. The undetected ones are more worrying. I get that the language is a beta, but be warned. One example I saw - http://internals.rust-lang.org/t/memcpy-is-backwards/1797 http://internals.rust-lang.org/t/memcpy-is-backwards/1797
    - dbaupp 12y ago
      Breaks during beta that are not detected seem fine to me: people were not using the feature, and the improvement/bug fix could land without issue. That particular change caused heartache, yes, but it was purposely made before the beta release, exactly because it was breaking.
    - kibwen 12y ago
      The language was not yet in beta when the linked change was made. Using that change to criticize the stability of the beta is disingenuous.
      - andrewchambers 12y ago
        My mistake. I also just skimmed the issues page and saw people who are contributors discussing whether a memory leak is classified as unsafe behavior and changing api's based on this. It feels like this sort of thing should be put to rest before you declare any sort of stability.
        kibwen 12y ago
        The notion that memory leaks do not constitute memory unsafety has been the party line for a long time, since last year at least (since we can't prevent memory leaks statically: imagine sending something across a channel to a deadlocked thread (remembering that Rust cannot statically prevent deadlocks in general, only data races)). The disruption this week has been due to a stdlib API that made use of a very specific pattern involving a mix of unsafe code, ownership transfer, and destructors. Previously it was believed that this particular unsafe code could not lead to memory unsafety, but that happens to be untrue when memory leakage is thrown into the mix. As a result of this coming to light people will need to reevaluate unsafe code in destructors in a way that had previously not been considered, which is why there's been a general tizzy about it.
        andrewchambers 12y ago
        Thanks for the explanation.
- kibwen 12y ago
  The team is emphatically not changing things like crazy. Every week the nightly unstable branch runs against the stable packages on crates.io to automatically smoke out potential stability regressions. Here's last week's: http://internals.rust-lang.org/t/regression-report-beta-2015-04-03-vs-nightly-2015-04-10/1860 http://internals.rust-lang.org/t/regression-report-beta-2015... Two regressions out of 900 packages, and one of those was due to a bug that was fixed (the other was due to a new warning being added, which caused breakage in a package that had opted in to turning all warnings into hard errors; a plan to keep this from happening in the future is being formed at https://github.com/rust-lang/rfcs/issues/1029 https://github.com/rust-lang/rfcs/issues/1029 ). For this week, the big breaking change will be the deprecation of thread::scoped due to its API being found unsound. This is exactly the sort of thing that you want to cause breakage for, and does not happen lightly.

andrewchambers 12y ago

I'm not judging the language, I'm just warning people to be careful in choosing to build a product with it. The team still seems to be changing stuff like crazy even after the "stable beta" release.

dbaupp 12y ago
I think you have the wrong impression about the recent changes, e.g. a recent "regression report"[1] found only two regressions between nightly and the original released beta. Furthermore, several changes have been rejected due to being breaking. The team is seriously committed to stability. [1]: http://internals.rust-lang.org/t/regression-report-beta-2015-04-03-vs-nightly-2015-04-10/1860 http://internals.rust-lang.org/t/regression-report-beta-2015...
- andrewchambers 12y ago
  You can be sure if more people used rust, there would be many more detected breakages. The undetected ones are more worrying. I get that the language is a beta, but be warned. One example I saw - http://internals.rust-lang.org/t/memcpy-is-backwards/1797 http://internals.rust-lang.org/t/memcpy-is-backwards/1797
  - dbaupp 12y ago
    Breaks during beta that are not detected seem fine to me: people were not using the feature, and the improvement/bug fix could land without issue. That particular change caused heartache, yes, but it was purposely made before the beta release, exactly because it was breaking.
  - kibwen 12y ago
    The language was not yet in beta when the linked change was made. Using that change to criticize the stability of the beta is disingenuous.
    - andrewchambers 12y ago
      My mistake. I also just skimmed the issues page and saw people who are contributors discussing whether a memory leak is classified as unsafe behavior and changing api's based on this. It feels like this sort of thing should be put to rest before you declare any sort of stability.
      - kibwen 12y ago
        The notion that memory leaks do not constitute memory unsafety has been the party line for a long time, since last year at least (since we can't prevent memory leaks statically: imagine sending something across a channel to a deadlocked thread (remembering that Rust cannot statically prevent deadlocks in general, only data races)). The disruption this week has been due to a stdlib API that made use of a very specific pattern involving a mix of unsafe code, ownership transfer, and destructors. Previously it was believed that this particular unsafe code could not lead to memory unsafety, but that happens to be untrue when memory leakage is thrown into the mix. As a result of this coming to light people will need to reevaluate unsafe code in destructors in a way that had previously not been considered, which is why there's been a general tizzy about it.
        andrewchambers 12y ago
        Thanks for the explanation.
kibwen 12y ago
The team is emphatically not changing things like crazy. Every week the nightly unstable branch runs against the stable packages on crates.io to automatically smoke out potential stability regressions. Here's last week's: http://internals.rust-lang.org/t/regression-report-beta-2015-04-03-vs-nightly-2015-04-10/1860 http://internals.rust-lang.org/t/regression-report-beta-2015... Two regressions out of 900 packages, and one of those was due to a bug that was fixed (the other was due to a new warning being added, which caused breakage in a package that had opted in to turning all warnings into hard errors; a plan to keep this from happening in the future is being formed at https://github.com/rust-lang/rfcs/issues/1029 https://github.com/rust-lang/rfcs/issues/1029 ). For this week, the big breaking change will be the deprecation of thread::scoped due to its API being found unsound. This is exactly the sort of thing that you want to cause breakage for, and does not happen lightly.