4 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. In addition to the backwards compatibilit

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.

dathinab 5y ago
> 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.
      - 5y ago
mmastrac 5y ago
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.
bfrog 5y ago
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.
- rvz 5y ago
  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)
  - bfrog 5y ago
    My project had about 40kloc and acted as a low latency ad server. Far from a hello world.
  - dexterlemmer 5y ago
    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.

dathinab 5y ago

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

mmastrac 5y ago

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.

bfrog 5y ago

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.

rvz 5y ago
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)
- bfrog 5y ago
  My project had about 40kloc and acted as a low latency ad server. Far from a hello world.
- dexterlemmer 5y ago
  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.