Except when you have to make iOS/Windows/Linux specific instructions to get it working haha.
We have the joke at work where it almost works all the time. As long as the base OS is the same. Also random updates to libraries that break the docker container. But thats less on Docker and more on base OS images that are provided (im looking at you Ubuntu and your “new” sudo…).
Ubuntu is removing core utils and replacing them with supposedly plug and play replacements that work exactly the same. In practice its already breaking some builds ( https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Makeself ), which is unfortunate. I dont care if core utils are rust or not to be honest. But I DO want things to be rock solid stable in our environment.
There are MANY articles on techrights.org on rust and Microsoft as well, but I don’t know enough about the subject to verify any of the claims other than Microsoft seems to have a interest in getting people to use rust more. They are one of their biggest backers. And it would be unfortunate if yet another open source project becomes…influenced by MS and their needs.
If I had to guess it’s because Microsoft wants the memory protections that rust gives. Which would make windows more stable and less hackable? Meaning more money
I had success running unit tests for software deployments in pairs, one with pinned versions (error on a failed build) and one unpinned (warning on a failed build)
so at least you get forewarning when an upstream dependency messes everything up, and if the software changes are somewhat regular than each log of pipeline runs should show incremental changes making it easier to spot the package that started breaking everything
Oh yeah those are fun. Ive come across projects just 6 months after creation that cant work if they have a small version update. So it just sits there for a LONG time before a senior dev (mostly me) decides to get grumpy and fix the dang thing.
CI/CD builds can help…but you have to have someone keep an eye out for potential issues and, in best case, have a development deploy actually test the dang things.
Except when you have to make iOS/Windows/Linux specific instructions to get it working haha.
We have the joke at work where it almost works all the time. As long as the base OS is the same. Also random updates to libraries that break the docker container. But thats less on Docker and more on base OS images that are provided (im looking at you Ubuntu and your “new” sudo…).
Wait what did I miss, Ubuntu changed sudo for the sake of changing sudo?
Its a good question.
This bit me when we tried to use it via a beta build: https://www.omgubuntu.co.uk/2025/05/ubuntu-25-10-rust-sudo-rs-change
Ubuntu is removing core utils and replacing them with supposedly plug and play replacements that work exactly the same. In practice its already breaking some builds ( https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Makeself ), which is unfortunate. I dont care if core utils are rust or not to be honest. But I DO want things to be rock solid stable in our environment.
There are MANY articles on techrights.org on rust and Microsoft as well, but I don’t know enough about the subject to verify any of the claims other than Microsoft seems to have a interest in getting people to use rust more. They are one of their biggest backers. And it would be unfortunate if yet another open source project becomes…influenced by MS and their needs.
If I had to guess it’s because Microsoft wants the memory protections that rust gives. Which would make windows more stable and less hackable? Meaning more money
I mean, I guess it’s more money if it’s better. But turning the goal of being more stable and less hackable into something insidious seems weird.
And the discussion on whether or not to pin versions.
Pinned, these packages work together, but don’t automatically pull in security updates.
Don’t pin, things randomly change on each build, best of luck debugging things.
I had success running unit tests for software deployments in pairs, one with pinned versions (error on a failed build) and one unpinned (warning on a failed build)
so at least you get forewarning when an upstream dependency messes everything up, and if the software changes are somewhat regular than each log of pipeline runs should show incremental changes making it easier to spot the package that started breaking everything
Pin API / ABI versions.
If you’re able to track that…
Oh yeah those are fun. Ive come across projects just 6 months after creation that cant work if they have a small version update. So it just sits there for a LONG time before a senior dev (mostly me) decides to get grumpy and fix the dang thing.
CI/CD builds can help…but you have to have someone keep an eye out for potential issues and, in best case, have a development deploy actually test the dang things.