As someone writing code on Java since v1.0 and making tech strategy decisions on the C-level, I consider myself sane and experienced enough to say that Java is something that will do the job well and can be the primary choice for startups and new projects. Kotlin as a platform is not mature enough to deserve the same qualification.

> Kotlin as a platform is not mature enough to deserve the same qualification. With (1) a lot of Java backend projects migrating to Kotlin (let's be negative and assume 20%); (2) all of Android running Kotlin, which is around 80% of the world's mobile phones; (3) the world's best IDE authors building features and improving Kotlin; (4) the language being almost 13 years old at this point; and (5) Kotlin being 100% compatible with Java in both directions, I wonder what additional maturity would you be looking for. Can you point to a specific problem?

I mean, of course, Java has been here since forever and we've made careers out of programming for JVM. I'm wondering if you are referring to a specific maturity issue, or just want to highlight that Java was here for longer... if it's the latter, I don't think it can be a valid argument against Kotlin or in favor of Java.

Hard agree on the maturity, it's clear this person has literally just decided that Kotlin is immature despite it flying in the face of all facts

The job of software engineers is to translate a business domain into software.

Different languages are better or worse at modeling different domains of problems.

I have seen the same problem solved in different languages take 2-3x the amount of work and have a large difference in ongoing maintenance costs.

Java's reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs. People get good at modeling problems in Java, but that doesn't mean Java is the right language to model all problems in.

A problem that is best represented as stateless functions processing data is a miserable fit for Java, a problem that is best represented as thousands of threads going off to do independent work and then unifying results, is a bad fit for Java.

Sure Java can be used, and I'm sure as an experienced Java developer you instantly thought of how to model those problems in Java, but experienced users of languages that map naturally to those problem domains don't have to think of how to translate to their chosen programming language, because the language is a natural fit for that particular problem domain.

As a trivial example, I once saw Java used to parse a raw binary stream that had a lot of unsigned ints in it. Miserable usage of Java, tons of wasted space. In a language like C/C++, or even C#, it was possible to just directly map a structure onto the raw byte stream, but for Java they had to read each unsigned 32bit INT into a 64bit INT to ensure no overflow.

Horrible mismatch, lots of unnecessary allocations, ugly code, wrong tool for the job!

> Java's reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs.

In my career I worked on a really wide range of business domains and have not even noticed the problems you are talking about.

The problem of mapping certain types like unsigned int that you mentioned is rather rare integration scenario. There’s not that many domains where numbers with the most significant bit are important, but MAX+1 size numbers are not.

> In my career I worked on a really wide range of business domains and have not even noticed the problems you are talking about.

How many other programming paradigms have you explored in depth and built solutions with?

Back when I did OO in Java and C# I didn't think twice about it, converting things to an OO paradigm was second nature, but once I stepped outside my comfort zone and learned of other modeling techniques, I realized that I had been jumping through extra hoops to get to where I wanted.

> I have seen the same problem solved in different languages take 2-3x the amount of work and have a large difference in ongoing maintenance costs

I am sure none of this experiences were basis for an objective experience, there are too many variables. But surely, there are (very few) problems that doesn’t fit Java too well, though it is not an OOP-only language, it is a multi-paradigm one, with many FP concepts seeping into it.

E.g. for some ultra low-lat audio processing I wouldn’t choose it, your binary stream processing may be another good example, though it depends on a bunch of factors and in many cases java is more than fine for that as well.

> reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs

You don't have to stick to OO constructs. Java has functional programming support and pattern matching.

> best represented as thousands of threads going off to do independent work and then unifying results

Java has had executor support for a long time now. And if you're talking about IO bound tasks, Java has virtual threads now.

> parse a raw binary stream that had a lot of unsigned ints

Java has `Integer.parseUnsignedInt()` and other similar operations.

I'm sure you have done great work in Java, as have many of us, and for many of those years, Java really was the best tool for many jobs. But that was then, now is now.

I'm not saying Java doesn't work, even for greenfield projects today. It works fine. But me and many others also think it's not enough for something to merely work, especially not when there are other much better and more modern tools. (which Java is demonstrably playing catch-up with)

You and every other C or higher level exec need to get a grip, get with the times and realize that continuing to insist on Java is only going to make (or, by now, keep, more like) your organization stale and attract more and more mediocre engineers for every year that passes. I know because I've worked with the kind of engineers who are still doing Java + Spring like it's still the 90s, and they're not the ones you want on your projects. The best talent don't even want to consider working with Java if they can help it.

> especially not when there are other much better and more modern tools. (which Java is demonstrably playing catch-up with)

Which modern tools do you have in mind here?

Java does indeed playing catch up with new features. That's inevitable for a language came out 30 years ago. OTOTH many other languages are still behind Java in terms of the runtime environment and the ecosystem. You should pick what works for you, not to go with the trend.

> The best talent don't even want to consider working with Java if they can help it.

I think you seriously overestimate how talent those devs are if language is the deciding factor of what they choose to work on.

> Which modern tools do you have in mind here?

We're talking about Kotlin here (there are many contexts where neither Kotlin nor Java is the correct tool, but for pretty much any use case where Java is an option, Kotlin is going to be a better one)

> not to go with the trend

I'm so sick of this argument, it presupposes that Java is the default and anything else by definition is just a trend. Kotlin is not a trend, Kotlin is not a fad. Stop begging the question.

> I think you seriously overestimate how talent those devs are if language is the deciding factor of what they choose to work on.

Ok, and I think you seriously overestimate the willingness of people who have given Kotlin a serious try and seen first hand how much it offers over Java to go back to working for a Java-heavy shop if they can help it.

> OTOTH many other languages are still behind Java in terms of the runtime environment and the ecosystem.

Ecosystem doesn't matter except at the long tail. I've never needed a library that didn't exist for NodeJS, until I started doing LLM work.

Now 80% of LLM libraries exist for NodeJS, 100% of LLM stuff has a Python library, and Java libraries are incredibly rare.

Want an ORM solution? Java has you covered.

To build a good product you don’t need a kid with Hollywood star complex, for whom the choice of programming language or tools matters that much.

If Java repels such self-proclaimed “best talent”, good, because the team will be healthier without them. There’s enough engineers willing to learn and write a good code on Java to solve a business or an user problem, and they are absolutely not mediocre. There’s even no such thing as a scale on which you could put an engineer to measure some “greatness”. Every person is unique and has talents that may be useful in different types of projects.

> To build a good product you don’t need a kid with Hollywood star complex

Agree 100%.

> for whom the choice of programming language or tools matters that much

Programming languages do matter. Serious, mature professionals critically evaluate and compare tools and pick the best one for the job. Kotlin is a) not some fad b) objectively better than Java for pretty much every imaginable use case. Kotlin avoids entire categories of Java defects https://proandroiddev.com/kotlin-avoids-entire-categories-of...

