| |
| ▲ | gf000 29 minutes ago | parent | next [-] | | Sure, though most of the time it's library-only, not language change (with the only exception I have in mind is new keywords, but those are pretty rare with java). All in all, Java is pretty unique in the level of backwards compatibility it provides, I don't think any other language is comparable to this level. Especially that it is both source and binary compatibility. | | |
| ▲ | kibwen 11 minutes ago | parent [-] | | > Sure, though most of the time it's library-only, not language change While this distinction is often useful, here we have to think about it from the perspective of users: you press the button to upgrade your toolchain, and code that formerly worked stops working. If a language supported upgrading your compiler/interpreter separately from your standard library then that would be different, but generally a standard library version is considered tightly coupled to a language version. |
| |
| ▲ | pdpi 2 hours ago | parent | prev [-] | | Not that I need to tell you of all people, but I do find that Rust's editions system is one of the better ways to minimise this issue. | | |
| ▲ | kibwen 2 hours ago | parent [-] | | Indeed, editions are brilliant for making relatively large changes in a way that fully preserves backwards compatibility for codebases in the wild, but the existence of editions doesn't mean that Rust is exempt from sometimes desiring to make minor breaking changes in new versions for all editions. For that, it has the mechanism of future incompatibility lints, to give people ample advance warning: https://doc.rust-lang.org/rustc/lints/index.html#future-inco... |
|
|