3 ms·

>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

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

zxzax 5y ago
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.
- steveklabnik 5y ago
  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.
  - zxzax 5y ago
    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.
dathinab 5y ago
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.)
spinax 5y ago
> 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=names&exact=1&suite=all&section=all https://packages.debian.org/search?keywords=nodejs&searchon=... https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/
jen20 5y ago
> 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.
- gspr 5y ago
  It's not a problem with mature languages though.
  - jen20 5y ago
    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.
    - gspr 5y ago
      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.
      - jen20 5y ago
        To run software written using them. Operating systems are servant of their applications, not vice versa.
akiselev 5y ago
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 https://wiki.debian.org/DebianStability [2] https://wiki.debian.org/WhyDebian#Why_Linux.3F_Why_Debian.3F https://wiki.debian.org/WhyDebian#Why_Linux.3F_Why_Debian.3F

zxzax 5y ago

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.

steveklabnik 5y ago
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.
- zxzax 5y ago
  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.

dathinab 5y ago

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

spinax 5y ago

> 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=names&exact=1&suite=all&section=all https://packages.debian.org/search?keywords=nodejs&searchon=... https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/

jen20 5y ago

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

gspr 5y ago
It's not a problem with mature languages though.
- jen20 5y ago
  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.
  - gspr 5y ago
    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.
    - jen20 5y ago
      To run software written using them. Operating systems are servant of their applications, not vice versa.

akiselev 5y ago

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 https://wiki.debian.org/DebianStability [2] https://wiki.debian.org/WhyDebian#Why_Linux.3F_Why_Debian.3F https://wiki.debian.org/WhyDebian#Why_Linux.3F_Why_Debian.3F