[bbu]

>Do people allocate a certain amount of time just to upgrade Rails?

Is there a framework or technology that doesn't need constant maintenance? I feel like Rails is actually quite low maintenance. Major version changes are rare - Rails 6 was released in 2019.

[lmm]

Typed languages and explicit-over-implicit frameworks are much easier to upgrade. I worked on a large project based on Wicket and we would curse the library developers for making their classes "final" so we had to copy-paste rather than subclassing, but the result was that even major version upgrades were completely routine and painless.

[square_usual]

Java being typed hasn't helped my company move on from Java 8 :'(

[lmm]

The blockers tend to be the parts of "Java" that aren't actually Java and aren't typed, such as Spring or Hibernate. Blaming Java for that is correct - there's no point having a typed language if it's so inexpressive that people layer untyped hacks on top of it in order to be able to actually do anything - but blaming types is a mistake; if you use a language that is properly typed without compromising expressiveness (i.e. an ML-family language in the broad sense) then you can genuinely get that ease of upgrade because you don't have to step outside the language to get things done.

[unscaled]

Moving from Java 8 to Java 11 or even Java 17 is surprisingly simple. Most of the work is just upgrading libraries which use internal JDK features or rely on brittle reflection/bytecode hacks.

Java is a specifically strange beast here. With many modern typed languages, a major version upgrade will require you to modify small parts of your code, as the compiler becomes stricter or small parts of the syntax change.

Java is more like C and C++, in that it tries very hard to maintain language level compatibility. On the other, library compatibility is a bigger mess in Java, because the language was pretty stagnant for such a long time, and library authors got used to a very slow upgrade pace. This meant many libraries and tools chose to rely on internal JDK implementation details or perform bytecode wizardry which stopped working with new versions. Java 9 also moved a lot of interfaces which were not an official part of the Java SE spec (like all of Java EE) to external artifacts which you needed to add as dependencies.

Another extreme point of incompatibility was very silly: libraries were making assumptions parsing the Java version string: up until Java 8, the version string had the format "1.x", where x is the major version (Java 8 was "1.8"). Starting from Java 9, there was no phantom "1." prefix coming before the major version anymore, so Java 9 was just "9". This broke a lot of libraries which would have been compatible otherwise.

Library maintainers were unprepared for the rather small changes Java 9 has made, and took quite some time to upgrade, especially huge frameworks like Spring. It took Spring 6 months to support Java 9 after it became GA, but Java 17 was fully supported 3 months before it was released![1]

If you have to upgrade from Java 8 to Java 17 now, there is nearly zero friction if your libraries support it and upgrading the libraries is easy. You'd barely need to touch your own code. If any changes are forced on you, that's usually the libraries, but then neither Java nor static typing is to blame.

And honestly I think it's quite easy to upgrade. In my experience, Java shops just tend to be more conservative than the industry average.

[1] https://twitter.com/snicoll/status/1420652097373188100

[dustymcp]

Still need effort to move larger codebases No matter what people say..

[michaelcampbell]

Is that a Java issue, a typing issue, or a company issue?

[subsection1h]

Go 1.x is around 9.5 years old, and many Go developers write software using mostly the standard library without any framework.

[Zababa]

> using mostly the standard library without any framework

I don't think that's totally true. Without any framework, maybe, but mostly the standard library? I'm not sure. People use a lot of libraries, and these may not have the same guarantees as Go itself.

[rtcoms]

Comparing language with the framwork, even if you want to better compare it with Sinatra then