My name is Viacheslav Aksenov, I am developer of big and complex backend systems. I started from Java 7, than upped to Java 8 and sometimes Java 11...
For further actions, you may consider blocking this person and/or reporting abuse
This interests me for a number of reasons (that I can happily get into, if appropriate).
I was going to pick through your list, and post a response from the Java perspective, but lets cut to the chase:
Assuming that is your motivation for the list, Java boilerplate can be removed in 3 ways:
Then there's this:
Forgive me, but code style is an internal discussion, and a document. That produces a formatter (IntelliJ will work with an Eclipse formatter export, etc). That even deals with your "one line method" claimed benefit (our formatter forces methods to one line, if the body of the method has one line, overriding our line length constraints).
I genuinely get the impression, and I'm sorry in advance if it's incorrect, that there's motivated reasoning behind this post - you like Kotlin, therefore everyone should at least try it.
Since I manage a Java development team, and one of my developers semi-frequently (and half jokingly) says things like "this would be easier in Kotlin" - I'm genuinely interested to hear concrete business benefits to using Kotlin over Java in the development cycle. My starting premise: more developers understand Java than Kotlin, so hiring people is easier.
About the same reasoning I have. We use Spring + Lombok and it solves a lot of the pain points (although some remain). Kotlin does enforce better guard rails (null-handling for example), but at what cost?
When it comes to features that Java has implemented after others have shown how it can work (e.g. instanceof, loom vs coroutines (I know, not out yet), record types) I do have to say I like the Java version better? Might be a preference but it seems that Java is slowly catching up while Kotlin in the near future has to make some hard choices on how they wish to do things (ref the reddit article posted earlier highlights this in a good way).
Although, your post about LTS further up I am less sure about but I guess that also might depend on context. We run Java 16 just fine in production for mission critical applications and have no issues with it. No service agreement either, as long as we have a robust set of tests and can deploy at will with good monitoring, we have seen no issues with this over a long period of time (not always Java 16 but keeping us at the latest version).
I know very little about the practical meaning with LTS (I've understood its more about backporting bux fixes from latest) but I might be wrong here so please correct me if I am.
The "Kotlin cost" - from my perspective, is that I already pay Java developers. Why do I need them to go through the cognitive complexity of learning a new syntax, if we're just going to run it inside a JVM anyway?
That, and Graal looks really interesting, as soon as MS sort out SQL JDBC compatibility, though I know that's on their roadmap. I haven't a clue what native compilation would look like in Kotlin, and the benefits of native compile far outweigh the niceties that Kotlin may bring to the table... though, that's diverging from the topic a little... and Graal will likely force us to stay a little behind the JVM release cycle.
LTS - for us, at least - isn't about "can I run this in Production." It isn't even about the level of support offered. It's more about buying time to weigh up options when avoiding vendor lock-in situations.
For an example there, we still have a large number of projects that run in a very specific build of Java 8. At least one of them, for reasons I haven't yet fathomed, will happily compile in 9... but then it refuses to run. Even when you ask javac to give Java 8 compatible bytecode. Then, during the our future migration of that project, I need to worry about reflection API changes within the JVM over time, etc etc. Plus we have dependencies to worry about, like our Tomcat version and which Servlet API it's using, or can work with and not break other dependent projects...
Sometimes, it simply makes more sense for legacy projects to stick with an LTS. Then when that's approaching EOL, we can look at "is it more beneficial to just bin that project, and re-write it?" - which also opens options for "should we do this in Kotlin/dotnet/Java/JS/C++ etc and which of those options gives the best ROI? Which team has the skillset to do that before EOL? What new features of these languages do we want to benefit from?"
Equally, our build pipeline is really simple to switch between Java versions and see if a project works in a different version... but that's why, ultimately, the language & version is a decision based on what's best for the business, not what makes developers feel cozy & warm (there's better ways to make developers happy, rather than chasing the latest tech all the time).
I mean, I still read the JVM release notes and geek out about upcoming changes, and share those around the business...
Jepp, and as Java gets more features anyway, many things will get better. So personally we have not switched although I do from a developer perspective like what Kotlin has done, but from a broader view we have not swapped although some people want to, with the same reasoning as you have combined with the fact that Java is moving along rather fast now (and many of the small things can be fixed with frameworks/libs anyway).
Okey, I understand the premise with LTS for your sake then, thanks for clearifying.
Great post, and although I love what Kotlin has done, what are your thoughts about the future?
For example, a language that says one of its features is that its very similar to Java but considering that Java is also up'ing its iteration cycles, how will this affect Kotlin in lets say, 2 years?
A great post that puts it in a bit of perspective: reddit.com/r/java/comments/ndwz92/...
I don't advocate in absolutes, but thinking about what your choice given your context and also taking a look into the glass ball might be a good approach.
I've read this insightful comment about what happened when Java adds new features that were in Kotlin only before. New features released in Java is a good thing IMHO, it means the whole ecosystem progresses. But for people to actually use the new features, they have to be willing to update the SDK. But it turnns out Java programmers are very wary of updating the SDK. Java 16 is released but we are still in the middle of the migration from Java 8 to Java 11.
So Kotlin is perhaps doomed in the long term, but in the long term we are all dead!
Who told you that people are wary of updating Java?
I mean, I wouldn't want to use something in Production that didn't have an LTS agreement behind it, but that's not only limited to Java.
The main issue, is the security manager and Modules when moving through Java 9/10... but maintaining legacy projects always has legacy problems. All our newer projects are in Java 11 when deploying, or 14 during development (Maven profiles...). When we hear the next LTS release beyond 11, that will be our default - the next morning (and CI/CD will log tickets for projects that fail to build for some reason).
Challenging, yes, but wary?
I agree if the premise is SDK 8/11 or Kotlin forever, but at least the place I have been (mostly public sector) has seen a shift into product teams with autonomy, so updating to a new SDK has and is not an issue.
Also, if the issue is that companies refuses to upgrade the SDK, can that be applied to Kotlin as well (over time)? Or is every part of a company that uses Kotlin always able to upgrade but those that use Java are not?
I love kotlin as much as the next guy, it's just that every post I see about Kotlin vs Java is about the small stuff (which of cource comparing Java 8 vs Kotlin leaves java with a lot of bruises), but I never see any discussions about the negatives? Cause if I am to suggest to a customer, a client or just my co-workers that we should change, it also has to include the down sides and usually with a timeframe more than a year ahead when picking a language for a product. And if the premise is that people don't upgrade SDK, the same can just as much be applied to Kotlin and then you gain little. Something along the lines of: Fix the culture before you try fix it using technology.
Edit: And I agree, I love that people see Java and think in the lines of: "We can do this better!", such as Kotlin did. And as we see now, the ecosystem and Java is also better off. Java has its weaknesses and luckily some of them are being adressed. This post is rather good if you wish to see how the JVM team is thinking about changes: blogs.oracle.com/javamagazine/java...
Updating Kotlin is not the same as updating Java. In the second case you upgrade the virtual machine and hope for the best, which has been sometimes painful in the past, while when you update Kotlin you are still compiling bytecode for the same virtual machine, so you keep the same infrastructure.
And yes Java being a very mature technology has pros over Kotlin, for example the compiler is faster and static analysis tool are better. And hiring Java developers is easier, outside of the Android world, you may have to be OK with developers learning Kotlin on the job.
Yes, I agree with those premises. although I wish it came more apparent in the discussions between Java or Kotlin
@jmfayard
you upgrade the virtual machine and hope for the bestThat sounds painful to even read. Please tell me someone you work with has read, understood, considered and then tested the upgrade path, before just "hoping" it will work...
Kotlin is already like Java 16, and much more, and you do not need to switch your JVM. You can keep using your most comfortable JVM 8 or 11.
Interesting read. I understand the benefits of Kotlin, but the payoffs don't seem to be big for developers who have experience with Java already. What people forget that there are many JVM languages such as Groovy, Scala, Clojure...etc, and I think that diversity is cool, but most of these languages are offering something quite different than Java e.g. Groovy is dynamic and good for scripting..etc. Kotlin seems the most like Java, but it's biggest selling point is less boilerplate.
What is different than the other JVM languages is that Kotlin has the most mainstream traction. This seems to be mostly because Google promotes it for Android development. I was learning some Android programming and I found it muddied the waters that tutorials and examples are mix of Java and Kotlin. If you consider that Java adopted some features from other languages in later versions, I feel it hurts education and adoption in the long-run if there is a migration. If you learn Java in university and companies are mostly using Kotlin, it's making it a longer path for people starting off.
I haven't delved into Kotlin, so I don't want to show bias, but based on what I know now - I would learn Scala over Kotlin. You gain more from delving into a different programming paradigm and using a language that has different applications.
Kotlin is very different from other JVM languages, not because it has anything very special as compared to others. It is because it is a very practical alternative to Java. Groovy and Clojure are dynamic typed and Scala though it is more advanced but just too complex for many people. When you switch to Kotlin, you immediate enjoy all benefits of Kotlin without worrying any compatibility issues with your favourite Java frameworks, Spring, etc. They all work flawlessly in Kotlin. If you have knowledge about Java, the learning curve of Kotlin is very minimal. If you don't bother to learn anything new in Kotlin, you can simply write a Kotlin program that looks very similar to a Java one (with just some minor differences in syntax). You can also keep your existing Java code. The Kotlin compiler compile Java code too, so you can keep your existing Java source files along with your new Kotlin source files in the same project.
Actually all these stuff adopted from father of Kotlin which is Scala. But this article still gives a very good gathering of Scala excellence over Java, and hence so valuable to me to the point that gave me a brilliant moment of enlightenment.
Anyway I encourage the author to write another article named such as "10 reasons to switch from Kotlin to Scala right now!" and select 10 (from at least 100 one of) features of Scala not available in Kotlin from it's advanced type system targeting soundness; and new metaprogramming capabilities come from any source code's Tasty IR; and functional effectless programming combined with actors for uncomplicated asynchronous microservice implementation; also mentioning ScalaJS to replace Kotlin and JavaScript for web and ScalaJVM plus Jetpack Compose to replace Kotlin for Android.