Earlier quoted context omitted.
universal null type safety has sadly been discarded as a core concept of Valhalla in my Understanding; that being said, the proposals in Valhalla have null-safety as a side effect, but only under certain conditions.
When (if) null safety ships, I‘m not sure I can justify using Kotlin any longer. Java simply got too nice.
Java 27
71–80 of 423 posts
Re: Java 27
#72Earlier quoted context omitted.
When building boring web applications with a sizeable team that need to run for a long time. Hiring developers is easy since there are many, there is nearly no magic and the language is quite strict and type safe so it works well with a large team. And that "team" nowadays may also consist of many AI agents. In my experience Claude Code for example works very well with a typed, slightly boring language with lots of f…
> there is nearly no magic I agree with the rest, but there's definitely a lot of magic in Java. This is from both what features the languages makes available (many) and how the community uses them (often). I've had so many hard-to-debug issues in Java over the years due to reflection, annotations, and bytecode manipulation shenanigans. And another positive point for Java: checked exceptions. It's verbose, but knowin…
I've worked on Java apps that have failed in mysterious ways that no exception could explain. Meanwhile, the overhead of having to call out certain exceptions but not others in language syntax is a bit excessive.
For example, decoding a byte array (or URL encoded form field) into a UTF-8 string means handling a theoretical UnsupportedEncodingException. What the fuck? How the hell can one have a JVM that doesn't support UTF-8? Why does my code need boilerplate that will never run because there might be some broken-ass JVM out there that that doesn't support UTF-8? How did it launch a web server, safely load all the libraries, and accept a web request, and route it to my code without blowing up? "But the encoding scheme might change..." No, it won't change. It's always going to be UTF-8. It will always be UTF-8. If it's not, let it blow up.
Re: Java 27
#73Earlier quoted context omitted.
> there is nearly no magic I agree with the rest, but there's definitely a lot of magic in Java. This is from both what features the languages makes available (many) and how the community uses them (often). I've had so many hard-to-debug issues in Java over the years due to reflection, annotations, and bytecode manipulation shenanigans. And another positive point for Java: checked exceptions. It's verbose, but knowin…
I haven't really been in the java space for a while now, but I recall there being a fair bit of criticism[1][2] of checked exceptions over the years. [1] https://www.javacodegeeks.com/2026/01/javas-checked-exceptio... [2] https://reflectoring.io/do-not-use-checked-exceptions/ WRT magic, I've generally thought that was a result of frameworks - Spring, for example. In the past, my feeling was that these impose a sort o…
Many times I've decided to switch from one function to another, or even an entirely new library, because the checked exceptions told me that it was doing far more than I expected, and I was not comfortable introducing those new failure modes.
It's far from perfect, one still has to handle nulls and wrapped/merged exceptions, but overall I like this language feature.
Re: Java 27
#74Earlier quoted context omitted.
I never thought of Java being the 'move fast ~and break things~' alternative over .NET, but Java has a faster release schedule to get features out sooner.
Seriously, how many are using always the latest releases of Java instead the LTS ones? With LTS ones you have ~2/3 years between the versions.
It may be that we are shielded from edge cases because we are based on Spring, which is probably the most tested piece of software before new versions of Java are released. But it's my impression that the risk of upgrading to a new version of Java is not the same today as it was in the past. The only advantage of an LTS is that it is supported longer, so that you can postpone the upgrade if you really want. It's not as if the intermediate releases are inferior or less safe.
Re: Java 27
#75Serious question: when should one use Java for greenfield projects in 2026?
Whoever works with, or chooses Java, is not doing it for the language itself, be it beautiful or not. Java has a huge ecosystem, from battle tested integrations to optimized images to build pipelines to whatever, so at the same you're buying access to all this world (yes, more than an environment). And of course transferable skills. I'm not saying Java is alone offering this, also not saying every feature is the best…
And if you are starting from scratch, whatever part of the ecosystem you use, I'm not optimist on its situation improving with time.
Re: Java 27
#76Serious question: when should one use Java for greenfield projects in 2026?
Java & Spring is a good choice whenever you want your application to work and be maintainable 10 years from now, without having to replace the framework and half of the libraries you used. I see few good reasons to ever use something with unstable ecosystem (like Javascript with NodeJS) over Java these days.
Re: Java 27
#77C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and I’m guessing this is a function of the much larger Java audience: things rarely get two preview versions in a proper release. Updates in beta versions, yes, all the time. It also feels like Microsoft are bundling a lot more into the platform and leaving less…
Re: Java 27
#78Serious question: when should one use Java for greenfield projects in 2026?
Java & Spring is a good choice whenever you want your application to work and be maintainable 10 years from now, without having to replace the framework and half of the libraries you used. I see few good reasons to ever use something with unstable ecosystem (like Javascript with NodeJS) over Java these days.
I guess I'm asking this as an open question: Where are we in the "move fast vs stable" spectrum with Node these days? Definitely not rock solid, but it's moving in that direction I feel.
Re: Java 27
#79Earlier quoted context omitted.
If someone wants to create a project by assembling bits and pieces from different open source products they can, but many just go for Spring (Boot) and call it a day. All of my projects are based on Spring and I don't really have to look outside of that ecosystem. It almost acts as an aggregator of different open source solutions and often works by abstracting the functionality so that differences are not that big. I…
Yep, with Spring Boot development is so easy, and even decade old projects are mostly easy to upgrade. I don't have experience from C# or .NET development, but at least compared to Python and especially JS ecosystems it's so much better.
That's a pretty low bar to beat.
Re: Java 27
#80Earlier quoted context omitted.
Golang gives you none of nice features of a modern language while being about the same performance tier as Scala or Java, so there's basically no reason not to use Scala.
Golang is faster and use way less memory than Java, never wonder why you never see Kubernetes controller / sidecar is Java? As for Scala it's pretty much a dead language, no one work with it and it's impossible to find dev for it. 10 years ago I was moving Scala code back to regular Java.
I think it used to be common to just look for smart people and assume they can run with whatever stack. Wasn't that the point of abstract algorithm questions etc. (basically an IQ test)?