I started programming when Java 6 was relatively new. Back then it was about 3-4 years in between releases. Although I don’t write much Java any more, I’m happy to see changes shipping more frequently now.

Up to a point.

Embedded systems versions tend to have their own ways, which is why despite everything Android using Dex isn't a first in the Java ecosystem.

10 years ago I was working at a place that was building Python systems that had dependency graphs too complicated for pip to handle. I was able to solve the problem for my system with a "wheelhouse" system that could compute a list of wheels that could be installed to build it but the confidence of my team in Python had flagged.

I had a sheaf of notes about the problem and figured out the math to build a proper dependency resolver for Python and tested out a lot of ideas such as being able to use http range requests to get the metadata out of wheels on PyPi without having to download the whole wheel.

The problem I had no solution for though was "how to stop developers from trashing the environment that the dependency manager runs in." The data scientists I worked with had an astonishing target for wrecking anything at all. Myself I would have my poetry's environment got bad for reasons I didn't understand every few months ago.

I also found the Python community just didn't care that pip didn't really work right. The most seductive form of blub is "I can accept using things that fail intermittently." I got a job coding Java and Javascript and never built the package manager.

Then uv came along and managed to sell itself as "crazy fast" which did connect with people more than "correct". Written in rust, uv would have beaten my system in the fast department, and since it is a binary, there is no way anyone can screw up a Python it depends on -- as I see it, both technical and marketing genius!

Value types are scheduled to be in preview next release (6 months). And C# does not have type classes.

At the same time, all this syntactic sugar makes the language's surface area gigantic. Like it's almost C++-level complex, and then you would have to properly understand all the interactions between this matrix of features.

That's absolutely a valid language design and many people prefer that, but I personally prefer a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do.

(And then there is also Go that falls off the other edge of the cliff with useless if err checks spamming the code making actually functioning error handling hard)

> Proper IEnumerable with proper iterators that in turn enables Linq

Are you referring to generators?

> Properties

As far as I'm aware, it is a deliberate choice not to implement them, and I can see their point of view.

> object initialisers

I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen.

> extension methods

Typeclasses are currently being explored, which are a superior approach.

> named and optional arguments in functions

Those would be nice (at least named arguments). I can see how optional arguments could complicate things.

> generics over primitive types

As you mentioned, it's in the works

> async/await... verbiage could still probably be hidden behind a friendlier syntax

The approach they took does not need any extra syntax.

Good list.

- Value types is a huge one to add if we're looking at what is actually in the wild.

- Scopeless `using` declarations are nice for RAII like behavior.

- IMO C# builds are actually way way nicer than Java. Sln and .csproj files and nuget are actually a lot easier to deal with than javac/ant/mvn/Gradle. Maybe that's more a .NET thing than a C# feature.

> - object initialisers

Probably not a good idea since they break encapsulation by exposing internals of the class. There is work on withers, which should make defining builders far simpler.

> - extension methods.

They make code harder to understand. If they ever come they would have to be declared at the top of each source file.

> - null coalescing operator

Maybe we'll get it, maybe not, but they want to first introduce proper nullable types, lest there is a risk of painting themselves into a corner.

> - async/await

There is a fork in the road, and Java has gone into the direction that leads to virtual threads and Structured Concurrency, for the simple reason that there is no simpler syntax than plain old synchronous code.

> - ... generics metadata in runtime

There are plans to add a kind of reified generics, so maybe we'll get it.

> Some of those ways come from just plain object initialisers. Which are amazing and sorely needed in Java.

They really aren't, and they are IMHO an antipattern since they break encapsulation. One might argue that encapsulation doesn't matter with mere data classes, but Java will cater to that use case by introducing withers.

Greenfield doesn't imply startups, does it?

Until quite recently, the reasonably feature complete open source libraries available for things like DICOM or HL7 were old C/C++ libraries, Java, and C#. That often created a choice between Java and C#. People not doing Windows based development tend not to be interested in C#.

What were they moving towards?

I don't know what compiler and GC quality has to do with how people are making software these days, and I don't think state-of-the-art optimising compilers and GCs are terrifying at all. Go opts for more traditional, simpler algorithms under the assumption that for many purposes they're good enough. That may be so, but sometimes workloads really are very demanding, and you need the best performance.

> Saying that Go lacks in those is just showing how people are making software those days. It’s just terrifying

