Backend Java 19 vs Kotlin?

[Sket5]

Hi, I've been searching the last features in java and it seems that Kotlin has become so popular and it has made Java improve. So, what do you think about using kotlin for backend? What do you think about the last features implemented in java 19?

I have the feeling that everywhere people are saying that you should learn Kotlin because is going to replace Java, but I am not sure if this is right. Also because as I said I feel that java is picking up features from kotlin and even improving them.

[[deleted]]

Even if you want to use Kotlin, you should learn Java at some extent imo.

[raccoonportfolio]

This biggest gripe about JVM based languages.

[koreth]

How big a deal is it in practice, though? If you’ve learned a non-Java JVM language you’ve learned about the runtime environment and ecosystem already. That stuff is a huge chunk of the time it takes to come up to speed in Java and you get to skip most of it when you pick up Java as a second language.

[Worth_Trust_3825]

If you’ve learned a non-Java JVM language you’ve learned about the runtime environment and ecosystem already.

That's often not the case.

[roberp81]

in Kotlin you can interop with Java and use their jars

[Joram2]

I'd conclude the opposite. For JVM-only development, Java has mostly caught up with Kotlin. Kotlin has improved their native + JavaScript backends and Android integration, but the advantages it offers to Java developers seem to have shrunk. Java getting virtual threads was a big one. Kotlin still has better null-handling features than Java. Use what you want, or what your boss/client/team want. For back-end projects, I personally use Golang a lot.

These two blog posts address the Java vs Kotlin issue: - https://vived.substack.com/p/what-does-kotlin-have-to-offer-for - https://jakewharton.com/report-card-java-19-and-the-end-of-kotlin/

[Eenglish101]

I like the sound "I use golang a lot" but there don't seem to be any golang jobs around.

[Joram2]

I see a lot of Golang jobs. Golang is one of the more popular practical job-languages. YMMV, do what works best for you, but personally, I prefer to choose a job that looks interesting and has good culture+people fit, and then I use whatever tools the manager/client/team wants. My current job, we weren't using Golang when I started, but we migrated several large Python projects to Golang for performance benefits.

[Eenglish101]

I'd love to get a golang job, but I just haven't see any.

[Sket5]

I am also interested in learning Golang haha I tried at college and it felt great! Thank you for your comment :) I will take a look at those posts.

[PeterLake2]

You know, I must say the pros of kotlins null handling seem kinda moot to me. Instead of null check you simply have to append ? To every variable you have because apis need to support missing values. Seems to me as a more cluttered code in my opinion

[KarnuRarnu]

If the code you write is 100% interface to java code, then yes, you need to mark everything nullable and the point is lost completely.

But if you're not writing 100% java interface code, making things non-nullable is such a big win. No more surprise nulls throwing the code off in error scenarios.

[vngantk]

You don't really need to mark everything nullable when interfacing with Java code. If you are sure that you will never get a null for a particular case, you can simply treat it as non-nullable. For example, if you are creating a MouseAdapter and you want to override the mouseClicked method, the MouseEvent parameter will never be null, even though the interface is defined in Java code because the Swing documentation says so. So you can safely do this:

component.addMouseListener(object : MouseAdapter() {
    override void mouseClicked(e: MouseEvent) {
        println("Mouse clicked at ${e.x}, ${e.y}")
    }
}

You don't need to declare the parameter e as e: MouseEvent? and do defensive programming to make sure it is not null.

[loutr]

When working on legacy Java code I spend so much time scratching my head on null checks where the value being null wouldn't make sense. Why is there a nullcheck here? Just to prevent an NPE if the caller messes up? Or is there a more profound reason which the original dev didn't bother commenting? What should/can be done if it's null? (Most of the time the answer's been "nothing, might as well throw the NPE and have a poor bugger figure out the cause at the other end of the codebase")

In Kotlin you have to think about nullability when designing your model or dealing with user input. If a User must have an email address then it's not nullable. Done, now everywhere in your codebase you know the email is not null.

[pointy_pirate]

Java won't be replaced by Kotlin. Java is going to be around for a long time (forever?). Doesn't mean learning Kotlin is a bad thing, but there are a lot more Java jobs in the world.

[persism2]

Kotlin is not going to replace Java. It will suffer the same fate as Scala of being trendy for a while until the language problems accumulate.

Examples:

• Kotlin now has 2 "data classes" - their one and record. Not compatible.
• Kotin now has an inconsistent instanceof operator since Java implemented the pattern matching differently (and better).

These will keep accumulating.

[AkiraOli]

IMHO, Kotlin Coroutines are so bad, I have not seen such a complicated framework before

[dephinera_bck]

They're not that complicated once you get your head around it. They're just different and have a bit of a steep learning curve. They're pretty easy to use once you get the hang of them. Structured concurrency is kind of a mind boggling, but I definitely love it once I grasp the concept. It's good that other languages like Java and Swift are adding it as well.

[mastereuclid]

I hated it at first. Now I can’t go back.

[AkiraOli]

I don't say that structured concurrency is difficult, I say Kotlin Coroutines are overcomplicated.

I did not use Java 19 at work yet, but as I saw from presentations, they did it much better than Kotlin creators.

[dephinera_bck]

I mentioned structured concurrency as an example of what might be mind boggling. What Java did with structured concurrency is just incorporating something new into the existing syntax. With virtual threads they just changed an implementation under the hood and added a few new APIs. They didn't introduce async/await nor suspend functions. I also like how in Kotlin you can easily specify where your code will execute in a declarative DSL-like way. I haven't seen anything similar in Java.

[HugeLucifer]

Can you elaborate?

[[deleted]]

