Hacker News Reader

Comment by superkuh | Hacker News Reader

Rust is just too young and moves to fast to be used for software projects you want other people to be able to compile. In addition to the backwards compatibility problems it suffers even more serious forwards compatibility problems due to the type of dev culture currently associated with it. They always use $latest and what is in $latest changes so fast even if your rustc is 4 months old it already can't compile code written in $latest. If you're only shipping binaries it's okay. And in the future I bet Rust will be pretty nice. But right now it's painful and full of pitfalls.

View on HN

> Rust is just too young and moves to fast to be used for software projects you want other people to be able to compile.

Except many people doing exactly that and it working fine.

> backwards compatibility problems

Which aren't really a problem in practice. Definitely not worse then in any other language, yes there was some intentional breakage (soundness bug fixes) and unintentional breakage (compiler bugs) but most of this was in the very early stable rust versions since then accidental breakage which isn't caught and fixed before stable has become quite rare. As far as I know rust does more to find accidental breakage then many other languages.

> They always use $latest and what is in $latest changes so fast even if your rustc is 4 months old it already can't compile code written in $latest.

What is the problem with requiring a up-to date build chain? Slow long release cycles with a lot of patch back-porting is a software development model which for many (most?) projects has been deemed to not work well and has been replaced with something more in the direction of CI. Let's be honest even if we assume slow long releases are better for compilers, they still put quite an additional burden one the compiler development process which a is feasible if you have a lot of payed devs from large companies, but not really if only your core devs are payed (by the foundation and/or companies) but a lot of relevant contributions come from people not directly payed to work on rust.

> But right now it's painful and full of pitfalls.

I don't think so, but I guess we both can agree that thinks are improving, for me to make it even better and for you to maybe make it usable for the things you currently treat it as not suited for. ;-)

>What is the problem with requiring a up-to date build chain?

Well, Debian Bullseye, a distro that hasn't even been released yet, already has a rustc that's so out of date (ie, ~5 months, 1.48) that it can't compile code written today using today's features. I guess if you come from the web or some "fast" internet company where you rebuild your entire world every day then 5-6 months is an eternity. But with, say, c++, I can expect to be able to compile C++ programs written by devs for a handful of years before C++?? issues start. And despite Bash 5 getting new features regularly I can expect a bash script written today to work on my 15 year old desktop running linux 2.6. It's not because these languages don't add new backwards incompatible features. It's because the devs don't immediately use them and say, "What is the problem with requiring a up-to date build chain?"

If you only talk to other bleeding edge devs in the rust community I can see how this ethos propagates. But not everyone is a bleeding edge rust dev. Some of us run our distros for many years and just want to compile programs.

Requiring the use of rust-up instead of using system repos is the often suggested way around this. But I, and many others, absolutely hate using third party compiler software from out of repos. It's a bad practice and leads to it's own trouble as shown the very topic this discussion thread is about.

I don't see how that's different to C++. You will run into the same issues there if you happen to use code that uses some of the various new features e.g. items targeted for C++23, that are already starting to be supported by the newest versions of GCC and Clang. If you're on Debian Stable or RHEL, I believe those are even still using GCC versions that don't fully support C++20.

Their argument is a cultural one, not a technical one. Technically, they’re the same, but culturally, C++XY takes time to see adoption, but Rust 1.Y tends to be adopted almost immediately.

On certain corners of Github, I wouldn't say so. I think you would see a lot more people doing the same thing in C++, if there was a Cargo-style package manager that got more adoption there.

But rust is a compiler, i.e. a dev tool.

It's not a problem of running rust code, you always can run any "latest" compiled rust code with Debian Bullseye. Only for building the binary do you need a up to date version.

But this isn't uncommon for a lot of projects which might require up to date build tools for them to be build.

I my opinion, and I know many do disagree with me, the problem is the idea of pinning dev-tools when releasing a distribution and expecting this to work well. In my experience it doesn't, and it's not limited to rust or web-related things where it doesn't work well.

