3 ms·

> 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

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

superkuh 5y ago
>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/

superkuh 5y ago

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