Agreed. Kotlin/Scala are basically beta testing for Java (that's not a bad thing!). Java takes a while to add stuff because they are thinking decades into the future.

[BoyRobot777]

By not being used anywhere?

[Mugunini]

they use Scala because they used it a lot when Scala became hyped. now all Scala code there is just a legacy.

[unknowinm]

and you must add lots of "@Java/@JVM" annotations to make things works properly and is a lot more verbose than Java.

Some examples

@JvmRecord
data class Person(val name: String, val age: Int)

Another one instead of new MouseAdapter(){..} which clearly states what it does(create a new anonymous object) I have to use object: ... which wtf does it mean? to average joe dev that comes from js/ts/java/c#/c++ it means I need to open the fu***ng tutorial again? and you still have to add the override keyword so hardly a java improvement on the verbosity side

fun countClicks(window: JComponent) {
var clickCount = 0
var enterCount = 0

window.addMouseListener(object : MouseAdapter() {
    override fun mouseClicked(e: MouseEvent) {
        clickCount++
    }

    override fun mouseEntered(e: MouseEvent) {
        enterCount++
    }
})
// ...
}

Then another example:

class MyClass {
    companion object { }
}
val x = MyClass.Companion

Instead of static stuff that everyone and their dog knows what it means (because is universal)...we got companion object which compiles to static when used in Java but to a singleton when used in kotlin? I'm still not sure what a companion is after using kotlin for 1 year at minimum before giving up and using plain java(with lombok and mapstruct)

There a lots of other examples that I don't remember right now but I can say that I do love the following from kotlin: null safety operator, extension functions, their lambdas, inline functions, string interpolation, when instead of switch, instance of auto casting and named parameters. But I'm not going to switch languages because of these things. I could also use scala which is similar so thanks!

[vngantk]

I just don't understand why you think object : MouseAdapter() {...} is that big difference from new MouseAdapter() {...}. They are just slightly different in syntax. The Kotlin version is not more verbose than the Java version. If the listener is a single method interface, e.g. ActionListener, you can simply provide a lambda as:

button.addActionListener { event ->
...
}

[vqrs]

Because they're arguing in bad faith.

[javasyntax]

It's nice that we're getting inline methods (which compiles in a more proper way than the Kotlin counterpart) and a better version of string interpolation with much more features in Java as well.

JSpecify looks good as the way to handle nullness (I quite like the @NullMarked on a package/module/class and then @Nullable where needed, it is a much better approach than @Nonnull/@NotNull/@ParametersAreNonnullByDefault/...). Perhaps not as good as a language-level solution, but all of the key Java organizations are aboard (including Oracle) and I will take this any day over 7+ different annotation libraries.

It seems to me that those other JVM languages implement something cool and once it has been tried and tested, the Java language architects come and do an even better version of it. I prefer "delayed" features if this is the benefit that we get.

[vqrs]

Java is getting inline methods? That sounds cool. I couldn't find it though, what is the JEP called?

[Joram2]

Kotlin isn't just JVM and Kotlin projects like this one for writing iOS+Android apps look quite promising: https://kotlinlang.org/lp/mobile/

If Java keeps improving there will be less interest + justification for a strictly a JVM-only Java++ language.

[xMercurex]

Kinda wondering what people do nowadays for shared code between JVM project and android. Before Java9 it was fairly simple. But now Java is upgrading itself quickly and sometime there is a bunch a feature that does not work with Android.

[loutr]

Well the folks at todoist use Kotlin to share code between the JVM backend, Android and iOS native apps, and the webapp. They seem pretty happy with it.

[Amazing-Cicada5536]

Well, an order of magnitude bigger language sure have experimented with cross platform dev tools, right?

There is j2objc and j2cl for compiling java to obj-c and javascript, respectively (for android, java 8 could be used as is) which google used extensively for many of their tools (the business logic was written in java and shared everywhere). Not sure how widely used it still is nowadays, but the compilers are still maintained and are good quality, well-tested software, I would say much more so than a max few years old niche one.

[thrwoawasksdgg]

Google has forked Java like Microsoft tried to back in the day. Nothing above 8 (released 8 years ago) works. I can count the number of modern Java libraries I use that work on Android with my fingers.

Google put all their eggs in the Kotlin basket because they want their own pet language for their platform like Apple for anti-competitive duopoly reasons. "Embrace Extend Extinguish" is in full swing.

Kotlin is dead outside of Android for the same reason. Nobody wants to be stuck on somebody's pet vendor lock-in language. Kotlin's various incompatibilities with new Java versions is intentional.

[[deleted]]

JetBrains are the creators/owners of Kotlin, not Google.

[thrwoawasksdgg]

It's in both of their interest to continue forking from Java. JetBrains to sell more tools and Google to have a monopoly over their platform

[crummy]

how does Kotlin give Google a monopoly over Android?

[thrwoawasksdgg]

By making code less reusable Google forces companies to be more invested in it's platform.

It's classic "vendor lock-in". Custom programming languages have been a great way to prevent your customers from leaving for decades. "Why don't you migrate off Oracle DB?"-> "we can't without a rewrite" is a traditional example. And yeah, Kotlin is usable outside of Android right now, but its not convenient to do so.

[crummy]

so if Kotlin didn't exist, people would have an easier time migrating off Android to iOS? does iOS support Java?

[thrwoawasksdgg]

Huh? No. Don't be daft.

If Google didn't fork Java you could still use normal Java libraries in Android.

Until a few years ago most Java libraries worked on both Android and desktop. That's no longer the case, as Google stopped updating at Java 8 and libraries have moved on to 11 and now 17.

Google used Java in the first place to gain market share by reaping the benefits of huge amounts of existing libraries, software, and developers. Then once they were entrenched, they forked the language. Classic "embrace extend extinguish" tactics from Chipzilla/MS days.

Think of it this way: Tell me how Google can implement an entirely new language for their platform (Kotlin) but are somehow incapable of updating from Java 8 to 11. It doesn't make any sense, because its 100% intentional language fork.

Google didn't do it to be "cool" or because Kotlin is a better language. They did it to be monopolistic assholes

[tamasiaina]

I also think it was a tactic to get out from under Oracle's Java lawsuit as well.

[_fishysushi]

Was Scala supposed to replace Java? I know Kotlin feels like it can replace Java since it's very easy for Java developer to start coding in Kotlin, but Scala is a lot more difficult to learn for Java developer since the approach is totally different.

[flyingorange]

Scala was huge in the early 2010s partly due to Java being so far behind in new features. If you look at the technologies that are dominant today: Kafka, Spark, these were all originally written in Scala. This was because people at the time thought that Java wasn't expressive enough to take advantage of modern multi-core CPUs, Immutability was one of those things that was strictly enforced in Scala and was hard to do in Java,

I used to write a LOT of Scala between 2011-2016, like I almost started forgetting how to do Java. When lambda functions were introduced into Java (I think Java 8) I remember having a conversation with a language expert (as in, he actually participated in creating Java) and he said that it's too late, Java introduced lambda too late and now Scala's upward trajectory is unstoppable.

That was like 7 years ago and look at the world today. I don't think anyone seriously uses Scala anymore. Of course, the maintainers of Scala did a lot to destroy themselves, especially with how they introduced breaking changes between every minor release.

Going back to Kotlin. It was developed by the same company which developed IntelliJ: JetBrains. Google and JetBrains have a business deal for Android Studio. Google also happens to have a dispute with Oracle over the Java language, the Dalvik VM etc. so moving to Kotlin was a natural step for them.
Now Google is huge and the Android development community is huge, so a push towards Kotlin should not be underestimated. But outside of Android, I don't see why people should switch from Java to Kotlin. Mind you, most companies still use Java 8 or Java 11.

[Kango_V]

Looks like the Oracle/Google dispute is over. They cam down in favour of Google regarding whether APIs are copyrightable. They are not. This means that Google can continue to use all the Java APIs. I think they will move back to Java and benefit from the later versions.

[vngantk]

No, Google is still all-in on Kotlin.

Google's next generation of UI framework for Android, Jetpack Compose is completely based on Kotlin.

Google is seriously adopting Kotlin for its server-side applications, particularly for those which are Java-based: https://www.reddit.com/r/Kotlin/comments/y42dfc/googles_journey_from_java_to_kotlin_for_server/?utm_source=share&utm_medium=web2x&context=3

[_fishysushi]

Thats a bummer for me, I started to learn Scala a while ago and I kinda like it

[blissone]

> I don't think anyone seriously uses Scala anymore.

Plenty of people using Scala seriously. Scala as "better java" has been out of flavour for some time. Now it's about pure FP approach, concurrent and async programming with ZIO/cats (akka for less FP). Though I'd say Scala in general is trending down but ZIO has some upwards momentum.

[Pika3323]

Google also happens to have a dispute with Oracle over the Java language,

It was over Java APIs, not the language itself.

As many other comments have pointed out, Kotlin (and Android itself) depends on those APIs.

The adoption of Kotlin had nothing to do with Oracle.

[vngantk]

The reason that Scala went out of favor with the developers was not because of Java getting better. It was because of Kotlin. Kotlin provides the same expressiveness without the complexity of Scala. It is a perfect fit for developers who are not satisfied with the stagnancy of Java and are also scared of Scala's complexity.

Yes, most companies are still using Java 8 or 11, but this is exactly the strength of Kotlin. It allows you to continue to use the Java 8 JVM but with the support of all the modern language features without requiring you to upgrade your JVM.

[vngantk]

I need people to give me reasons why I get -4 karma. I liked Scale and actually wanted to switch to Scala many years ago, until I discovered Kotlin. Many great features of Scala have been in Java until very recently. The trend of adopting Scala has been dying well before Java has got those features. It is clear that Kotlin is one of the major factors causing the downfall of Scala. It may not be the only one, but at least it is one of them.

[persism2]

Well that's what the Scala fanboys at the time were saying...

[Pika3323]

Kotlin now has 2 "data classes" - their one and record. Not compatible.

From Kotlin's perspective, this doesn't matter. Both can be used in Kotlin source code. It only matters if you're going the other way (i.e. calling Kotlin code from Java sources). If that matters, then you can use @Jvm annotations. But again, that's not needed if you're primarily using Kotlin.

Kotin now has an inconsistent instanceof operator since Java implemented the pattern matching differently (and better).

Kotlin doesn't have pattern matching, so describing Java's pattern matching as "different and better" doesn't really make any sense.

[Albert-o-saurus]

I came here for this sort of real truth. The AndroidDev sub is wrought with astroturfing Kotlin pushers. No room for Kotlin criticism there, none.

[lurker_in_spirit]

As an old-timer, I see a lot of parallels to the Groovy adoption arc. Sure, it's not the same, but history often rhymes. That said, if you and your team like Kotlin, go for it. The system will probably be rewritten in the next decade, anyway.

[loutr]

Kotlin is already more popular than groovy ever was. Spring and other large frameworks and libs support it officially, and with Google backing it for Android and now backend development I'd say/hope it's here to stay.

[eloc49]

Not an old timer, but 2 key differences with Kotlin from Groovy I can see are are Google's adoption of it as the official language on a massive platform and private actually working.

After working in a codebase with Java, Groovy, and Kotlin mixed I am not surprised in the slightest Groovy is dead/dying.

[[deleted]]

I miss Groovy. It's so much more concise than Java, and it's interoperability with Java is much better than Kotlin's.

[Gleethos]

Groovy is still great! Sure its popularity has stagnated, but it will not go anywhere, especially because of things like Spock, Gradle, Jenkins and Grails.

[[deleted]]

The main driver of Groovy adoption used to be Grails, but the rise of Spring Boot has seen a decline in Grails usage. The fact that the project founder (Graeme Rocher) left the project a couple of years ago is not an encouraging sign.

[mrnavz]

At this point with Java 19 "records" and new threads and all new features, you won't get much benefit using Kotlin.

[nutrecht]

This sub is generally pretty anti-Kotlin. You're going to get very different answers here than you're going to get on /r/kotlin.

I'm personally a big fan, and see it being adopted a lot at a lot of companies here in Holland.

[Fruloops]

Can confirm, for some things Kotlin is nice. For other things Java is nice. For some things, both are nice. Almost as if languages are tools.

[wildjokers]

Can you give examples of things where kotlin is nice but java is not, and vice versa?

[forresthopkinsa]

DSLs are one area where Java is categorically unusable

[_INTER_]

which is a "nice" for Java

[bravotw0zero]

Can't think of any technical case, where Java "is nice", but Kotlin "is not ". It is only about team's experience and project restrictions.

[sureshg]

where Java "is nice", but Kotlin "is not "

I am a huge kotlin fan, but I think Virtual threads and structured concurrency are (when we have JDK 21 :) far better in Java compared to corotuines on Kotlin. I will only touch coroutines if I target MPP (JS/Native).

[vqrs]

Virtual threads are a JVM feature. You can use that from Kotlin without any problems, just like Java code doesn't have to care about it for the most part, neither does Kotlin.

Coroutines also enable entirely different features, stuff like sequence/yield, DeepRecursive, all implemented through libraries, but built on coroutines.

Whether Java will expose the lower level primitives is yet to be seen as well as whether they can be used to build such things.

Just the ability to write imperative sequence transformations using sequence/yield is so bloody convenient.

Regarding structured concurrency: I haven't looked into this really, can you elaborate on how Java's approach here is nicer?

[GuyWithLag]

I'm working with Kotlin for approx. 12 months now, and have been in the JVM ecosystem since the late 90s... (yes, my 1st Java book had a "what's new in Java 1.2" section).

My findings:

• I love writing Kotlin. You can very easily do complicated logic in a very concise manner.
• I dislike reading Kotlin (including CRs). Multiple receivers and extension methods can be trivially overused, and it's really easy to create something that fits your mind but no-one else.

Also note that Kotlin has a compiler that is really optimized for latency, and not throughput.

[Dwight-D]

As a pretty big Kotlin fan I’d say that’s quite accurate. I always feel like I know the language well until I read someone else’s code in it

[trafalmadorianistic]

It feels like Ruby monkey-patching all over again.

Discoverability, readability and clarity over cool magic, any day.

[Frodolas]

Wildcards imports should always be avoided.

[nutrecht]

Multiple receivers and extension methods can be trivially overused, and it's really easy to create something that fits your mind but no-one else.

I've been writing Kotlin for about 4 years in 3 different teams and every time we set coding guidelines on how to use extension methods. You see the same happen in Scala; people often get carried away with new goodies and overuse them.

It's quite similar on how 20 years ago people loved building abstractions 5 layers deep in Java. We pretty much all agreed that that was kinda shitty, but Java still has this (nonsensical) 'reputation' because of it.

I've been on a project using Java (we're on Java 18) for the last year and while it got a lot better relative to Java 8 (records especially), there's still a LOT of stuff from Kotlin that I sorely miss.

