not changing working code to prevent issues is unsafe.
we can go in circles all day with blanket statements that are all true. but we have ample evidence that even if we think some real-world C code is safe, it is often not because humans are extremely bad at writing safe C.
sometimes it's worth preventing that more strongly, sometimes it's not, evidently they think that software that a truly gigantic amount of humans and machines use is an area where it's worth the cost.
believing that rewriting to rust will make code safe is unsafe)
Of course it will be safer, but not safe. Safety is a marketing feature of rust and no more. But a lot of people really believe in it and will be zealously trying to prove that rust is safe.
A test will never catch every bug, otherwise it's a proof, and any change has the probability to introduce a new bug, irregardless of how careful you are. Thus, changing correct code will eventually result in incorrect code.
not changing working code to prevent issues is unsafe.
we can go in circles all day with blanket statements that are all true. but we have ample evidence that even if we think some real-world C code is safe, it is often not because humans are extremely bad at writing safe C.
sometimes it's worth preventing that more strongly, sometimes it's not, evidently they think that software that a truly gigantic amount of humans and machines use is an area where it's worth the cost.
believing that rewriting to rust will make code safe is unsafe) Of course it will be safer, but not safe. Safety is a marketing feature of rust and no more. But a lot of people really believe in it and will be zealously trying to prove that rust is safe.
If the code is brittle to change, it must not have been particularly safe in the first place, right?
And if it's well-tested, maybe that condition is achieved by the use of a test suite which could verify the changes are safe too?
A test will never catch every bug, otherwise it's a proof, and any change has the probability to introduce a new bug, irregardless of how careful you are. Thus, changing correct code will eventually result in incorrect code.
I'm not sure if that's how probability works.
I mean if you want Git to never change you're free to stick with the current version forever. I'm sure that will work well.
I obviously don’t think that is wise, but Git is literally designed with this in mind: https://git-scm.com/docs/repository-version/2.39.0
Just like SQLite has an explicit compatibility guarantee through 2050. You literally do not have to update if you do not want to.
And it’s still a choice you can make regardless of Git moving to Rust or not, so what’s the problem?
This is the repo format version.
It's pretty different from the git version, which receives new releases all the time for things like security patches, improvements, and new features.