241–250 of 427 posts
Serious question: when should one use Java for greenfield projects in 2026?
When you work at a Java shop. Kotlin is much nicer if you have to run on the JVM but aren't restricted to Java.
Serious question: when should one use Java for greenfield projects in 2026?
C# 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…
Polyglot dev here, that uses both ecosystems, Java since 1996, .NET before it was announced to the public in 2001, only available to selected Microsoft partners. A big difference between both ecosystems is that the Java world is like C and C++, even though Java isn't defined by ISO or ECMA, since Sun days the main implementation is only a reference, there are official documents for everything, and there is a plethora…
Serious question: when should one use Java for greenfield projects in 2026?
Earlier quoted context omitted.
Why not Go, Rust, or C#?
Go and Rust have much worse tooling for enterprise-level collaboration
I'm not sure what kind of tools you mean, but unless you're looking for something that just works exactly the way EJBs do for some mysterious reasons, I don't see why you can't do most "enterprisey" things with Rust or Go. Or Python or TypeScript for that matter.
Earlier quoted context omitted.
Can I trust code I’ve written myself with no guarantees from the language? Maybe. Can I trust code written by dozens of other developers (and/or agents) working on the same project over multiple years? Definitely not.
Why don't you have any coding standards? If you're working with agents in particular, catching and enforcing this stuff should be easier than ever.
I just don't see why nullability is a problem in the first place.
Earlier quoted context omitted.
Most engineers don't get to decide to use a language either. Usually someone with the clout to pick a language has the clout to set style requirements too.
They do get to decide which jobs they take. And the languages involved are one of the easiest filters. A lot easier than checking whether the code a company actually writes is any good. Theoretically you don’t need to write AbstractFactoryProvider in Java, but looking at languages mentioned in job offers, I have a pretty good idea of which of them have a high probability of working with such code and which do not, ev…
Earlier quoted context omitted.
> First off, Oracle are doing versions at approximately twice the cadence Is that actually a good thing? But Oracle started playing a game, for better or worse, where they decided to couple the "language version" with a single specific runtime's release schedule. For example, in "Java 27" there are exactly 0 language changes and 1 minor feature addition to the TLS library. Everything else is OpenJDK runtime internals…
The Java language and runtime have been co-designed as a unified platform for many years now. Virtually every significant feature has language, library, and VM people working on it, and we often don't even know when we start how much of the feature would be in the language, library, or VM. Consequently, there is no "language version" or a "runtime version". There's only a platform version, which is defined in a singl…
Earlier quoted context omitted.
> Java has a faster release schedule to get features out sooner While still being behind on most features?
Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads and structured concurrency, is getting value types, and even type classes in the work.
Earlier quoted context omitted.
When (if) null safety ships, I‘m not sure I can justify using Kotlin any longer. Java simply got too nice.
Multiplatform and Compose come to mind as Kotlin differentiators. I agree rest of the language actually slowly falls behind