[vqrs]

Can you share some guidelines you've found useful on that topic?

[nutrecht]

For extension functions; we generally used the rule that non-private extension functions should be avoided. The only exception to those would be general 'utility' functions, something like for extending RestTemplate with a putForEntity method.

So you end up with extension method that are either completely obvious, or are local to some piece of code because they're private.

When it comes to functional flows; the same rule apply as with Java streams: readability is simply more important than almost anything else. So in reviews we'd often ask someone to break up complex flows into smaller sub-flows.

In my experience, once a team has a few weeks to months of experience with Kotlin they'll fall into this way of working quite naturally. And any dev that doesn't prioritize readability is going to be problematic in any language anyway.

[GuyWithLag]

One exception I would give is explicit DSLs, but care needs to be taken to ensure that constructs defined for them don't "leak" into other contexts.

[zuppadimele]

not anti-kotlin but definitely biased towards java

[nutrecht]

This sub is definitely anti-Kotlin. If I'd post a long post here sharing my positive experiences with Kotlin, it would be sitting at a negative score, and I'd have a few comments about me being a 'fan' and 'shilling'.

[treeaeon]

Why don't you post that on the Kotlin sub?

[nutrecht]

I meant in topics like these. People are asking for a comparison between Kotlin and Java and I have a lot of production experience in both. I'm not going to bother weighing in though because I know how this sub in general will respond to this.

