5 ms·

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

by geocar 4d 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?

slopinthebag 3d 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 3d 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 3d 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.
nixpulvis 4d ago
You could keep using the old compiler, no?
- Ygg2 3d 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 3d 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 3d 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_ 3d 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 3d 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 3d 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 3d ago
    I was just lucky to have found an ancient rhel box when I desperately needed one. Luck is not a process.
    - jcelerier 3d 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 3d 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 3d 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 3d 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 3d 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 3d 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 3d 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.

by geocar 4d ago

slopinthebag 3d 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 3d 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 3d 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.

nixpulvis 4d ago

You could keep using the old compiler, no?

Ygg2 3d 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 3d 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 3d 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_ 3d 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 3d 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 3d 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 3d ago
  I was just lucky to have found an ancient rhel box when I desperately needed one. Luck is not a process.
  - jcelerier 3d 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 3d 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 3d 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 3d 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 3d 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 3d 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 3d 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.