5 ms·

> Though I think my problem with rust is that they make breaking changes in their compiler and spec every release That's not accurate. Rust is backwards compa

> Though I think my problem with rust is that they make breaking changes in their compiler and spec every release That's not accurate. Rust is backwards compatible. Most 1.0 code would still compile perfectly fine today. There have been some minor breaking changes for soundness reasons, if I remember correctly. There also has been one edition upgrade (2018 edition), but every new compiler still supports the old edition, and most new stuff actually works in the old edition as well. There are experimental features, which are only available on the nightly compiler and have to be opted in to with a "#[feature(X)]" attribute. But those are very clearly labelled as experimental, unstable, and evolving, with no stability guarantees whatsoever. The criticism I would share is that while Rust is backwards compatible, it is obviously not forwards compatible. Rust evolved dramatically since 1.0, and many developers jump on new features once available. So compiling actively maintained projects with a older compiler in distros like Debian is not fun. But the rate of change has slowed down a lot over the past year or so.

frankmcsherry 6y ago
> That's not accurate. Fwiw, I recorded at least four different times a Rust release broke timely / differential dataflow, and have seen a few others in other folks' code. Afaict, none of them were soundness related, and were instead due to ergonomic additions and performance improvements. They haven't been recent (e.g. were 1.17, 1.20, and 1.22, and the others earlier) and I agree that things are much more stable now.
- the_duke 6y ago
  Interesting, I never got hit by those I think. The biggest issue I had was with the macro import and visibility changes in the 2018 edition. That broke quite a lot and was rather painful.
  - frankmcsherry 6y ago
    Yeah, for example I have an open PR in differential dataflow to make some changes to avoid a planned break in the future. https://github.com/TimelyDataflow/differential-dataflow/pull/225 https://github.com/TimelyDataflow/differential-dataflow/pull... I think they are doing the right thing with the break (it adds something I've wanted) but at the same time it's another break.
clktmr 6y ago
I think the concerns are more towards the ecosystem and community, which are very curiosity-driven. I tried Rust about one year ago and nothing would compile without the nightly toolchain. After reading the Rust book there was this realization that I now have to go and read all the new language proposals, because everybody is using them already. This and the excessive use of metaprogramming by some users drove me away from the language.
- zozbot234 6y ago
  You might want to try again, one year is a very long time in rust land. We've seen some very high profile stabilizations quite recently.
  - clktmr 6y ago
    > one year is a very long time in rust land That's the problem and stabilization doesn't solve it. Only rejecting language changes will.
    - nindalf 6y ago
      > nothing would compile without the nightly toolchain. This problem is solved though. Almost all nightly users shifted to stable after async-await was stabilized. The last holdout (IIRC) was Rocket, which also compiles on stable now. I can't think of any popular libraries or frameworks that require nightly. I can't think of any popular feature that people would want to use nightly for. I think you could learn Rust now, write your code and then not worry about any new features that are added, ever. Your code will work without breaking. Keep upgrading the compiler every 6 weeks and your code still won't break. That's a guarantee.
      - ezekiel68 6y ago
        Rocket should _soon_ not need nightly, but the documentation for currently available releases from github states that it still does[1]. (The compiler is ready, but the code/cargo.toml hasn't yet caught up) [1]https://rocket.rs/v0.4/guide/getting-started/#installing-rust https://rocket.rs/v0.4/guide/getting-started/#installing-rus...

frankmcsherry 6y ago

> That's not accurate. Fwiw, I recorded at least four different times a Rust release broke timely / differential dataflow, and have seen a few others in other folks' code. Afaict, none of them were soundness related, and were instead due to ergonomic additions and performance improvements. They haven't been recent (e.g. were 1.17, 1.20, and 1.22, and the others earlier) and I agree that things are much more stable now.

the_duke 6y ago
Interesting, I never got hit by those I think. The biggest issue I had was with the macro import and visibility changes in the 2018 edition. That broke quite a lot and was rather painful.
- frankmcsherry 6y ago
  Yeah, for example I have an open PR in differential dataflow to make some changes to avoid a planned break in the future. https://github.com/TimelyDataflow/differential-dataflow/pull/225 https://github.com/TimelyDataflow/differential-dataflow/pull... I think they are doing the right thing with the break (it adds something I've wanted) but at the same time it's another break.

clktmr 6y ago

I think the concerns are more towards the ecosystem and community, which are very curiosity-driven. I tried Rust about one year ago and nothing would compile without the nightly toolchain. After reading the Rust book there was this realization that I now have to go and read all the new language proposals, because everybody is using them already. This and the excessive use of metaprogramming by some users drove me away from the language.

zozbot234 6y ago
You might want to try again, one year is a very long time in rust land. We've seen some very high profile stabilizations quite recently.
- clktmr 6y ago
  > one year is a very long time in rust land That's the problem and stabilization doesn't solve it. Only rejecting language changes will.
  - nindalf 6y ago
    > nothing would compile without the nightly toolchain. This problem is solved though. Almost all nightly users shifted to stable after async-await was stabilized. The last holdout (IIRC) was Rocket, which also compiles on stable now. I can't think of any popular libraries or frameworks that require nightly. I can't think of any popular feature that people would want to use nightly for. I think you could learn Rust now, write your code and then not worry about any new features that are added, ever. Your code will work without breaking. Keep upgrading the compiler every 6 weeks and your code still won't break. That's a guarantee.
    - ezekiel68 6y ago
      Rocket should _soon_ not need nightly, but the documentation for currently available releases from github states that it still does[1]. (The compiler is ready, but the code/cargo.toml hasn't yet caught up) [1]https://rocket.rs/v0.4/guide/getting-started/#installing-rust https://rocket.rs/v0.4/guide/getting-started/#installing-rus...