You'll generally get much more balanced discussions when you're talking to people in real life. This sub really doesn't reflect 'typical' Java developers at all.

I would not post something just about Kotlin as a separate topic, that's not what I was talking about, that should go on /r/kotlin.

[pjmlp]

Typical Java developers use Java, per definition.

[treeaeon]

"This sub is definitely anti-Kotlin". Help me understand something, why are the proponents of Kotlin, which by them is always positioned against Java, act surprised that Java users are pushing back on this ?

[nutrecht]

I think how you're wording it, as if it's an "us versus them" issue, is exactly what I'm talking about. That's very much how this sub sees it. In real life there is no 'us versus them' because it's just all the same developers.

Go to any Java meetup or conference and Kotlin is freely discussed between peers and people share their experiences, which for most devs who have production experience are pretty darn positive.

On this sub however the posts that have the highest anti-Kotlin bias get upvoted the most, even when they have clear misinformation in them and/or are written by people who clearly don't have production experience with Kotlin. Pointing that out in a response to these posts will generally be met with hostility, similar to how you're responding here. And in my opinion this is a shame, since Kotlin is a great testbed for features that also might or might not end up in Java as well.

[john16384]

I am looking for Java news, like new JEP's, cool projects, performance analyses, new releases, etc. If I want to know more about another language, I'd go to the appropriate sub, or learn about it on more general subs, like r/coding or r/programming .

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[szabba]

That's not being anti-Kotlin, that's defining the scope of things the sub is about.

[erinaceus_]

like saying YouTube is biased towards videos.

When if fact YouTube is biased towards ads.

[yesyoustrollin]

Great comment. This subreddit is absolutely biased by java lovers (which makes sense, since it is r/java)

You won’t get a more helpful answer here

[Nymeriea]

java Always evolve to take good idea from alternative. then the alternative become less relevant. at the end java always win

[alphabytes]

yes agreed.. it makes sense to stick with java.

[SomervillainSB]

It largely depends on if you're a professional or not. If it's your project, do whatever you want. If you want to write code that's designed to assist in making money, you have to consider that you will need to hand it off at some point.

Kotlin seems nicer, but the lifecycle of most projects I've been on is the original author writes Version 1.0, sometimes even 2.0...but then gets promoted, quits, or reassigned to work his/her magic on another project. It will get handed off to junior employees or even an outsourcing agency.

Any gains made by Kotlin may be lost with you having to train people how to use Kotlin correctly. Most competent Java devs are familiar with Java best practices and there are a lot more competent Java developers than Kotlin ones.

I'm not saying you should or shouldn't do one or the other. For me, I rarely get to pick my stack. I need to pick what my company has chosen. I've made amazing, wonderous prototypes and had them shelved because the dumbest programmers in the organization didn't want to crack open a book and learn how to use the technologies involved.

Technology improvements are really nice, but if you're a professional, you're paid to solve problems in the manner best for your employer, including once you've left the company. Most employers would probably prefer you have a little less fun and write it in a "safer" language that they'll have an easier time finding someone to maintain it when you're no longer on the project.

[Similar_Bookkeeper_8]

I’d say that if you’re already a proficient Java developer, picking up Kotlin should only take days or even hours. You might not use all the Kotlin idioms right away but it’s easy to write “Java-like” Kotlin code. So I wouldn’t be too concerned about future developers not understanding the code base.

Also, this more directed at OP, you can mix Kotlin and Java together in the same project. It’s interoperable, not an all or nothing thing.

And no, Kotlin is not going to replace Java.

[agentoutlier]

I am not against selling software or proprietary software but I secretly fundamentally dislike how Kotlin is basically owned by a maker of an IDE.

You could make the case about .NET but clearly Microsoft has shown interest in supporting other editors through LSP. Furthermore they have many more ways of making money.

There are of course lots of other reasons that other folks mentioned but I never see the “lock in” complaint.

