Hacker News Reader

Comment by superkuh | Hacker News Reader

A hilarious juxtaposition. Generally Rust programs' source are forwards incompatible and a program written by a rust dev $now won't even be able to be compiled on a rustc from 3 months ago. This is not an exaggeration or hyperbole but something that happened to me multiple times in 2020-2022 before I stopped even attempting to use rust source code. Whereas a Perl program written today could be interpeted and executed on a perl interpeter from 1999.

View on HN

That hasn't been my experience with Rust over the past 5+ years. Maybe I haven't been poking into obscure features. When the language is as old as Perl I imagine the pace of change will slow but already it's been very slow moving and stable. There's a huge emphasis on backwards compatibility (editions are such a great concept).

Is that because you update your rustc every month or two by either, 1. using a rolling distro, or 2. pulling down a new one from out of repo sources using rustup... | sh, etc as is standard rust community practice? Or did you really use a normal non-rolling distro's packaged rustc and never run into problems in 5 years?

If the former, well... yeah. If the later, I'm impressed. I wasn't doing anything complex. I had it happen even with simple programs like a rust web scraper tool for web serials to epub and a rust FFT visualizer for software defined radio.

Just rustup update. The most frustrating part of the whole experience is the rate at which the clap argument parsing crate makes breaking changes. I've had to pin a specific version because they start deprecating features as soon as they make a release. So in my experience the crate ecosystem moves much faster and is less concerned with backwards compatibility than the compiler/core language. And compared to most languages the Rust standard library is fairly sparse (which I think was a smart move).

Reply on news.ycombinator.com