undefined | Better HN

0 pointssuperkuh1y ago0 comments

I imagine that is a dev's perception (in shipping rust binaries to users) with their rolling OS and constantly updated rustc. But as a user trying to compile rust code written by rust devs what happens is that it won't compile because the compiler is 3 months out of date and rust devs immediately use new features. I had this happen personally often enough it put me off even trying out rust written applications. This is not things I've heard. It is things I've directly experienced.

rustc is a rolling only compiler and that's not great and it does break often (not be able to compile code) in distros that are not rolling. And no, curl|sh and/or rustup are not solutions. I think the only solution is waiting for rust to become popular enough that the proportion of bleeding edge using devs to normal devs goes down.

0 comments

6 comments · 2 top-level

gpm1y ago· 2 in thread

Right, that's usually described as "forwards compatibility", and yes, rust the language doesn't attempt to supply it. And yes, rustup is in fact a (the) solution for users. Distros increasingly package it because it is the recommended way to use the rust compiler (e.g. if you're on the latest ubuntu or any of its derivatives you can install it with apt instead of curl|sh).

A decent portion of projects, especially bigger ones, will try to support stables going back a few versions, but at best they're just changing the timeline slightly. This is really intended to help packaging for distributions, not users. Users should just use a compiler at least as up-to-date as the software they are trying to build.

superkuhOP1y ago

Exactly. rustc has a lifetime of about 3 months. gcc has a lifetime of about 5-10 years. Perl's interpreter has a lifetime of about 20 years.

edit since I can't reply: The difference is that Perl devs don't immediately use the new features (and Perl 6 is not Perl). Bash too constantly gets incompatible (forwards) changes, but no Bash dev is so inconsiderate as to use these as they want their software to actually run on people's machines.

That's my entire point: rust's immature/bleeding edge dev culture causes the problem. rustc could be okay, but the culture is too bleeding edge for using rust software now. Maybe in a decade it'll settle down.

gpm1y ago

Perl 5 introduced forwards incompatible changes less than a year ago. Perl 6 was so backwards incompatible that after 20 years of work they renamed the language to something else - it last had forwards incompatible changes sometime in january.

Not only are these not meaningfully better, they're also the opposite of what I would hold out as a "successful versioning model".

Rustc lasts until you are using software that depends on a more modern version of rustc, just like any dependency. Then you upgrade it - which just like any dependency with backwards compatibility - is painless (and in fact entirely transparent if you use tooling like rustup).

duped1y ago· 2 in thread

> And no, curl|sh and/or rustup are not solutions.

I'm confused - you are frustrated that the official release channel of software that is used by almost all users of that software is "not a solution" because you want to use unofficial release channels that have outdated versions of the software that are much more rarely used?

superkuhOP1y ago

Correct. I avoid rust because it is a language where it's pretty much infeasible to have a compiler from your system repositories unless it's a rolling distro. Having some random application require updates so often (like a browser) is marginally acceptable if distasteful. But a compiler and toolchain that exists entirely outside my distro? No thanks.

What I am confused about is how everyone is pretending this is a normal software situation. It's vastly weird and different from most compilers and toolchains. It may be normal if you're coming from web dev but web dev is not normal and not a healthy ecosystem.

duped1y ago

It's totally normal except for C/C++ toolchains on Linux. C/C++ compilers are managed this way on MacOS, Windows, and by most embedded toolchains.

Why don't you want your toolchain managed outside your distro? Don't you want your software to run outside your distro?

1 more reply

j / k navigate · click thread line to collapse

0 comments

6 comments · 2 top-level

gpm1y ago· 2 in thread

superkuhOP1y ago

Exactly. rustc has a lifetime of about 3 months. gcc has a lifetime of about 5-10 years. Perl's interpreter has a lifetime of about 20 years.

gpm1y ago

Not only are these not meaningfully better, they're also the opposite of what I would hold out as a "successful versioning model".

duped1y ago· 2 in thread

> And no, curl|sh and/or rustup are not solutions.

superkuhOP1y ago

duped1y ago

It's totally normal except for C/C++ toolchains on Linux. C/C++ compilers are managed this way on MacOS, Windows, and by most embedded toolchains.

Why don't you want your toolchain managed outside your distro? Don't you want your software to run outside your distro?

1 more reply

j / k navigate · click thread line to collapse