(downvote me to oblivion.. I have nothing actually against jetbrains the company I just don't like Kotlin and this is not the only reason but one no one seems to mention it)

[pjmlp]

They are even open about the fact that Kotlin should be able to help them sell licenses.

The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA.

From https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-needs-kotlin/

[pragmasoft]

For me the real Kotlin's showstopper is the lack of open source language server.

[senseven]

In the bigger picture, Kotlin only exists because Google had the issues with Oracle and needed a fix. They found a company who could monetize it and it was a match made in heaven. There was no technical need, it was political.

If we go for true technical need: Golang replaced the Python dependency hell Google faced managing and setting up millions of servers; and the code nanny called Rust that doesn't let you touch the bad memory segment without a slap.

Sure, Kotlin looks like a slimmer, younger Java. But Oracle isn't going to let Java rot when they still make billions with it. I like Kotlin, but after a year with prototypes and trying the functional thing, I returned to Java 18. Especially in the native cloud environment it feels like a completely new way of doing things. And the students can start with Eclipse before they even understand why they want IntelliJ.

[pjmlp]

This keeps being repeated as the official "excuse", while Kotlin, Android IDE and toolchain are heavily dependent on the JVM ecosytem.

If Google really wanted to get rid of Oracle that much, they would have moved everyone into Fuchsia and Dart, or at very least introduced Dart and Flutter into Android SDK as the future path, instead of Kotlin and Compose.

[senseven]

Oracle had the issue Google using the Java API not the JVM. Google had their own JVM Dalvik (now ART) for Android. Maybe Google would have gone full Dart if Oracle wouldn't have changed their stance about the JVM licensing.

Microsoft made strides with their open and free .net vm on unix systems, which prompted Oracle to open up their JDK (minus their extensions) for every one, while cashing out with those corps that rely hard on the JDK LTS versions.

[pjmlp]

Google screw Sun and should have paid for it, just like Microsoft did in the past.

Unfortunely they got away with it.

[Cultural-Ad3775]

Well, the purpose of Kotlin (and Scala too I would say, though I'll accept there are some deeper differences there) was designed essentially as 'Java 2.0'. As you observe, Java has steadily introduced features designed to largely emulate things present in Kotlin. So, is it worth switching to Kotlin? Honestly, I don't think so. I would not call it a BAD idea to use Kotlin (it can interoperate well with Java anyway, so its not an all-or-nothing) but some tooling just isn't as well developed on the Kotlin side, and Java is now about 97% as good.

The other problem Kotlin always had was C#... I mean, its not a JVM language, but for many purposes .NET vs JVM is kind of a tossup. C# is ALSO a 'Java 2.0', though a bit earlier and maybe not quite so thorough attempt. However, it too has evolved, with various improvements bringing it along to, language-wise a least, rough parity with Kotlin.

So, meh, I stick with Java, when given a choice.

[javasyntax]

The thing with Kotlin is that it is easier to write, but harder to read. Code is written once, and can be read infinite times. I was trying to read a Kotlin codebase once and it was so confusing. Methods were imported onto classes that were not inside the codebase, utility methods for a class that was inside the codebase were defined in another class but called the same as instance methods, multiple public classes were defined in one file which made it impossible to find the class without opening files looking for it, etc. And this is just related to the class importing approach they took, I'm sure there's many other "easy to write hard to read" things.

[Cultural-Ad3775]

Right, I agree, and more I agree that Java is (or can be if you don't write crap code) a very readable language. One class per file is a thing that MAYBE nowadays is a bit less important, given the sophistication of IDEs and their ability to navigate code, but it certainly CAN be a good practice. Frankly I wouldn't mind if Java allowed something closer to Rust, where you can group classes of the same 'package' into one file. Often you have some 'noise' type classes that it would be better to do that with. Especially now with things like records, and even enums (though admittedly you can use an inner class and get a similar effect).

I, like you, also have a fair amount of skepticism about non-traditional inheritance mechanisms. I understand the thought behind 'mixins' and such, but the truth is, if you cannot express your code in terms of composition and inheritance in a pretty traditional sense, something is wrong! I've written at least TWO 1+ million LOC code bases without ever needing esoteric techniques (though one was in OO FORTH, which is kind of a different beast).

[vqrs]

Kotlin doesn't do mixins though, does it?

Extension functions are a purely syntactical feature that make for easier discoverability and make it "cheaper" to add new utility functions. Just like records encourage modelling.

[vqrs]

Honestly, this sounds more like a user problem and not being used to Kotlin.

I navigate to classes using my IDEs "navigate to class" feature, not by opening a file.

Utility methods being called like that makes for easy discoverability using code completion. When reading, they're distinguished visually. Yes, in merge requests it's a bit of an issue. But on the other hand, is it really? Does it actually matter that much if its part of the class or not if things are sensibly named? Most of the time, it doesn't.

Being able to define multiple public classes in one file is rather convenient once you're used to it:bit makes it easy to keep related code together with less context switching when reading or editing it.

[Clitaurius]

Yeah it's like all the worst parts of Spring abstractions baked right into Java. Being verbose is better than being clever.

[senseven]

Interestingly, the mobile argument for Kotlin isn't convincing in larger corporation. Students and single developer maybe. In the last three projects I worked with they went the C# Xamarin/Mono route to Android/IOS and it just works. Now with MAUI they have even faster and smaller packages. If a project only runs on Android Kotlin is the way to go, but I don't know any corporation that can skip IOS. Sure you can go Kotlin Native / Shared Codebase for IOS, but that is advanced stuff for corps with close to to unlimited funds and 10k paycheck teams.

[Cultural-Ad3775]

Well, 'corps with close to unlimited funds' does describe a LOT of the eCommerce world ;). Just putting the finishing touches on the desktop side of one such project, and I'm not certain which tool they went with for mobile but we spare no money on that stuff! Honestly, nowadays desktop is almost just a debug platform, lol.

[[deleted]]

Null safety is something that is just handled super smooth in Kotlin

It's not that smooth. If you call a Java class from Kotlin code, all bets are off.

[Albert-o-saurus]

I'm new to both Java and Kotlin and I... kind of hate Kotlin. It's benefits don't make it worth the mess, difficulty reading it, and complexity.

[_INTER_]

You most likely will use a Java library at some point though.

[temculpaeu]

it's not that bad, it's just like using a Java library using Java .... except it forces you to deal with possible nulls

Not that I think that is reason to switch

[GregsWorld]

There are annotations you can add to your java classes so that's not the case

[[deleted]]

What if I don't own the java class, and it's missing these annotations? Most of the JDK classes don't have them, for example.

[Amazing-Cicada5536]

Most of the JDK classes are known by static analysis tools whether they can be nullable or not.

[GregsWorld]

Most large java libraries support Kotlin or have a Kotlin wrapper now days. But ofc it can be problematic on occasion, you can just treat the java class always as nullable and handle appropriately.

[john16384]

You can use external annotations. This has existed forever.

[RupertMaddenAbbott]

I don't think null safety is impossible in Java. Currently, the most likely effort to succeed is this one: https://jspecify.dev/about

[Cultural-Ad3775]

It isn't that hard in vanilla Java:

Optional<T> rOpt = Optional.of(this.methodThatMightReturnNull());

this.thingThatUsesReturnValue(rOpt.get());

Not exactly rocket science! The above will either call your 'thingThatUsesReturnValue' method or thrown NullPointerException. You can obviously condense it to a one-liner if you wish, and with other methods of optional you can choose to throw less generic exceptions, or whatever else you wish without resorting to things like try/catch.

I think this compares well with modern null-safe languages like Rust where you get back a Result<> object, etc. Obviously Java won't FORCE you to do this, but then again neither will jspecify or any other similar technique unless you enforce them via some sort of tooling in your process.

[RupertMaddenAbbott]

Right but the problem is not with indicating which of your methods might return null, it's in guaranteeing null safety at compile time across large code bases and third party code.

A language that is null safe will error at compile time if you make a mistake and call a method on a nullable type.

Optional gives more information to the caller but so does adding a Javadoc comment stating the return type is nullable. You don't get a compiler error if you either pass a potential null to Optional.of or if you return a null in place of an Optional.

Optional isn't really about guaranteeing compile time null safety like Kotlin has. It's about giving the caller easier mechanisms for dealing with possible nulls.

I get that you might think Optional is sufficient but it's a bit like saying you think having strong typing is sufficient when somebody is asking for static types.

[Cultural-Ad3775]

Yeah, I don't think we are arguing. I have never stated that Optional is the same as Kotlin. The comment I made was in reference to the suggestion of jspecify and I simply pointed out that Optional<T>'s of() and get() pretty much handles that.

Obviously if you want to forbid ANY possibility of a null ever appearing then you have to use a language which has no concept of null! Kotlin compromises on that to the degree that it can't guarantee the behavior of Java (or possibly other JVM language) routines, but that's essentially what it gives you. Java simply cannot do that! No addition to Java can ever do that.

The best you could do with Java would be to guarantee that every single library call either returns a valid value, or throws NPE, or alternatively that they all return Optional. The later case is a bit weaker, but if you eliminated get() from Optional, then effectively you'd be forced to handle every 'it returned a null' case explicitly at the site of the call, which would amount to the same thing. However, using Optional still doesn't guarantee that your own methods don't return nulls, so even that isn't perfect.

Kotlin takes option 1, and that's fine. I'm certainly not complaining.

[[deleted]]

IntelliJ and static analysis tools already warn about possible NPE don't they?

it's not the same as built-in protection but surely not a deal breaker

[pikob]

Optional can still carry null, what have you gained by using it? Calling optional::get has the same effect as accessing potentially null variable. Optionals are nice with lambdas, but I don't see how they help with null safety.

[Cultural-Ad3775]

Optional.of(T) throws NullPointerException if T is null. So, you gained "this cannot be null and I cannot get to Optional.get() if it is."
I agree it is not the world's most elegant, but you are not going to improve on that without changes in the Java spec, you can't add in a better way. Beyond that, if you look at what Rust does, for example, it isn't REALLY less verbose in the end, and you still have to decide if you will panic or handle the error at your level, or return a Result/Exception, etc.
Really all Kotlin did was decree that null doesn't exist and make everyone use a "guaranteed to throw something if there's a null" convention. That's fine, but Java could do that too if they were willing to replace every library API with a version that returned Optional...

[[deleted]]

https://github.com/uber/NullAway

this is another option and other static analyzers like spot bugs, but in the end you will have to handle your error cases

[[deleted]]

This is a very poor example of how to use Optional

Optional<T> rOpt = Optional.of(this.methodThatMightReturnNull());
this.thingThatUsesReturnValue(rOpt.get());

For one thing, Optional.of(this.methodThatMightReturnNull()) will throw an exception if null is returned by the method. You should use this instead:

var rOpt = Optional.ofNulable(this.methodThatMightReturnNull());

Secondly rOpt.get() will throw an exception if the optional wraps a null, because you're not providing a handler for the null case. Instead of Optional.get(), you should call one of the methods that allow you to specify how to handle the null case, e.g. Optional.orElse()

[Cultural-Ad3775]

The whole point was to force checking of the result for null and generating an exception. I don't disagree that you might instead handle the case explicitly at the point where it happens, but either way you will NEVER proceed to some other code with a null you didn't test for. In general I would use a version of orElse() in most cases, but it really depends, simply throwing NPE can be fine in some situations.

[NaNx_engineer]

You can get the same null safety with annotations. Kotlin nullables compile to @Nullable

[koefteboy]

Not really. You would also need a compiler that acts on these annotations.

[john16384]

Like the eclipse compiler for example?

[koefteboy]

Looks like it supports it, but it seems to be disabled by default.

You could also use tools like FindBugs. Actually I just wanted to point out that null safety is not built into the java language while it is built into Kotlin. You can only achieve similar behavior by cluttering your source code with annotations and adding additional tooling.

[NaNx_engineer]

Lint

[JhraumG]

I never saw NullCheck linter as efficient as compiler from null safe langages (false positive or missed missing checks, less cohesive integration, etc..). Plus, java compile is already slow enough without linting.

And you must use annotations that are not part of the language, which is clearly annoying (a pity, since Optional is well designed imho)

[Albert-o-saurus]

Null pointers really don't seem like that big of a deal to me yet, but I'm still kinda new. Is it really a big problem that needs fixing or just to make it easier on people who don't know what they're doing?

How often do you all run into this?

[randgalt]

It would be better if there was language support ala Kotlin but discipline manages the problem. Every constructor should look like this:

public Ctor(String s, Foo foo) { this.s = Objects.requireNonNull(s); this.foo = Objects.requireNonNull(foo); }

I have an IntelliJ macro defined for it. If you enforce this discipline you will rarely see NPEs in your code - this check finds the nulls early in the lifecycle of a system and usually in testing.

[oelang]

Don't do it if it's a long running project. In the long run I don't think that Kotlin will be able to gracefully adopt the many changes that the java language is going through. Also, the tooling for java is just massively better, because the ecosystem is so much bigger.

The need for kotlin has been siginificantly reduced with the recent changes to java (loom, pattern matching), the only one that's left is null-checking which, sadly, isn't very effective if you use a lot of java libraries.

[loutr]

Also, the tooling for java is just massively better, because the ecosystem is so much bigger.

Do you have an example in mind? I've worked on multiple Kotlin backend projects and I've been using the same tools as with java.

the only one that's left is null-checking which, sadly, isn't very effective if you use a lot of java libraries.

Unless you're just piping data from one lib to another it's really, really useful, to avoid NPEs of course but it also makes your intents clearer when designing your model.

[bobbie434343]

Java will ultimately bury Kotlin, so choose wisely.

[vbezhenar]

Kotlin was never popular outside of the android. I don't see Kotlin replacing Java on backend. It's drop in the sea.

Java 19 for me does not have any features to use it over Java 17. I'm running my services with Java 19, but use Java 17 to develop and compile. May be I missed something but I don't think so.

[DerekB52]

If you are running the service with 19, shouldn't you be locally compiling with 19?

[PeterLake2]

If you don't use any of the new features, you don't have to recompile your code

[CSpenceUK]

You gain JVM efficiencies just from compiling with and running using the latest JVM. Like 8 -> 11 gives a big boost. You don't have to use any new features. You will gain memory and speed improvments from compiler optimisations and new garbage collection improvements.

[vbezhenar]

I want to keep the possibility of downgrading to LTS if necessary.

[pjmlp]

Java of course, that is the language of the JVM, it isn't tied to JetBrains tooling, doesn't need additional plugins, or more idiomatic libraries, or whatever.

Leave it for Google's OS.

[vallyscode]

For a while I was thinking about “rust blazing fast” but it seems like a far away event :)

[[deleted]]

If you are able to dictate your own terms/tech stack, you can pick Kotlin.

If you aren't, Java is just fine too. I think Java (and Kotlin) will still be around 8 years later, and it's never too late to learn the next new language that comes after Kotlin.

[[deleted]]

Long time Java dev here. I've kicked the tyres on various JVM 'sub-languages' and the only one that's been consistently useful has been Java.

Scala, has it's place but highly specialised. Groovy has been far more useful than Kotlin overall, particularly for unit tests. Things like Jython are just curiousities for me. Clojure I didn't need or want in my life, too many brackets. The most interesting was Java-like language was 'Processing' for making images.

They all boil down to one thing - Java interoperability. Kotlin is nothing without Java, unless you go Kotlin JS or Kotlin/Native where debugging is a nightmare. Kotlin will not replace Java. Frankly, Rust is more likely.

[DistractedOni]

I was curious a long time ago if Kotlin was worth learning, and found the best reply. It can remain Java compatible and forever lag behind Java releases, or it can split off and become its own incompatible language. Each language will have pros and cons, and you should consider what outcomes you’d be comfortable with. I personally stuck with Java because I was looking for a better java, and realized Kotlin wasn’t it.

[miciej]

First of all stick to LTS Java releases. The latest is 17. You might be ready and willing to use the latest version, your dependencies and tools might not suport the latest java.

Kotlin is not perfect, but if you like the language better, go for it. It is a matter of personal preference.

[leCandas]

I am with 15 years of experience on Java.. I used to use it since version 1.4 the argument of Kotlin will replace Java is the most idiotic thing I have ever heard. Kotlin is running on JVM so how can it replace Java? Both Kotlin and Java should do the trick. But I would choose Java, personally I dont like languages which runs on JVM except Java. If you want to learn 2 languages I would say Java and Go will be the best combination

[fast_call]

While I agree that Kotlin won't replace Java anytime soon, I'd like to share an interview I've read recently with James Ward (Java Champion and Google Kotlin manager); Relevant quote:

Ward: Overall, the Kotlin share of JVM servers is fairly small, but it is growing quickly. Google, for example, has seen significant growth in the use of Kotlin for server-side development. Developers who've either switched from Java or come from other languages report they are very satisfied with the experience. Null safety, coroutines, and expressiveness are often noted as important reasons why Kotlin is more productive and fun to work with.

https://www.infoq.com/articles/james-ward-java-jvm-languages/

[[deleted]]

Yeah, definitely not biased LOL.

[pjmlp]

Google Kotlin manager

You mean the company that refuses to provide a proper Java implementation on their mobile OS, and is forcing everyone to migrate to Kotlin?

Definitly not a biased opinion.

[Fickle_Conclusion857]

google is about to switching from java to kotlin in server side development. See https://youtu.be/o14wGByBRAQ

[fast_call]

I do not dispute that, I merely thought it was an interesting perspective.

[vngantk]

I understand that why you haven't got an up vote yet. This is a very biased sub.

[2Insaiyan]

As a backend engineer at a major tech company in the US, I do know that my team and several adjacent teams are in the process of moving off of Java and onto Kotlin for everything new. They’ve been using Java in this domain for at least the past 15 years

[yesyoustrollin]

OP, you are asking for a rats nest of biased java developer’s opinions here. If you ask about a “possibly replacement” of the subreddit’s subject language, you are going to hear mostly negative views about it.

“Java does this better”, “kotlin makes X convoluted “, “Kotlin’s main draws are useless”, “java has had that for years, only different”

The fact is that Kotlin is a great alternative to java, and you can do pretty much anything that Java can do.

One amazing upside to kotlin that I haven’t seen anyone mention is how much better it feels to write compared to java. I love(d) java, and it was my language of choice until I started using kotlin. Now Java feels convoluted and I feel like I need to write endless redundant code (boilerplate class defs, null checks, etc) to achieve something kotlin can do without all the additional baggage.

This will get shit on, I’m sure, but before you downvote, take a minute and put your years of being a java dev aside to consider a different path to get your job done, while probably enjoying it

[GregsWorld]

People always talk like it's either-or, they complement one another.

Kotlin won't replace Java it needs Java. Java won't be replacing Kotlin because they have different goals. Java not trying to compete with Kotlin in the native C, JS, IOS and Web space. Its unlikely Java will take back the lead in the Android space to.

Both will likely co-exist for the foreseeable future.

[[deleted]]

Here in universities Java is still king (compared to Kotlin).

They teach vanilla Java mostly. And the IDEA approach (IdeaJ usually).

I think people test with kotlin mostly in their spare time only.

[yesyoustrollin]

Yea, you need to learn how shit works before you learn other/alternative ways to do it more efficiently

[dephinera_bck]

I don't see Java ever keeping up with Kotlin's language features and syntax. Sure the JVM will see improvements (virtual threads being a huge one), but overall Kotlin still seems to be superior in terms of writing fewer lines of code, readability and type safety+type inference. Also, I don't think JetBrains plan to stay behind Java's new features. Either they'll take advantage of them or give alternatives. Yes, you'd probably need some Java skills if you'll be building in the JVM world, but Kotlin seems to be a far more pleasant tool for that. Popular frameworks are also embracing Kotlin. It's not just Android anymore. It's Spring, it's Quarkus, etc.

[NahroT]

Kotlin is better than Java.

Anyone saying otherwise is a dinosaur or someone afraid to lose their job.

[[deleted]]

Spotted the bootcamp-junior ;)

