>Do Java projects in industry even use the new stuff?

Yes. Kotlin fans need to understand that Kotlin is not competing with the old Java ways and stop mentioning bloody enterprise as an argument against Java, because bloody enterprise is largely ignorant to Kotlin‘s cause. EnterpriseStrategyAdapter anti-pattern is not a language problem, it is a management problem. It won’t be solved neither by new features of Java nor by new features of Kotlin. The real competition is in the new code in startups and Java has one big advantage there: faster recruiting, more reliability in tooling, better quality of business code for the money. Kotlin is a good perk for developers in late stage startups, where the teams are big, delivery timelines more relaxed and you can afford fancy but less mature language or tool to consume resources instead of delivering more business value.

>Kotlin is a good perk for developers in late stage startups, where the teams are big, delivery timelines more relaxed and you can afford fancy but less mature language or tool to consume resources instead of delivering more business value.

The proof being?

Your sibling commenter said (s)he just got off Java 8 in 2023. My experience was similar; that's why I asked.

Also, it's hard to find Java programmers who haven't been tainted by that enterprise mentality, so in a way it makes hiring hard if you don't have the resources to filter the junk. When you see Clojure or Scala on a resume you know they're above that.

Well, my team is now on latest LTS (21) and we do use new features in our code. Hiring an engineer who can write modern code is not any more difficult than hiring without this requirement. It is generally a management problem, that any skilled senior manager should be able to solve. After all, enterprise anti-patterns are not uncurable poison, e.g. switching to record-style accessors is something people can do on their first day easily.

I could count the number of startups I’m aware of building on Java on one hand, after a wood chipper accident. For perf it’s rust, for web it’s Go or node/deno/bun for single front/back language.

Java is often faster than Rust on typical single-threaded code. Rust is faster when you want to leverage features like SIMD.

And when it comes to concurrency Rust is the worst language I've ever used by far. The type checker makes dealing with objects between threads extremely painful. With the JVM it's all just handed for you.

Rust is great when you want a tiny binary with minimal memory consumption.

So you think Rust and Go are more frequently used than Java for new code? Do you have something to support you claim?

Looking at TIOBE and PYPL, it comes that for backend Java and .NET are huge, followed by .Node.js, followed by Python and then PHP.

I know a number of them, but that’s not really important. You didn’t mention Kotlin, right? :) Often enough whatever stack was used at the seed stage, it is eventually either replaced or complemented by Java, meaning that new code is written either on latest LTS or even on evergreen version.

I have never seen Golang being used for business logic backends, its Java, Kotlin or .NET, and then nothing else for a long while. It is not expressive enough but shines in other areas, mainly infrastructure.

Remember that "Systems Programming", which is what Golang was designed for, isn't necessarily just Kernel and device drivers, but everything that isn't "Application Programming", and that includes the whole K8S networking and container stuff where it is very successful.

Kotlin is weird inclusion in that list with Java and .NET unless you'd include Android.

> new code in startups and Java has one big advantage there: faster recruiting, more reliability in tooling, better quality of business code for the money.

You're delusional if you really think any of this is true. There are, proportionally to "enterprise", extremely few startups using java. For good reasons.

I have no idea what „good reasons“ are you talking about except fancy language as a compensation perk. Java is a good choice for startups, even if it is not the most popular choice (often for bad reasons). I have proven it several times by being able to ship working and scalable solutions quickly and hiring decent team with time to close open vacancy within 1 month.

>Kotlin has great tooling, and Java library compatibility, so why wouldn't you use it?

As an average company what you want from a language is: your team already knows it or is fast to learn, it is arguably better in a measurable way (development is faster, codebase is easier to maintain), developers like it more, it has a large support and audience.

How many of these does Kotlin check?

All of them except first.

Kotlin is the Dvorak to Java's Qwerty. It looks better in theory, but not where it actually counts, and not enough to justify going against the grain.

I'm allowed to use Streams but var isn't because it makes GitHub PRs difficult to parse.

We got to upgrade from Java 8 to Java 17 in 2023.

I've worked in "enterprise" and have a different experience. The enterprise projects that I was working on switched to Java 8 in 2015. There were some legacy services that remained on 5 or 6 for a while, but they were mostly in "maintenance" mode and nobody wanted to spend time on them.

I have over two decades of experience and there has always been room for trying out the "new" technologies and keeping up with the latest best practices, even in enterprise. I know that not everyone has this experience, but there are actually a lot that happens outside slow big American legacy companies...

In my current startup we use the latest JVM and have a mix of Java and Kotlin. It works really well and we have never experienced any problems with development speed that was related to code or language syntax. JVM + Spring boot + Postgres may be the "boring" choice, but it has enabled us to focus on getting things done and focusing on the product. It didn't take long for juniors to be productive in our stack either. Spring itself looks a bit scary at first sight, but once you learned the basic philosophy you have less issues than a Node project in my experience.

I know that my experience may not match your experience, so I recognize that I can't make a generic statement. It's just a bit frustrating to see similar statements made by people with bad experiences.

- Not all Java development happens in enterprise. There is a thriving eco system of small to middle sized companies and startups using Java

- Not all enterprises are the same. I've actually noticed a shift to the other extreme, where enterprise uses the latest technologies to attract new employees. Nobody who has a choice wants to work with factory patterns on an old version of Java

- Old Java patterns like factories and extreme use of inheritance is out of fashion. There is of course a lag like in any trends, but remember that Java is so widely used so you will always find companies that are slow to adopt, or have legacy software that is in maintenance mode.

Luckily I don't have to deal with FactoryFactories either.

I have to keep alternating between startup and enterprise so that I can keep sane but also get pension contributions, so I do know there is a great world out there. Just not always great paid (am in UK).

We use Java 17 features on all our projects now, expecting to update the platform to 21 in a year or so. Allowed features vary by project, some reviewers don't like vars (though I do) because it makes it harder to understand the code for them.