(Like e.g. I don't know how often I had to install newer versions of clang, gcc, C++-related build tools, python related build tools, system dependencies, java etc.)

> Well, Debian Bullseye, a distro that hasn't even been released yet, already has a rustc that's so out of date (ie, ~5 months, 1.48)

Sadly, Debian does this a lot - Bullseye is going to release with NodeJS v12 which is already in Maintenance LTS (dying) and not the Active LTS (v14) and has 4 more newer Current releases (15->18). I am a Debian supporter but this is a distro problem of locking in on already out of date dev tools over and over again, Bullseye is already far out of date before it's even launched.

https://packages.debian.org/search?keywords=nodejs&searchon=...

https://nodejs.org/en/about/releases/

> Well, Debian Bullseye, a distro that hasn't even been released yet, already has a rustc that's so out of date (ie, ~5 months, 1.48) that it can't compile code written today using today's features.

This sounds more like an argument against Debian’s packaging practices than Rust. Debian is full of out-of-date tools, and that and CentOS doing the same are the reason non-system package managers are so popular.

It's not a problem with mature languages though.

Depending on what you consider “mature”, sure. Here is a short list of programming languages where I have had to install an up-to-date version on recent Debian, Ubuntu or RHEL derivatives in just the last month:

- Node.js

- Python

- Go

- Rust

- C++

- .NET Core

- Java

None had an up-to-date version in the distribution repositories. It’s a problem - and for those who defend it as otherwise while lamenting the rise of Docker, perhaps it’s worth some careful introspection about what a majority of people actually want from an operating system distribution, and whether the concept is in fact a relic of the days when software was distributed on CDs via the mail.

Really? For what reason did you have to install a newer Python, a newer C++ compiler, or a newer Java runtime?

> None had an up-to-date version in the distribution repositories.

Of course not. A Debian release is meant to not change – except for security fixes – for the duration of its 2 year cycle. That's a feature, not a bug.

To run software written using them.

Operating systems are servant of their applications, not vice versa.

What’s a mature language then? I’ve encountered this issue with rust, php, ruby, nodejs, python , java.

Debian has an explicit stability guarantee:

> This is what Debian's Stable name means: that, once released, the operating system remains relatively unchanging over time. [1]

If you just want to compile programs, perhaps a distro + release channel geared towards production server deployments isn't the best choice. They even call out that fact in the "Why Debian" page:

> You can fine-tune the degree of risk you want to take, since Debian has three separate releases: Stable, Testing, and Unstable. On some of our machines (the server, the kiosk machines) we run 'stable'. Some of the other systems (individual work-stations) run various combinations of testing/unstable. (Note that there are no security updates for testing). I run some stuff from experimental on my own work-station. What's great is the ability to make finely graded decisions for different machines serving different functions. But even the more adventurous choices are solid enough that they virtually never break. And `stable' just never breaks ;-). [2]

[1] https://wiki.debian.org/DebianStability

[2] https://wiki.debian.org/WhyDebian#Why_Linux.3F_Why_Debian.3F

Meanwhile a large C++ code base I maintain broke on a minor GCC version bump.

My Rust 1.0 code on the other hand has compiled just fine since the dawn of stable rust.

The only really stable languages might be C89, C99, some fortran, and Cobol.

I think the Rust team does a fantastic job of supporting old code bases with new compilers. Crater is a testament to how much they care in fact.

Well of course a hello world Rust project would just compile fine since Rust 1.0, unlike my recent Rust project which broke again and that just broke on a minor version bump.

As for another ancient Rust project which was also on 1.0 when I was trying the language out, the borrow checker on 1.52.1 screeched at every line of my code.

While C++ is just as bad, the fact that Firefox must always use the latest Rust compiler gives you a hint that it will not work on lower versions; hence the need of a MSRV. (Minimum Supported Rust Version)

My project had about 40kloc and acted as a low latency ad server. Far from a hello world.

If the borrow checker of 1.52.1 "screeches" on every LOC but it compiles on 1.0 then very likely either there's some bug in 1.52.1 that you should report or you code was never correct and should never have compiled in 1.0 in the first place but did due to a compiler bug that since got fixed.

Of course, without more info nobody can tell which of these or even whether it is one of these two or something else.

I used Rust at FullStory for years and the pain you describe just didn't really exist, except when I wanted to test out the latest-and-greatest features that were usually better to wait until they baked on stable.

The only real pain we felt was around iOS bitcode and that was mainly Apple's fault because they make the whole process so Byzantine if you aren't using clang.

Reply on news.ycombinator.com