zlacker

[parent] [thread] 2 comments
1. drzaiu+(OP)[view] [source] 2025-11-20 13:47:46
I feel like time and again language designers don't properly uphold backwards compatibility as a high enough priority, to their and their users detriment.

My team has recently ported 14 Ruby services along with over 50 separate Gem libraries from ruby2 to ruby3 where THEY CHANGED HOW FUNCTIONS INTERPRET ARGUMENTS! Older code run on newer runtimes _change behavior_ for the same code by treating splatted arguments differently, which was _very_ annoying to figure out and reason over for codebases that _heavily_ used '*' splatted arguments.

I feel like folks need to take page from Java's book and maintain backwards compatibility as a core tenet of their language. I've done perl4 -> perl5 -> raku, python2 -> python3, ruby2 -> ruby3, and rewriten a handful of c++, rust and node applications because everything in those landscapes seems to be in constant flux...

I just want to write software that will continue to work after it's been written, without having to use an older CVE-ridden language runtime every time. From personal experience, only java seems to 'get it.' (I'm sure there are others that do get it, but sadly I've had little opportunity to use them.)

replies(1): >>josefx+WY2
2. josefx+WY2[view] [source] 2025-11-21 12:42:09
>>drzaiu+(OP)
> from Java's book and maintain backwards compatibility

Didn't they start breaking things between Java 8 and 9? Modules, Reflection Access, JavaEE, ... .

replies(1): >>drzaiu+Wi3
◧◩
3. drzaiu+Wi3[view] [source] [discussion] 2025-11-21 15:01:01
>>josefx+WY2
Nope, the closest thing to a a breaking javalang change is adding new keywords like var. Outside of the language itself, java's standard libraries have undergone some depreciations and packaging moves (moving javafx, etc.), but absolutely nothing like breaking core language constructs, syntax or behaviors across revisions. I would expect standard libraries to have some deprecations across a 20+ year span.

However, I'm of the opinion that "standard libraries" should be much more minimalist and than javas: move as much as you can into a "core" library that isn't necessarily part of the language, just an optional runtime component following semver so you can be sure pinning a major version will work for essentially forever. Java isn't perfect in this regard, but it sure as hell better than what perl, ruby and python have done in significantly less time than javas...

[go to top]