5 ms·

> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when t

> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain. I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard. I would much rather go through the easy process of switching to an older Rust tool chain to build something than all of the games we played to keep entire VMs archived with a snapshot of a vendor tool chain that worked to build something.

whiatp 6mo ago
I remember a coworker having to fight with an old platform's build not working because our user/group IDs were bigger than 2^16. I can't remember which utility was causing the problem, I'd have to guess tar. This is when we learned to play the archive a VM game.
- butvacuum 6mo ago
  I can't imagine theres much overlap between "we will need to update this firmware for the next decade." and "Let's bet the farm on the documentation being perfect, and all the downloads still available."
- cyberpunk 6mo ago
  I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax. They had some great stories trying to get something or other running again where they had to fly one of the original designers over to hand solder a board back into action. How we do that today is a bit of an interesting problem I don’t think they’ve convincingly solved; basically maintaining nightly builds forever — a couple 1U’s of kubernetes in deep storage ain’t gonna do it, you’re not gonna be able to solder a xeon back to life.. I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust.
  - jitler 6mo ago
    > I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax. So uh, will these ever make it to an auction site you think?
    - shrubble 6mo ago
      I have an Acer Chromebook with Celeron N3060 CPU and it runs the SIMH VAX emulator with 64MB for the VAX at the same speed as a Vaxstation 4000/60 and likely the disk is much faster. I like OpenVMS and am slowly learning more about it; no reason to wait until you see those hit eBay :-)
  - IshKebab 6mo ago
    > I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust. Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years. C is an absolute nightmare in comparison. I tried to compile some old C code I had for Nordic nRF51 chips, only a few years after the chips became available. I gave up. Broken links, missing documentation, etc. etc. I can see why other people here are saying it's standard practice to archive a VM. Not really necessary for Rust.
    - cyberpunk 6mo ago
      shrug I guess we have different experiences. Any even small sized rust application I've come across rivals nodejs for amount of deps it pulls in. Sure, just vendor them in, simples, right?
      - IshKebab 6mo ago
        You could do (it is simple), but all the code is stored on crates.io so there's no real need. An exception is for crates that wrap C code which might get the code from elsewhere but those are quite rare.
deleted 6mo ago
[deleted]
LtWorf 6mo ago
> You can still use the same old toolchain. Unless you find out the compiler was buggy and was producing faulty binaries, but the new compiler can no longer compile the old code.
- tredre3 6mo ago
  What you are describing happens all the time. Usually the toolchain provider will continue updating a list of known issues for some time after EOL. Beyond that you have third parties that do it for decades, if the platform is big enough. They collect bug reports from the industry, investigate them, then create lists that you subscribe to. Those lists include detailed examples, explanations, and usually linter rules to detect code that could trigger the bug. The truth is: If the toolchain was good enough to ship your product, has time to go EOL, and then you do a patch that surfaces an esoteric toolchain bug, then the odds are that you'll know exactly what triggered the bug and you can work around it by writing different code. Because even if the newer shinier compiler/toolchain had the issue fixed, most companies wouldn't upgrade to it at that point. It's almost never desirable to change your toolchain for a shipping product, you're just introducing more unknowns.
  - dwattttt 6mo ago
    > Because even if the newer shinier compiler/toolchain had the issue fixed, most companies wouldn't upgrade to it at that point. It's almost never desirable to change your toolchain for a shipping product, you're just introducing more unknowns. This reaction to toolchain stability is quite defensive, and was needed for C, but isn't universally needed. C toolchain updates could break your product because of how loose the C language can be; I've had code that had benign undefined behaviour, until a toolchain update brought in an optimisation that broke it. Another outcome of a toolchain update could be "no bugs introduced, existing bugs in your codebase now found by diagnostics".
- adrianN 6mo ago
  Coding around compiler bugs is pretty standard practice in usecases where you have some random vendor compiler that is based on some ancient gcc if you’re lucky or completely in-house if you’re not.
hulitu 6mo ago
> You can still use the same old toolchain. If you keep your old computer around, yes. The good news is that C seems also contaminated with "move fast, break things " phylosophy. The modern code writer is not able to make things that last more than a couple of months.
- sli 6mo ago
  Previous versions of the Rust compiler don't just up and disappear just because I moved to a new workstation or setup a new build server. I understand it's not optimal to rely on a download always being available, but even then, that is not at all exclusive to any single language. Why would earlier versions of Rust be susceptible to this but not something like gcc? I don't see it.
deleted 6mo ago
[deleted]
avadodin 6mo ago
People work supporting past embedded codebases and developing new code intended to run on them for decades. If the toolchain moves on, the product is suck on whatever architecture and developers are stuck running an emulator/docker of some particular vintage of Debian sid.

