Hacker News Reader

Comment by georgyo | Hacker News Reader

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.

View on HN

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

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

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.

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

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.

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.

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.

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

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

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

> That's the problem and stabilization doesn't solve it. Only rejecting language changes will.

What are you using, then; COBOL!? The C standard was last bumped in 2018, C++ is more aggressive than that, Python his shipped some downright controversial changes in the last minor versions, Go is gearing up for 2.0... Languages evolve.

I am using C and Go and I don't remember ever having to deal with some kind of change in the language. Sure there were changes but with very little impact on the ecosystem.

Languages evolve okay, but Rust felt more like it was just right in the making.

> and nothing would compile without the nightly toolchain

That has changed a lot over the past 1-2 years. Many popular crates have matured a lot and work just fine on stable.

Not all, and Rust is still evolving, but things are much more stable now.

> nothing compile without nightly

Have you ever compiled ripgrep?

> 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 for the details.

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

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

I guess they mean ABI breaking changes, like enum Lay-out optimizations, etc. (not “language feature” breaking changes).

By changes in the compiler I could kind of understand it like that... but changes in spec?

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

this is demonstrably false

Reply on news.ycombinator.com