3 ms·

Backward compatibility (in terms of successful compilation) is never absolute. It's just Rust makes it very rare, and usually justifiable (say, fixing sound iss

Backward compatibility (in terms of successful compilation) is never absolute. It's just Rust makes it very rare, and usually justifiable (say, fixing sound issue), while still allows making good progress. In this case, it's an inference change, which is easily fixable. Inference breakage is explicitly allowed in Rust compiler policy. You won't get any new methods in standard library if you want absolute backward compatibility.

quohort 2y ago
I think that in an ecosystem that's more standardized like C or C++, you will have better backwards compatibility because compilers are written to the standard rather than the other way around. I look forward to the time when rust gets a GCC-based compiler, as it will force the language to become more standardized. I think that rust will eventually ossify. But for now it is good to have some time to learn the language before it's widely relied upon, and to for the language to make reverse-incompatible changes and improve. I think the whole benefit of rust in the first place is that it is able to improve upon C/C++'s design while being able to make reverse-incompatible changes with hindsight.
- seanhunter 2y ago
  In my (too long) experience of C and C++ this is absolutely not the case. New compiler versions are much more frequent than new language standards and frequently will barf on existing code when you make an upgrade. Usually when it happens it will be because of some unsafe/undefined/broken edge case that noone thought of before so some (evil) developer relied on it and then the subsequent compiler writer figured out how to detect and warn/error on. The whole premise of the article seems weird to me. "New compiler detects problem in old code" doesn't seem like a bug to me especially if the breakage is caused by type inference. If you want the ci/cd to not change in any way then you need to build in an environment which doesn't update in any way.
  - quohort 2y ago
    >If you want the ci/cd to not change in any way then you need to build in an environment which doesn't update in any way. Necroing this, but what would it take to ensure forward-compatibility of rust like this?

quohort 2y ago

I think that in an ecosystem that's more standardized like C or C++, you will have better backwards compatibility because compilers are written to the standard rather than the other way around. I look forward to the time when rust gets a GCC-based compiler, as it will force the language to become more standardized. I think that rust will eventually ossify. But for now it is good to have some time to learn the language before it's widely relied upon, and to for the language to make reverse-incompatible changes and improve. I think the whole benefit of rust in the first place is that it is able to improve upon C/C++'s design while being able to make reverse-incompatible changes with hindsight.

seanhunter 2y ago
In my (too long) experience of C and C++ this is absolutely not the case. New compiler versions are much more frequent than new language standards and frequently will barf on existing code when you make an upgrade. Usually when it happens it will be because of some unsafe/undefined/broken edge case that noone thought of before so some (evil) developer relied on it and then the subsequent compiler writer figured out how to detect and warn/error on. The whole premise of the article seems weird to me. "New compiler detects problem in old code" doesn't seem like a bug to me especially if the breakage is caused by type inference. If you want the ci/cd to not change in any way then you need to build in an environment which doesn't update in any way.
- quohort 2y ago
  >If you want the ci/cd to not change in any way then you need to build in an environment which doesn't update in any way. Necroing this, but what would it take to ensure forward-compatibility of rust like this?