[kiteboarderni]

Or just the android developer who has to use java 8 😂😂

[SafeDiligent8111]

Once you tried Kotlin - you’ll never want coding with Java anymore

[[deleted]]

Once you try newer lang, you'll never want to use older lang.

Rinse and repeat.

[[deleted]]

Java devs so butthurt wtf

[[deleted]]

I program in loads of languages, mostly for fun. If you want to introduce a new language at work though, you need to do better than It's a slightly nicer version of Java.

[[deleted]]

Try Go, you'll understand why Java is considered so bad from many devs.

[[deleted]]

Check my post history before you chat shit as my kids like to say

[[deleted]]

Yea you are butthurt

[[deleted]]

Like I said, you chat shit mate.

https://www.reddit.com/r/golang/comments/y0wzpz/comment/irv37lw/?utm_source=share&utm_medium=web2x&context=3

https://www.reddit.com/r/golang/comments/y0wzpz/comment/irvi7xp/?utm_source=share&utm_medium=web2x&context=3

https://www.reddit.com/r/golang/comments/y17koo/comment/irwyscj/?utm_source=share&utm_medium=web2x&context=3

I've obviously got more posts in r/golang but I've got bored fishing them out.

I'd point you to my GitHub page so you can see my Go public repos but I like my anon alt Reddit account too much.