Me and others who advocate for more modern tools are not self proclaimed wannabe rockstar devs who are only interested in the latest fad. Ultraconservative diehards who refuse to learn anything new since the 90s are the ones who need a reality check, not us.

As a mature professional who stopped counting learned programming languages and frameworks long ago (I’m familiar with Kotlin too), I can tell you that Java is a modern tool by all measures. It may lack some features of other languages and platforms, but it is not features what defines relevance for modern applications. Your advocacy is important, we of course need progress and testing new concepts. Yet what ultimately matters is business value and user experience. Java is pretty good in delivering it and many professionals choose it for that reason, leaving new stuff to pet projects at home. It is not diehard conservatism that lets us make this choice, but a mere pragmatism. For me it is not obvious that Kotlin is better. There are risks associated with less mature platform that already costed one of my teams a couple of wasted sprints. Productivity and quality impact isn’t really noticeable (the biggest factor in those two measures is always communication, not tools).

> it is not features what defines relevance for modern applications

what? zero-effort null safety out of the box alone is immeasurably valuable

> leaving new stuff to pet projects at home... risks associated with less mature platform

I'm so sick of this argument, it presupposes that Java is the default and anything else by definition is just new, a trend, a fad. Kotlin is none of those things and you know it. Stop begging the question.

> For me it is not obvious that Kotlin is better.

I mean, if you can familiarize yourself with things like https://proandroiddev.com/kotlin-avoids-entire-categories-of... and still conclude there are no obvious benefits then I don't know what to tell you, it's clear nothing is going to convince you