I'm not following. Saying Go lacks in X shows how poor other software is? Can you connect the dots?

and the costs they are willing to pay. Go/Rust just kill everything else (except maybe C++) for performance and resource needs. JVM requires so many resources just to run small apps.

There's a difference between number of programs and number of LOC (the latter is related to the number of people involved). I am not aware of any SDK targeting the industries I mentioned that "doesn't bother with Java". It's not only a popular choice in those industries, it's not only among the top choices, but it's the top choice by a large margin. Look at wanted ads in those industries to see that. Overall, there are only two languages as popular as Java or more, and they are JS and Python: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...

Yeah I mean he literally works on Java at Oracle, so may just be a little biased.

Doesn't bother to disclose it of course, because what, you don't check everyone's profile in every discussion to make sure they're not biased? What, you don't just know who every user on this site works for? You dummy you :)

> I also don't see the case for stability. Yes, if you're still on JDK 8, it would probably chug on for a couple of years. But we were talking about greenfield projects and newer JDK go EOL much faster. If you want patches, you'll have to run your app to a newer JDK, which may break a couple of things. Rust (within the same edition) or Go (within the same major version) break less than that.

Java also breaks very few things. Breaking binary compatibility is a no-go since it's a core promise of the platform. The only thing in the surface language that has ever been changed is the meaning of the underscore as an identifier, as well as the behavior of == in upcoming Project Valhalla.

> As far as runtime compatibility goes, Rust and Go apps ship with the runtime.

Java applications can also be shipped together with the runtime.

> Productivity is something that is dead if you are AI-heavy.

Nevertheless, making constructs available to express intent more clearly should also help LLMs to not go off the rails.

> the situation is very much the opposite when it comes to Rust.

It isn't, and the problem isn't Rust specifically, but all low-level languages. They can offer very good performance (often better than Java) when small. But as they evolve over time, or are very large to begin with, they become much harder to keep performant. This is for pretty fundamental constraints of low-level language that I mention in another comment here, and this performance problem with large programs written in low-level languages was well known before Java even existed. The JVM was designed, at least in part, to address it.

One of the things that drew me to Java (from years of C++, even though I still work in C++ when I work on the JVM) is precisely how it addresses those performance issues we ran into with C++ five years into a project.

> As far as runtime compatibility goes, Rust and Go apps ship with the runtime. This can be better or worse for you, depending on what is your upgrade story, but I don't see a clear winner here.

I wasn't talking about "runtime compatibility" but of overall version compatibility. Java has an unmatched compatibility record - not perfect, but better than anything else (with at least a medium-sized standard library).

> For observability, I feel that with Rust you have a bit less that you need to observe (no GC to worry about).

Memory management is very often a bigger issue without a GC than with a moving GC. Time and again we see Rust or C++ programs spend 30-50% on memory management.

> Productivity is something that is dead if you are AI-heavy.

Really? Have you had AI write a good medium-sized (say 100-500 KLOC) program or maintain one over a long period of time without very close reviews? The only people I've seen who don't know about the ticking time-bomb agents leave in the codebase are the people who don't look.

> With AI, this doesn't matter anymore, for better or worse.

You may be talking about small programs. I agree that for small programs, low-level languages can offer excellent performance, and AI can be okayish, and you can get some observability you can live with, but I'm talking about large programs.

> But I think the reason Java is chosen have little to do with the reasons you've mentioned above and more with organizational preferences.

Those organisational preferences are due to a long record of delivering on the things I mentioned. Java has an exceptionally low "regret factor", i.e. people who regret choosing it five, ten, or fifteen years into a project (which is when the problems usually start).

Open telemetry is about how telemetry data is reported, not how it's collected. It's hard to compete with JFR on the breadth and depth of low-overhead, in production telemetry, built into the standard library and the JVM itself.

> Let's use tools that are 10 years behind

Yes and that's exactly what modern tooling is missing. Try to develop for node.js 0.2.12 on today's update of Visual Studio Code. See? No enterprise-level collaboration for ya.

I don't think they do. I work in a maven shop and half of the people don't even know what to do when maven fails inexplicably

> Rust is just as ergonomic as any other popular language today if you're using an agent

