4 ms·

I like the pragmatic approach to backwards compatibility (accepting relatively rare breakage that's not too hard to fix) instead of requiring 100% compatibility

by srdjanr 21d ago

I like the pragmatic approach to backwards compatibility (accepting relatively rare breakage that's not too hard to fix) instead of requiring 100% compatibility without exceptions

geocar 21d ago
I don’t. My software gets done. The idea that it would suddenly not be done because the compiler upgraded sounds like a potentially limitless amount of future work. Why would I want to invest in something that promises that?
- nixpulvis 21d ago
  You could keep using the old compiler, no?
  - Ygg2 21d ago
    Yes, but new compiler can't use old ecosystem crates. Hence the issue. Rust's edition system gives you the best of both worlds, with caveats. Some changes will be impossible.
- psd1 20d ago
  Everything is a trade-off. Would you never ever under any circumstances accept even trivial breakage, even if it fixes a horrible wart that costs thousands of lost hours?
- pseudocomposer 20d ago
  I agree with your sentiment, but at some point backwards compatibility has to break. Rust handles it better than basically anything out there. If it bothers you, you should never try any other language except maybe plain, no-framework JS. Plus, LLMs have really made upgrading a codebase for a compiler or dependency update into a trivial chore, at least for the most part.
- Analemma_ 20d ago
  It’s not actually true that your software gets done, that’s essentially impossible unless you’re doing some kind of performance art project targeting a defunct platform from decades ago. Operating systems and libraries change underneath you all the time, even if you’re just using Linux and glibc, and if you’re not keeping up eventually your software is the legacy code keeping people stuck on an insecure OS, like those businesses who have to keep one box running DOS because of some ancient device driver for their equipment. It’s better to plan for this in advance and use a stack where upgrades are done gracefully, rather than sticking your head in the sand and pretending it doesn’t happen.
- baq 20d ago
  The answer is to keep the compiler and the OS image it is running on alongside the source in version control. (Docker alone won’t save you.) Unless you just have an axe to grind?
  - jcelerier 20d ago
    > The answer is to keep the compiler and the OS image it is running on alongside the source in version control. really says a lot that someone can say this apparently absolutely seriously
    - baq 20d ago
      I was just lucky to have found an ancient rhel box when I desperately needed one. Luck is not a process.
      - jcelerier 20d ago
        I mean I understand that this can happen, my point is that we should code things in a way where the huge majority your code will still work no matter if you have an old rhel box or the latest archlinux, just like today we can port doom to pretty much any platform without too much trouble.
  - irishcoffee 20d ago
    It’s very amusing to me that rust is trying to achieve a safety critical certification. Whatever version of the compiler that gets the cert will be cemented for the next 20 years. Safety critical work / security-sensitive work is completely orthogonal to the rust release cycle. Not to mention the vast amount of professionals who don’t have root on their runners / build nodes. Putting a ticket in every 3-6 weeks for a new compiler version takes… 3-6 weeks. People give up after a while.
    - estebank 20d ago
      > Not to mention the vast amount of professionals who don’t have root on their runners / build nodes. Putting a ticket in every 3-6 weeks for a new compiler version takes… 3-6 weeks. People give up after a while. When I talked with the people at AWS responsible for updating both the myriad Java compilers in use as well as Rust for every project in the company, they claimed that updating Rust was always painless and didn't even appear as a blip in their radars compared to other similarly wide reaching updates.
- aiono 20d ago
  Because software is rarely done. Also you will likely to write newer programs with the same but improved language that doesn't have the warts in the earlier versions. Isn't it worth paying a small price for the improvement you get in the future?
- fl0ki 20d ago
  This isn't the only way a Rust stable update can break your compile. It can also happen simply because they add a symbol to the standard library, and that isn't even protected by language editions. https://predr.ag/blog/some-rust-breaking-changes-do-not-require-major-version/ https://predr.ag/blog/some-rust-breaking-changes-do-not-requ... "Never add anything" isn't a tenable position, and in practice the breakage hasn't been bad enough to need special treatment yet.
  - brabel 20d ago
    Oh not only to the stdlib but to any lib! I thought that was crazy when you mentioned it but after reading the post I agree it’s a pragmatic approach. By the way Java does the same! The problem can be avoided by avoiding “star imports” in both Java and Rust, and at least in Java star imports are very rarely used for this exact reason (I remember my horror when I couldn’t call a method of List that I knew existed and it turned out a “import java.awt.*;” was the reason, that was a pain to figure out before AI and convinced me to never use star imports again).
    - fl0ki 20d ago
      Star imports aren't the only way, traits are another. Say you impl two traits and they end up both adding a symbol with the same name. Or you bring in an extension trait impl for a standard library type, and now the standard library adds a symbol with the same name as one in the extension trait. To avoid those problems, you'd have to proactively disambiguate any item with its trait name, which is so un-ergonomic that people genuinely prefer the possibility of occasional breakage.
- slopinthebag 20d ago
  Your software is done, so why do you need to recompile it with a new version of the compiler? After all it’s done. Pin compiler version and problem solved. No limitless amount of future work.
  - jstimpfle 20d ago
    For the most part, software does not exist in a vacuum. If there is a serious bug, or much improved feature, in a library you depend on, what do you do? Most likely you'll try to upgrade the library. Same deal for the compiler, it's a huge dependency. If your project is truly done, by all means ship it on a N64 cartridge. I can't say I don't have sympathy for that attitude. But don't expect this is how the world works today. And don't forget, N64 cartridges weren't built using massive amounts of dependency, so it was easier to confidently declare something "done".
    - slopinthebag 20d ago
      Ok but if you have to update your software it’s not done, it’s dormant. And when it wakes up, it’s not like this is some massive change. It’s trivial and automatable.
Ygg2 21d ago
Like Python 2 vs 3? That's what Editions were created to fix. With backwards incompatibility you will get ecosystem breakage and looming threat of future compilers not compiling your code.
- estebank 20d ago
  The problem is that assuring no breaks ever with inference means you can't ever improve the inference algorithm nor update the stdlib. This is what triggered the time 0.35 breakage. I have a still incomplete/unmerged rustc lint to avoid the situation that caused that (a useless .into() that didn't get flagged because the clippy lint has false positives so it is not on by default) which should minimize the likelihood of that happening again (once I get off my ass and finish it, it just requires some side-quests to add more accurate tracking of cfg'd out items). This might be able to be mitigated by editions, but in practice crater helps to not need that (yet?). This is not the only kind of breakage a project can experience. Trying to bring up an older project on a new platform will be a compile error (like building a project from 2018 on an Mx Mac), and updating the appropriate dependency to an appropriate version might become a chore. I have no idea how to improve the situation there to make that less painful, beyond having a simple database of crate-version+platform+rustc-version so that the toolchain could provide better/actionable messaging beyond "shit's broken".
  - Ygg2 20d ago
    Not sure how that relates to the argument at hand. The argument that you should break compatibility for justifiable reasons. We know how that looks, and it's not good. See Scala and Python.
hahn-kev 20d ago
Yeah this is good. I feel like a language which never fixes a mistake ends up stuck. JS by it's nature can't fix things like this and it sucks. Thankfully Rust is compiled so this break is at compile time, and seems simple to fix. I wonder if their could even be an auto fix for it.

by srdjanr 21d ago

I like the pragmatic approach to backwards compatibility (accepting relatively rare breakage that's not too hard to fix) instead of requiring 100% compatibility without exceptions

geocar 21d ago

I don’t. My software gets done. The idea that it would suddenly not be done because the compiler upgraded sounds like a potentially limitless amount of future work. Why would I want to invest in something that promises that?

nixpulvis 21d ago
You could keep using the old compiler, no?
- Ygg2 21d ago
  Yes, but new compiler can't use old ecosystem crates. Hence the issue. Rust's edition system gives you the best of both worlds, with caveats. Some changes will be impossible.
psd1 20d ago
Everything is a trade-off. Would you never ever under any circumstances accept even trivial breakage, even if it fixes a horrible wart that costs thousands of lost hours?
pseudocomposer 20d ago
I agree with your sentiment, but at some point backwards compatibility has to break. Rust handles it better than basically anything out there. If it bothers you, you should never try any other language except maybe plain, no-framework JS. Plus, LLMs have really made upgrading a codebase for a compiler or dependency update into a trivial chore, at least for the most part.
Analemma_ 20d ago
It’s not actually true that your software gets done, that’s essentially impossible unless you’re doing some kind of performance art project targeting a defunct platform from decades ago. Operating systems and libraries change underneath you all the time, even if you’re just using Linux and glibc, and if you’re not keeping up eventually your software is the legacy code keeping people stuck on an insecure OS, like those businesses who have to keep one box running DOS because of some ancient device driver for their equipment. It’s better to plan for this in advance and use a stack where upgrades are done gracefully, rather than sticking your head in the sand and pretending it doesn’t happen.
baq 20d ago
The answer is to keep the compiler and the OS image it is running on alongside the source in version control. (Docker alone won’t save you.) Unless you just have an axe to grind?
- jcelerier 20d ago
  > The answer is to keep the compiler and the OS image it is running on alongside the source in version control. really says a lot that someone can say this apparently absolutely seriously
  - baq 20d ago
    I was just lucky to have found an ancient rhel box when I desperately needed one. Luck is not a process.
    - jcelerier 20d ago
      I mean I understand that this can happen, my point is that we should code things in a way where the huge majority your code will still work no matter if you have an old rhel box or the latest archlinux, just like today we can port doom to pretty much any platform without too much trouble.
- irishcoffee 20d ago
  It’s very amusing to me that rust is trying to achieve a safety critical certification. Whatever version of the compiler that gets the cert will be cemented for the next 20 years. Safety critical work / security-sensitive work is completely orthogonal to the rust release cycle. Not to mention the vast amount of professionals who don’t have root on their runners / build nodes. Putting a ticket in every 3-6 weeks for a new compiler version takes… 3-6 weeks. People give up after a while.
  - estebank 20d ago
    > Not to mention the vast amount of professionals who don’t have root on their runners / build nodes. Putting a ticket in every 3-6 weeks for a new compiler version takes… 3-6 weeks. People give up after a while. When I talked with the people at AWS responsible for updating both the myriad Java compilers in use as well as Rust for every project in the company, they claimed that updating Rust was always painless and didn't even appear as a blip in their radars compared to other similarly wide reaching updates.
aiono 20d ago
Because software is rarely done. Also you will likely to write newer programs with the same but improved language that doesn't have the warts in the earlier versions. Isn't it worth paying a small price for the improvement you get in the future?
fl0ki 20d ago
This isn't the only way a Rust stable update can break your compile. It can also happen simply because they add a symbol to the standard library, and that isn't even protected by language editions. https://predr.ag/blog/some-rust-breaking-changes-do-not-require-major-version/ https://predr.ag/blog/some-rust-breaking-changes-do-not-requ... "Never add anything" isn't a tenable position, and in practice the breakage hasn't been bad enough to need special treatment yet.
- brabel 20d ago
  Oh not only to the stdlib but to any lib! I thought that was crazy when you mentioned it but after reading the post I agree it’s a pragmatic approach. By the way Java does the same! The problem can be avoided by avoiding “star imports” in both Java and Rust, and at least in Java star imports are very rarely used for this exact reason (I remember my horror when I couldn’t call a method of List that I knew existed and it turned out a “import java.awt.*;” was the reason, that was a pain to figure out before AI and convinced me to never use star imports again).
  - fl0ki 20d ago
    Star imports aren't the only way, traits are another. Say you impl two traits and they end up both adding a symbol with the same name. Or you bring in an extension trait impl for a standard library type, and now the standard library adds a symbol with the same name as one in the extension trait. To avoid those problems, you'd have to proactively disambiguate any item with its trait name, which is so un-ergonomic that people genuinely prefer the possibility of occasional breakage.
slopinthebag 20d ago
Your software is done, so why do you need to recompile it with a new version of the compiler? After all it’s done. Pin compiler version and problem solved. No limitless amount of future work.
- jstimpfle 20d ago
  For the most part, software does not exist in a vacuum. If there is a serious bug, or much improved feature, in a library you depend on, what do you do? Most likely you'll try to upgrade the library. Same deal for the compiler, it's a huge dependency. If your project is truly done, by all means ship it on a N64 cartridge. I can't say I don't have sympathy for that attitude. But don't expect this is how the world works today. And don't forget, N64 cartridges weren't built using massive amounts of dependency, so it was easier to confidently declare something "done".
  - slopinthebag 20d ago
    Ok but if you have to update your software it’s not done, it’s dormant. And when it wakes up, it’s not like this is some massive change. It’s trivial and automatable.

Ygg2 21d ago

Like Python 2 vs 3? That's what Editions were created to fix. With backwards incompatibility you will get ecosystem breakage and looming threat of future compilers not compiling your code.

estebank 20d ago
The problem is that assuring no breaks ever with inference means you can't ever improve the inference algorithm nor update the stdlib. This is what triggered the time 0.35 breakage. I have a still incomplete/unmerged rustc lint to avoid the situation that caused that (a useless .into() that didn't get flagged because the clippy lint has false positives so it is not on by default) which should minimize the likelihood of that happening again (once I get off my ass and finish it, it just requires some side-quests to add more accurate tracking of cfg'd out items). This might be able to be mitigated by editions, but in practice crater helps to not need that (yet?). This is not the only kind of breakage a project can experience. Trying to bring up an older project on a new platform will be a compile error (like building a project from 2018 on an Mx Mac), and updating the appropriate dependency to an appropriate version might become a chore. I have no idea how to improve the situation there to make that less painful, beyond having a simple database of crate-version+platform+rustc-version so that the toolchain could provide better/actionable messaging beyond "shit's broken".
- Ygg2 20d ago
  Not sure how that relates to the argument at hand. The argument that you should break compatibility for justifiable reasons. We know how that looks, and it's not good. See Scala and Python.

hahn-kev 20d ago

Yeah this is good. I feel like a language which never fixes a mistake ends up stuck. JS by it's nature can't fix things like this and it sucks. Thankfully Rust is compiled so this break is at compile time, and seems simple to fix. I wonder if their could even be an auto fix for it.