That feeling is mutual. I very much prefer boring Java or .NET developers who are all supposedly stuck in the 90s to hipsters chasing after the latest JS fad of the week.

Me too! But you're building a strawman. Kotlin isn't a JS fad. It's been around for many years, is the default language for Android platform and the de facto standard IDE for Java, backed and used by Google, JetBrains and many many others. But sure, everything that isn't what you've been doing since the 90s is a fad.

> I've worked with the kind of engineers who are still doing Java + Spring like it's still the 90s, and they're not the ones you want on your projects

And I've worked with programmers who use the latest fad of the day (golang, etc) and they're not the ones you want to have on your projects.

> The best talent don't even want to consider working with Java if they can help it.

Not in my experience.

Every single person who's arguing against Kotlin in this thread is resorting to the argument that it's the latest fad of the day. It's not.

I was mainly arguing against golang. As for Kotlin, given the incredible work that has been done in Java recently, the argument is that there isn't much reason to switch over anymore, due the introduction of more moving parts into the project (another dependency, compiler, room for issues, etc.) and the fact that Java ended up with the superior approach (better/fully fledged pattern matching, virtual threads, programmable string templates, etc.).

If I look at the job market in my area it’s dominated by Java. There are a lot of .Net jobs as well but they are typically at companies you really don’t want to work for, so it’s basically so much easier for you to find a nice job if you’re into Java.

I’m not, mind you, but maybe 21 will actually change that. I guess it’ll depend more on the tooling than anything else. Because the things I dislike the most about current world Java is that it’s very dependent on 3rd party “addons” to become a nice working experience. Like, you’ll probably want to use Quarkus if you’re doing anything enterprise related, but then you’re putting yourself at the mercy of Big Blue. I’m not sure that Java21 will change that, if it will then it’ll probably be a world where Java dominates even harder than it already does.

> the sane members of the Java community have long since moved on from Java, and they're not coming back

We wish! We're stuck in the Java job market, reading Java praise pieces like this... Oh boy! Java's getting structs?

How long until we get continuations in Java? Maybe another 10y? How long until we get TCO? Lets say 20y?

And in the end it will still not feel clean or as neat as other languages, that had this stuff for multiple decades.

Hopefully never. There's a reason no primarily functional language ever became mainstream. The "elegant code" they allow is never as lovely as the zealots imagine

None of those are a necessity, and they can be easily implemented in an additional layer (e.g. annotation processor if you really wanted to).

No language features above machine code are a "necessity". Java is not a "necessity". "OOP" is not a "necessity" either. Why don't we all work in C? Or maybe all in assembly language? Yet most of us are glad we can work at a higher level. Probably no single language feature is a "necessity", yet when they come together they make for higher level languages and elegant expression.

Let's not forget that the JVM still does not have reasonable generics & value types. The .NET CLR introduced this in 2005, bettering the JVM. Java was in a sleepy slow release mode back then. We've been waiting 18 years for value types and proper generics - Valhalla has been just about ready for a very long time. Some of us moved on a long time ago.

Agree that Kotlin is a bright spot in terms JVM languages. For my taste has adopted some of the best concept of Scala, but without the burgeoning complexity.

C# def brought a lot to the table vs Java but I feel like it has also kind of stagnated and not realized the potential of F#. Scala likewise is very powerful but def overly complicated and difficult. Kotlin + Arrow hits the sweet spot, at least for me.

As a Kotlin dev you should still be excited by virtual threads in Java 21. You'll never have to use coroutines again.

I'm very curious to see how this works out in the Kotlin ecosystem, given the amount of async code out there (and the associated function coloring issues).

You can easily combine the two, just use a virtual thread and when you hit a `suspend` function use `runBlocking` to get rid of the suspension.

> Also the null thing hasn’t been an issue for over 10 years.

I don't think I've ever seen a Java codebase that doesn't experience NPEs in prod, and that includes modern greenfield ones that make use of all the tools to combat it.

> Just use null annotations and both your static checker and your IDE will catch every NPE.

Yeah, or just catch it in code review, or just xyz...

Or, just switch to a compiler that doesn't allow it in the first place, out of the box?

> I don't think I've ever seen a Java codebase that doesn't experience NPEs in prod

Frankly, the last NPE I saw in production was many many years ago.

same, Kotlin doesn't compile if you try to deference null pointers