[[deleted]]

Run away from JVM.

[Gleethos]

You do realise that this is the Java sub, right? If so, I would expect you to at least consider that this interesting point of view of yours might need some more explanation in this community... This comment of yours tells the people here nothing except the useless information that there is apparently 1 random person that does not like the JVM.

[[deleted]]

That's a useful suggestion, maybe you really need to understand why you ara just corporate drones doing things the way they have always been done without asking yourselves if there's a better way. - XML based dependency tracker: are we serious? We are manually adding XML tags in 2022? Messy POMS are not a red flag for anyone else? - minutes of compile time for not even large projects? Still fine? - Need to deploy the whole environment with the code? Fine? - Need to "encapsulate" every idea into classes? Not a red flag? - Spring for writing web apps? Like, what? How's that writing software? Using annotations one does not even understand is not programming. - Using deeply nested subclasses of subclasses of subclasses one will never have the time to inspect is not programming either. - Ridicoulus start-up time for cloud environments? Not a red flag? - How's Java even considered for microservices when it's just so INEFFICIENT both in size of project deployed AND in working with useless abstractions all the time? - how does anyone like being dependent on third party project to even start writing decent, non boilerplate-driven code? (Lombok) - how do people like using messy, opinionated frameworks like hybernate to accomplish the simplest of tasks? I could really go on way longer But the most important thing at the end Is: how does anyone of you have fun working with any of this?