Have you worked on large (>500KLOC) codebases with an agent? Not only do you have to be an expert at the language, but even if you're lucky and everything is fine, Java code is likely to be particularly fast by comparison, because the agents aren't very good at manual optimisation, especially as the code grows (they're even worse than humans at that, and humans aren't great at manual optimisation of large codebases, either, which is one of the problems the JVM set out to solve; in fact, agent-written code in a low-level language gets pretty slow well below that size). Oh, and the long build times certainly don't help.

> Which Java famously does not have.

Hmm? Java gets null dereferences all the time, that's what a NPE is. The VM takes on the extra plumbing to surface a dereference of a null pointer in a recoverable way to code. On Windows this is done using SEH, on Unix it is handling SIGFAULT - but each NPE corresponds to a null pointer dereference that java then tries to clean up.

That the language does not have a way to have compiler enforced "never null" is actually a huge productivity drain, specifically because you have to do your own defensive measures against null or attempt cleanup/recovery when it happens.

Even languages like Swift which use Optional (e.g. a maybe monad) to provide a concept of nilability still internally will hit null pointer dereferences on occasion with faulty bridged code/bindings. However, they treat this as a non-recoverable violation of invariants - a developer shouldn't be trying to recover from incorrect code at runtime.

I don't really think about it too much, it works fine. We don't use Optionals, I'm not sure why you brought that up. I'm not a dogmatic person in this respect, rather pragmatic. I'm sure Kotlin is great, and I'd enjoy writing it, but for now, the vast majority of the finance world runs on Java, so it's what we use. I find it easy to work with, which counts for a lot.

> Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin.

You deserve the strawman award of the year.

NullAway and JSpecify encourage making as many types non-nullable as possible, thus they can actually also advice about removing redundant null checks. Nullable types become the painful exception that visibly spreads through the codebase, which discourages writing code that relies on null.

Optional doesn't enter the picture at all. NullAway kills their usecase within ones own code. They are anyway only recommend as return types to force others to check for an emoty case, but I think Optional will become fully optional when the Java platform gets nullable types on its own.

Google Error Prone is a code linting tool that's very useful in its own right, and NullAway is just another plugin.

More Java strawman arguments. How do we live with BuilderFactoryFactoryBuilders! Every day we cry ourselves to sleep!

Golang doesn't have solutions like these:

* https://jspecify.dev/docs/user-guide/

* https://openjdk.org/jeps/8303099

surely 'throw a npe' means something very similar to something that Go does

It just swallows errors, so you don't even know about it!

Go panics.

Can you explain what the issue is with nullability here? Is the concern that someone's code returns null in normal circumstances but doesn't document that well, so you don't check if null? Cause if it's an error situation, one way or another some exception has to be thrown.

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.

Null Analysis can be checked and enforced by the CI.

I don't think I've encountered an external library that returned partially constructed objects returned nulls (at least not without a @Nullable). There are probably cases of this existing, but those types of libraries don't tend to see a lot of users.

With agents, we're getting there.