whiatp 6mo ago

I remember a coworker having to fight with an old platform's build not working because our user/group IDs were bigger than 2^16. I can't remember which utility was causing the problem, I'd have to guess tar. This is when we learned to play the archive a VM game.

butvacuum 6mo ago
I can't imagine theres much overlap between "we will need to update this firmware for the next decade." and "Let's bet the farm on the documentation being perfect, and all the downloads still available."
cyberpunk 6mo ago
I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax. They had some great stories trying to get something or other running again where they had to fly one of the original designers over to hand solder a board back into action. How we do that today is a bit of an interesting problem I don’t think they’ve convincingly solved; basically maintaining nightly builds forever — a couple 1U’s of kubernetes in deep storage ain’t gonna do it, you’re not gonna be able to solder a xeon back to life.. I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust.
- jitler 6mo ago
  > I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax. So uh, will these ever make it to an auction site you think?
  - shrubble 6mo ago
    I have an Acer Chromebook with Celeron N3060 CPU and it runs the SIMH VAX emulator with 64MB for the VAX at the same speed as a Vaxstation 4000/60 and likely the disk is much faster. I like OpenVMS and am slowly learning more about it; no reason to wait until you see those hit eBay :-)
- IshKebab 6mo ago
  > I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust. Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years. C is an absolute nightmare in comparison. I tried to compile some old C code I had for Nordic nRF51 chips, only a few years after the chips became available. I gave up. Broken links, missing documentation, etc. etc. I can see why other people here are saying it's standard practice to archive a VM. Not really necessary for Rust.
  - cyberpunk 6mo ago
    shrug I guess we have different experiences. Any even small sized rust application I've come across rivals nodejs for amount of deps it pulls in. Sure, just vendor them in, simples, right?
    - IshKebab 6mo ago
      You could do (it is simple), but all the code is stored on crates.io so there's no real need. An exception is for crates that wrap C code which might get the code from elsewhere but those are quite rare.

deleted 6mo ago

[deleted]

LtWorf 6mo ago

> You can still use the same old toolchain. Unless you find out the compiler was buggy and was producing faulty binaries, but the new compiler can no longer compile the old code.

tredre3 6mo ago
What you are describing happens all the time. Usually the toolchain provider will continue updating a list of known issues for some time after EOL. Beyond that you have third parties that do it for decades, if the platform is big enough. They collect bug reports from the industry, investigate them, then create lists that you subscribe to. Those lists include detailed examples, explanations, and usually linter rules to detect code that could trigger the bug. The truth is: If the toolchain was good enough to ship your product, has time to go EOL, and then you do a patch that surfaces an esoteric toolchain bug, then the odds are that you'll know exactly what triggered the bug and you can work around it by writing different code. Because even if the newer shinier compiler/toolchain had the issue fixed, most companies wouldn't upgrade to it at that point. It's almost never desirable to change your toolchain for a shipping product, you're just introducing more unknowns.
- dwattttt 6mo ago
  > Because even if the newer shinier compiler/toolchain had the issue fixed, most companies wouldn't upgrade to it at that point. It's almost never desirable to change your toolchain for a shipping product, you're just introducing more unknowns. This reaction to toolchain stability is quite defensive, and was needed for C, but isn't universally needed. C toolchain updates could break your product because of how loose the C language can be; I've had code that had benign undefined behaviour, until a toolchain update brought in an optimisation that broke it. Another outcome of a toolchain update could be "no bugs introduced, existing bugs in your codebase now found by diagnostics".
adrianN 6mo ago
Coding around compiler bugs is pretty standard practice in usecases where you have some random vendor compiler that is based on some ancient gcc if you’re lucky or completely in-house if you’re not.

hulitu 6mo ago

> You can still use the same old toolchain. If you keep your old computer around, yes. The good news is that C seems also contaminated with "move fast, break things " phylosophy. The modern code writer is not able to make things that last more than a couple of months.

sli 6mo ago
Previous versions of the Rust compiler don't just up and disappear just because I moved to a new workstation or setup a new build server. I understand it's not optimal to rely on a download always being available, but even then, that is not at all exclusive to any single language. Why would earlier versions of Rust be susceptible to this but not something like gcc? I don't see it.

deleted 6mo ago

[deleted]

avadodin 6mo ago

People work supporting past embedded codebases and developing new code intended to run on them for decades. If the toolchain moves on, the product is suck on whatever architecture and developers are stuck running an emulator/docker of some particular vintage of Debian sid.