Comment by kstrauser | Hacker News Reader

Comment by kstrauser | Hacker News Reader

Parent Full thread

I'm asking sincerely, not snarkily: is that a problem for you? I've worked on a largish project with several other people, and occasionally a new feature would come up that would allow us to simplify the code. We'd tell each other, hey, I'm using new feature `foo` in the branch I'm hacking on. You'll need to be on at least 1.xx.yy to build it. Then we'd all run `rustup upgrade` and verify that it didn't break existing code, and if not, onward and upward.

Alright, I could see how that would be a PITA at a large company with a huge codebase, but I don't think there are yet a lot of Rust shops like that. I see the Rust version treadmill as similar to Python's, where it's nearly always backward compatible (let me stop ya right there, anyone who mentions 2-to-3; we're talking minor versions here) and new features are almost only additive.

Note that I'm not saying you're wrong if you disagree with me. It's more that the theoretical issues have been, well, theoretical in my personal experience so far.

Yes. I am speaking from specific experience.

I got into Rust around the 1.4 to 1.5 days. Rust 1.50 programs can't be compiled and run with Rust 1.48 rustc. My rustc compiler was literally 3 months old. Both times I went to compile a rust program I found they devs used features not included in the rustc I had. One was a software defined radio spectrogram generator, the other a web scraper and assembler for web serials. I talked to the author of the rust sdr spectrum program and he was able to write a version with older up-to-1.48-only features that worked.

That and the insistence on always using out of repo rustc via curl rust.up | sh etc put me off rust completely.

Was there a reason you couldn’t upgrade to 1.50?

Yes, I don't think doing curl rust.up | sh is a reasonable thing to do. I am only going to get language toolchains from my distro's repos.

Also, now we're ignoring that my rustc was only 3 months old and couldn't compile most things people were writing in rust? That's the point of this entire conversation. Let's not derail.

> Yes, I don't think doing curl rust.up | sh is a reasonable thing to do.

Eh, it's a one-time thing to install rustup. Then you can run `rustup upgrade` whenever.

> I am only going to get language toolchains from my distro's repos.

Ouch. OK, that's the real root of it. I haven't worked in a shop that used Python from the OS repos in... well, ever. We use to download/configure/make the source tarball from python.org. When pyenv came along, we switched over to using that. I upgraded my personal machine to use Python 3.12 earlier this week on the day it was released so I could start testing for compatibility with existing code.

I was pleasantly surprised to see my distro has Python 3.11.2 available in its repo, which is more modern than I'm used to seeing in the "native" package. That's a lot better than for the Java folks, who could only install JDK 17 from the distro when 21 is current.

> Also, now we're ignoring that my rustc was only 3 months old and couldn't compile most things people were writing in rust? That's the point of this entire conversation. Let's not derail.

I think you're right: Rust isn't the language for you. I don't mean that in a bad or smart-alecky way. It's more that the people writing the libraries you described found a new feature in the publicly availably new version of rustc, then started using it because it made their lives easier. There wasn't a compelling reason not to use that feature because everyone could freely upgrade to the new version of rustc, just as they had, without breaking existing code.

As an example of where it is a problem: anyone attempting to learn Rust runs into a huge amount of example/tutorial code that isn't all that old but will fail to compile on the latest rustc. It makes for a really difficult learning experience.

That is the opposite problem from what the person mentioned, and not a real problem. Rust is extremely good about backwards compatibility. With only a few very extreme exceptions you can take anything written from 1.0 on and build it with a new compiler.

What the comment said was:

> can't compile something written by a rust dev today with a rustc compiler from 3 months ago

This is taking new code and using it with an old compiler. Because of how deadly seriously rust takes backward compatibility, it tends to not be an issue. Just get the newer compiler to build the newer code.

This also isn't a unique problem to rust. You can't use features in any language with compilers from before they were introduced. Funny enough, even with rust's rapid growth, I actually have less issues with it in rust because of the ease of upgrading.

> Just get the newer compiler to build the newer code.

I think part of the problem is that this is backwards to how people coming from other traditional languages (like C, or C++) think.

With those, you deliberately choose your target compiler in a way to maximise who can build your software. Telling all your users "just get the newer compiler" is rude. If you can reasonably target a 20-year old version of the compiler, so that users on systems who can't upgrade their compiler for reasons you have no control over can still build and use your software, then that's a trade-off worth considering.

Note that you don't always have to choose that, but you should consider it. And when you do decide to move from, say, C89 to C99 (or - gasp - C11), that is a carefully considered decision. It's not just ooh, shiny.

You don't always know who all your users are, or why they may not have the same flexibility as you. But if you want your software to be installed on 10 billion devices, that's the sort of thing you have to consider.

https://daniel.haxx.se/blog/2022/11/17/considering-c99-for-c...

https://curl.se/docs/faq.html#How_many_are_using_curl

I feel that. I've worked in those environments. A previous job we had a C89 code base that very deliberately could only build with certain older compilers. It was made to be able to target ~20 year old OSes and embedded environments. We had to be extremely careful about new features used, and if we tried to update the tool chain.

> Telling all your users "just get the newer compiler" is rude.

With Rust you don't have the same things holding you back. Features and targets are extremely well supported and for a long time. This compatibility is a die hard sacred tenant. This a good thing! It should be celebrated and shouted from every roof top! It isn't rude that the level of engineering allows this to be a low drama affair. Without the use of RUSTC_BOOTSTRAP it is very rare to have something holding you back on an older, stable compiler. I can think of one major bump of supported OSes a while back and that's it.

You can stay on older versions of the compiler if you really want to, but don't expect to be able to build new code that uses new features.

That's just not how Software is done in this century, like it or not. Please update your software regularly.

If you encounter these kind of things, and the tooling doesn't explicitly and clearly tell you what, when and why things have changed, that's a bug and I would appreciate a bug report.

> a huge amount of example/tutorial code that isn't all that old but will fail to compile on the latest rustc

[citation needed]

Rust has maintained backward compatibility to a level even beyond what golang has done. Code written for Rust 1.0 will compile on latest Rust, minus a very scant few edge cases where it should never have compiled in the first place except for a compiler bug.

You could conceivably encounter cases where cargo init sets your project to 2021 edition and you're following a 2015 tutorial and encounter compilation errors due to edition differences, but when these happen the error should have enough information to make it clear this is the case.

Do you have some examples of that code that isn't all that old but will fail to compile on the latest rustc?

Reply on news.ycombinator.com