You're drawing a distinction that doesn't matter in practice. If you encounter a NullPointerException incident then you either didn't annotate your code or you didn't run the tooling. (In fact before even running your CI suite, any serious IDE will tell you immediately that you've mishandled null somewhere.)

I get that some people feel like it ought to be built-in to the language rather than a separate tool... but people's personal feelings are irrelevant to the lived experience of my day-to-day work, where worrying about null is truly a thing of the past.

yes, so are the NPEs - both are runtime errors indicating a bug in the code. NPE was a major source of irritation 20 years ago, but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source. And the culture has evolved.

>in places where it's pointless to check, like IOException

Can you explain why this is pointless? In my mind, this being a checked exception would hopefully be a hint that I should think about this failure-case and make an explicit decision whether to handle it or not. Network connection failed? Maybe I retry. Maybe I store that data somewhere else as a fall back. Isn't this similar to Go programmers needing to check if err is not nil?

Mostly I think they are a mistake, like in ordinary application code instead of catching close to the throw you want to do a lot of

  try {
     ...
  } finally() {
     ...
  }

Occasionally though I have built something really sensitive, like an authentication filter for a web site which has at least 5 ways to log in and in that I have a hierarchy of exceptions and use checked exceptions heavily to document all the ways things can go wrong and felt like "the type system really has my back here" but that is like 5% of the Java I write.

Scala's ZIO also demonstrates that they're a great idea and can be perfectly ergonomic, but you need type inference, which Java devs were resistant to for a long time (maybe still are? I remember lots of "how will I ever know what `val a = new Animal()` is???"). If you infer the exception type, they're basically invisible except for when you forget to have some place in your program to handle them, which is exactly what you want.

Dynamic runtime agents are deprecated functionality. In a few releases agents have to be specified at JVM startup. Mockito (I bet it's the most common user of that feature) and current JVMs already warn about it.

Another issue with Lombok is that it requires IDEs and other tools to be aware of it. Missing integration with other annotation processors only causes "definition of external element not found"-style errors.

> Structured Concurrency

I think the two languages mean slightly different things here. In any case, Java's model is so much more simpler that I don't think they are honestly comparable. In kotlin's case you have to be very on top of your game to have a chance of correctly using it - there is concurrency, parallelism, exception handling all combined into a single abstraction in a non-native way - so your stack traces will be useless/swallowed etc on incorrect usage. Of course the usual caveat applies, just use java's abstraction if you need that.

> Standalone function

Don't really see the benefit, if anything it creates place for style disagreements. A SomethingUtil class was just fine (and findable).

> Properties

Difficult topic with both cons and pros.

> Data classes

Exactly because they are "more powerful" they are strictly worse. A design element is just as much about what it is as it isn't. Copy is good though.

> Delegation

Used a couple of times, but it's not the full blown thing (see manifold)

> Extension method

I will be honest, I really dislike these. They can occasionally help a bit with some DSL, but for the most part they just make code very hard to read. I much prefer a normal static method instead.

> Context parameters

One of the few useful syntactic sugar.

> Operator overloading

Argued to death already :)

> Inline function

Feels more like a hack to support some of these extra features than something you would want to use yourself

> Block syntax

For the rare DSL usecase it's useful. Everywhere else I really dislike it and the accompanying coding style. These .also and similar implicit receiver thingies are just straight up evil.

All in all, there are a few things that are very elegant in kotlin, but I feel they went the c++ c# way of over abstracting just to have a long feature list.

Many of those are getting addressed. Value types are in the works, generics specialization for primitives, and even type classes.

It's sad - I spent a good 12 years writing Scala every day and it was the ideal language for my brain. Until it wasn't - sbt got too complex for it's own good, everything became "very smart" developers over-using implicit conversions, you couldn't find a project that wasn't an opinion war on cats vs whatever. It collapsed on the weight of it's own smugness.

go and kotlin aren't it, gleam scratches the itch but I can't justify writing code that would impossible to hire for.

scala situation is a real shame.

Every job I've has has used different languages so I don't really understand the need to find a dev for a specific language. I went from network firmware in C to banking application servers in Scala and it took like 2 weeks to ramp up. Not a big deal. Now I write lower level networking stuff again in Go, which seems like its just worse than e.g. C-with-templates (and occasional classes) style C++ so I don't really understand why people like it.

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)?

Java is almost always significantly faster than Go because the Go runtime does a poor job of exploiting large memory page, doesn't support text-on-huge-pages, and barely supports profile-guided optimization. With HotSpot you get all of this and more for free. Go is fine but Java is peak.

Golang is not faster than Java, the opposite in fact. With native image, Java can be used for sidecar applications as well.

IME they're both in a place where Rust is maybe ~40% faster for a decent CRUD web application server, but with go you need to write much lower level code to get there (e.g. using composable generic iterators will ruin your allocations, so it's all manual for loops). You can write idiomatic high level Scala and get the same performance. Which could be as simple as the go compiler offers no ability to force inlining and has way too low of a complexity threshold, but that basically makes reusable code unusable in high performance situations.

The whole go team's philosophy tends to also revolve around assuming their users don't know what they're doing, which is annoying. Like an inline keyword: thinking you know better than me doesn't mean I'm not going to inline it; it means I'm going to manually write it inline myself in the code, and then think the language sucks because it's tedious, error-prone, and verbose. Or they tend to mark lots of stuff private for no reason, and e.g. with TLS 1.3 they just ignore your config because they think they know better, etc.

Isn't this mostly about java cold start costs? It might be that other people are optimizing for steady-state performance, not transient startup performance.

So you compare the build tool of A and B on a short-lived job type where java is knowingly not its strongest? How is that a meaningful comparison?

Yes.. lol. The biggest argument now is Kotlin having nullness by default in the language. Just check around the comment section. Now java is planning to have them which will further help jvm to optimise for performance. Not sure what the next argument will be after.

Nullness annotations are already usable. The JEP is for further integration into the type system.

Fair.