5 ms·

The optimized and stripped library in rust was about 8 times the size of the C version. While 9MB is not a lot by itself, if a significant portion of libraries

The optimized and stripped library in rust was about 8 times the size of the C version. While 9MB is not a lot by itself, if a significant portion of libraries decide they want to switch to rust that would explode disk usage! Though I think my problem with rust is that they make breaking changes in their compiler and spec every release. People regularly building on rust unstable to get features not yet released. This all makes things complicated for a distro. But the points at about making breaking changes at the bottom resonated with me. Stability is what has allowed the Linux ecosystem to grow so well. Many interconnected parts all moving in unison. Not being able to fix a bad design decision because of this does suck. Still, having everything work and sadly is more important than perfect design.

viraptor 6y ago
> Though I think my problem with rust is that they make breaking changes in their compiler and spec every release. Can you bring specific examples? The stable version is not only actually stable, but when big changes happen you can also opt into previous edition's behaviour with one config line. Breaking spec every release really doesn't sound right. As for unstable - distros could find that complicated, but distros don't have to ship unstable things, so that doesn't sound like a big problem.
- fluffy87 6y ago
  I guess they mean ABI breaking changes, like enum Lay-out optimizations, etc. (not “language feature” breaking changes).
  - viraptor 6y ago
    By changes in the compiler I could kind of understand it like that... but changes in spec?
the_duke 6y ago
> 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.
zozbot234 6y ago
> The optimized and stripped library in rust was about 8 times the size of the C version. While 9MB is not a lot by itself, if a significant portion of libraries decide they want to switch to rust that would explode disk usage! The underlying issue is that even though the standard library is statically linked, Rust does not make it easy to compile "custom" builds of the standard library as part of your project - which leaves you with all sorts of excess code bloat in the final build. You can solve this, but it requires unofficial tools such as "xargo" and the like. Once this is addressed, Rust should become genuinely competitive with C/C++ (wrt. binary size). See also https://news.ycombinator.com/item?id=23496107 https://news.ycombinator.com/item?id=23496107 for the details.
- jdub 6y ago
  Good news: `-Z build-std` is available in nightly and various bleeding edge projects have switched to it https://github.com/rust-lang/wg-cargo-std-aware https://github.com/rust-lang/wg-cargo-std-aware
Ar-Curunir 6y ago
> problem with rust is that they make breaking changes in their compiler and spec every release. this is demonstrably false

viraptor 6y ago

> Though I think my problem with rust is that they make breaking changes in their compiler and spec every release. Can you bring specific examples? The stable version is not only actually stable, but when big changes happen you can also opt into previous edition's behaviour with one config line. Breaking spec every release really doesn't sound right. As for unstable - distros could find that complicated, but distros don't have to ship unstable things, so that doesn't sound like a big problem.

fluffy87 6y ago
I guess they mean ABI breaking changes, like enum Lay-out optimizations, etc. (not “language feature” breaking changes).
- viraptor 6y ago
  By changes in the compiler I could kind of understand it like that... but changes in spec?

the_duke 6y ago

> 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.

zozbot234 6y ago

> The optimized and stripped library in rust was about 8 times the size of the C version. While 9MB is not a lot by itself, if a significant portion of libraries decide they want to switch to rust that would explode disk usage! The underlying issue is that even though the standard library is statically linked, Rust does not make it easy to compile "custom" builds of the standard library as part of your project - which leaves you with all sorts of excess code bloat in the final build. You can solve this, but it requires unofficial tools such as "xargo" and the like. Once this is addressed, Rust should become genuinely competitive with C/C++ (wrt. binary size). See also https://news.ycombinator.com/item?id=23496107 https://news.ycombinator.com/item?id=23496107 for the details.

jdub 6y ago
Good news: `-Z build-std` is available in nightly and various bleeding edge projects have switched to it https://github.com/rust-lang/wg-cargo-std-aware https://github.com/rust-lang/wg-cargo-std-aware

Ar-Curunir 6y ago

> problem with rust is that they make breaking changes in their compiler and spec every release. this is demonstrably false