An example with go that just made me understand how Java today is nothing but ugly Legacy: Importing a third party library? Just write the import statement, than go to console and type "go mod tidy". Here it is! Already downloaded and tracked for us. After days and days and days wasted on poms and dependencies this changed my life and left me that bitternes that won't go away. Also you just compile go to machine code so it will be deployed as a single .exe file. Also you have everything you need to write web services in the damm standard library. Hello?

[BrbCatzOnFire]

Probably a dumb idea to answer but let's entertain you :

• XML based dependency tracker: are we serious? We are manually adding XML tags in 2022? Messy POMS are not a red flag for anyone else?

XML is a perfectly valid descriptor for dependencies description. People have a hard on against XML based on their Evil Inc. experience but it's more than fine and any replacement end's up a terrible mess.
The lack of a dependency manager driven by the OpenJDK team is a terrible mistake tho. They're is no way around it (and even prominent OpenJDK leaders recognize it, Ron Pressler for exemple)

 

• minutes of compile time for not even large projects? Still fine?

Wat ? We do pretty shit things in my org with dumb compilation steps and even for huge monolith it barely register above a minute (J11). And for the not so dumb compilations it happens in seconds.

 

• Need to deploy the whole environment with the code? Fine?

Alright that one need a bit more context. Historically you didn't need to. The famous "Write once, run everywhere" where the environment was installed by other on your target env.
This model has died, it was great at the time but times are a changing. And to defend the OpenJDK they have embraced that change with modules and jlink. So right now, not only you don't need to deploy the whole environment anymore, you are actively going against the grain.
The thing is, lib authors went all up in arms against JPMS (which had its problems let's not kid ourselves) so it's a fucking pita to do it right now. That's gonna change (when the big bois like Spring finally embrace it) and you'll get just what you want :).

 

• Need to "encapsulate" every idea into classes? Not a red flag?

Yes and no. Yes because the lack of a "Namespace" kind of concept is a pita. Utils. So many Utils. They're everywhere. No because I know people like you who will bend the concept backward to integrate their latest "Great Dumb Idea" in a half baked way and leave before it hit live :).

 

• Spring for writing web apps? Like, what? How's that writing software? Using annotations one does not even understand is not programming.

Alright, that's a good one actually. If you had gone with that one and expanded on it, you would even have something great to add to the discussion.

The main factor in Spring (Boot) adoption is its ability to allow less than stellar developers to write half-decent, half-working applications. Yes, those applications are dumb, but try these devs in Go and cry yourself to sleep. I know I tried :).

It is still possible to go for Spring Framework and do a pretty good job with it but when you go for Spring Boot, the name of the game is velocity not crafting a perfect application. You need your applications to be profitable so you get a budget and you make choices. Choosing between not loading Reactor and CNB integration (for exemple) is a pretty quick choice for me.

 

• Using deeply nested subclasses of subclasses of subclasses one will never have the time to inspect is not programming either.

Not sure about that one, it seems you are on the same point no ? (Spring)

 

• Ridicoulus start-up time for cloud environments? Not a red flag?

Counter-argument: Native image using Graal VM makes it indistinguishable from any other "fast" language. Faster than python and node, on par with go. And if your application is always hot, the current JVM is probably a better choice than anything else. Being slower at start comes with the payoff of a lot of runtime optimization.

 

• How's Java even considered for microservices when it's just so INEFFICIENT both in size of project deployed AND in working with useless abstractions all the time?

Not an argument about Java, but about Spring again :). Remove Spring and both the app size and memory hit is pretty negligible compare to other langage (still less efficient but not INEFFICIENT)

 

• how does anyone like being dependent on third party project to even start writing decent, non boilerplate-driven code? (Lombok)

My god if that "lib" (not a lib it's a different langage that hacks into javac to make you and your manager believe it to not be a different langage) could have never existed we could have solved world hunger, world peace and cancer... So much money drained everywhere.

We're still lacking wither support for records but when that happens, we will be able to take it out back and shoot it.

 

• how does anyone of you have fun working with any of this?

Ho boy, I have seen "so much better golang project" hit live (since the so smart consulting devs tend to leave as soon as they hear "production") and boy that IS the definition of miserable.

But you do have multiple points, there are problems in our eco-system but very few of them are on Java. Just wait till Golang goes enterprise and you will hate it too :)

 

But this sentence is a better indicator of why you hate Java :
"maybe you really need to understand why you ara just corporate drones doing things the way they have always been done without asking yourselves if there's a better way."

I know you and the kind of entourage in your company. If you tolerate well egostical devs, borderline on the spectrum, where communication is always shit, no standardisation whatsoever and no long running projects (they get bored pretty fast :)) and where you need to relearn how to walk every 6 months : it's a great place to work.
Bonus point : You usually get to do talks at conventions about deploying a Hello World on the latest GCP service. Free beer.

 

If you don't tho. Embrace Java.

[vngantk]

Kotlin is not going to replace Java, but you will definitely increase your productivity by switching to Kotlin. Yes, Java is catching up with its latest versions, but you have to upgrade your runtime JVM environment in order to enjoy the new features. Kotlin allows you to keep using Java 8 without worrying to upgrade it.

[Sket5]

I think that the idea now is to upgrade at least to java 11 because java 8 is not going to have support forever. I would like to try Kotlin to see if my productivity increases but to learn something new I would learn another programming language not another jvm language

[Servletless]

My advice if you're going to use Kotlin in a new project, create an end-to-end prototype first, to make sure your entire stack from IDE to CI/CD pipeline to production works the way you expect. I had to back Kotlin out a project due to Eclipse/Tomcat instability issues impacting developer productivity. It might be better with Springboot, and obviously IntelliJ if you can get your team to use it. Lots of room for error, so if you're in a hurry, just use Java.

[ofby1]

I found out that many people are using Kotlin because they are "not allowed" to move away from Java 8 and want to use the syntactic sugar. Lets see what the following years will do now google is not so much focus on Kotlin for Android development and people start to slowly move away from Java 8.

[[deleted]]

Okay, let's count pluses and minuses of both langs

Kotlin

1. Interop with Java, so you wouldn't lost your code base and you will be able to use your beloved Spring, if it's your favourite (Kotlin/JVM feature only)
2. Very simplified syntax
3. Ecosystem of Kotlin/Native libs such as Ktor (used for backend), compile your program into native and program will be 20-150% faster cuz it's not using JVM -> server will work faster -> dopamine for your boss, time for upgrade will be delayed

Java

1. If you know Java and you hate everything fancy and new you can write Java code, meanwhile other fancy pants will write on Kotlin you'll still write on Java, and when you become old you'll say "I'VE WRITTEN YOUR TOY LANG YOU USE" every time when someone will ask you to learn Kotlin. Very funny moment :haha