Is Java catching up with Kotlin?

Language Design
21

I agree, we do not want Kotlin to become the new C++ or Scala, where the language gets too complicated to use or very slow to compile due too many complex features added, while still having to be backwards compatible. Kotlin is already a really great language, and I would hate to see it getting ruined by a frenzy of less than needed features.

Are there things that can be improved? Yeah, sure, but I rather see that JetBrains takes their time and makes sure everything is developed in a good fashion and with the long term well being of the language in mind. Focusing on performance and refactoring and improving the compiler lays the foundation for adding additional features later, so I think the current priority is in everyone’s interest.

2 Likes
22

Indeed, progress doesn’t have to be in the form of language changes, and certainly not in the kitchen sink approach taken by Scala. It could be in standard libraries, tooling, or frameworks. The best progress tends to involve many aspects of the ecosystem progressing together.

As @fatjoe79 pointed out, the biggest problem here might be the lack of a public roadmap, other than refactoring the compiler. Are there no decent KEEPs? Is Kotlin really in such a perfect state that there are no significant user-facing improvements to be made, other than speed of compilation?

23

Oracle’s open mind about discussing Java ideas with the community is something I’d like to see Jetbrains adopt.

4 Likes
24

Me thinks that Multiplatform is a killer Kotlin feature.

It’ll take years for people to understand that. I’m waiting for libraries out there like lucene or berkeleyDB start migrating their code base from Java to Kotlin to make their stuff usable everywhere (browser/native/js) with 1 code base

Making the Kotlin compiler do it’s work fast is another killer feature.
I remember having to wait 2 minutes to compile a small project on android. This sucked.

Go is successfull also because it compiles a lot faster than C++
Nobody wants to wait hours after doing some trivial change.

Also, fundations are really really important to get some great work done.
And for enabling future features.

So… I was also a bit disappointed not to get new shiny features in the next kotlin 1.4 but, after reflecting a bit, maybee I got a lot better than what I was expecting with 1.4.

Good job Kotlin team :slight_smile:

2 Likes
25

I recently had a discussion with my older brother about kotlin. His team started using kotlin native some time ago and from what I can tell he really likes it. The problem he seems to have is with libraries surrounding kotlin native/mpp. From what he says things like the serialization library still need a lot of work. On the other hand there aren’t any features he is missing on a language level (yes some keeps are interesting but not vital). Also we both agree that Kotlin is the best tool on the JVM already by a big margin.
So based on that I like the current focus, maybe it should be even stronger on extending the mpp environment. Compile time performance as well as unifying the compiler will probably help with that as well if this allows for faster iterations in the future (both of kotlin and projects written in kotlin).

26

You make that sound simple, but most libraries have dependencies themselve which are written in Java. For a library to be rewritten in pure Kotlin, it will need to wait for its dependencies to be rewritten first.

3 Likes
27

Sorry if I was misleading. You are right. It isn’t simple and it indeed all depends on dependencies being converted to Kotlin. So far, it has only just started :
There is a project to add a kotlin target for antlr : GitHub - ftomassetti/antlr-kotlin: Support for Kotlin as a target for ANTLR
Some popular libraries (okio, okhttp, android api) are being converted to kotlin…

For complex projects like lucene, JanusGraph… to even consider it, dependencies have to be converted to kotlin first.

I’m just saying, that there are a lot of benefits to migrating java code to kotlin (null safety, …, targeting other platforms) and there are a lot of people that have become adepts at converting java to kotlin…
like 50% of android developers. There is even an idea intent that does a good job at automatically converting java to kotlin.

So well, yes, it cannot become better than that :slight_smile:

I am just expecting for library authors to get, at some point in time, that it might be a smart move for them to migrate their decade old java libraries to kotlin… which is a process that can be incremental.

Definately not simple and not done overnight, but when you have done it, you harvest some great benefits and make your library more relevant…

In the same way that, when you code in java, it sucks to use a library written in C++, you have to use jni. It is much better to use a library written in pure java.

Same for Go and C/C++ I guess

So, well, I’m waiting for libraries to migrate to kotlin… ^^

1 Like
28

I finally came around to watching the video from Kotlin Conf. Here it is on youtube:

Judging from this there are essentially two cases:

  1. Java maybe might someday implement something that Kotlin already has except in it’s typically clumsy, limited and painful style ie var only usable on locals and multiline strings that drop trailing whitespace

  2. Java maybe might someday implement something that Kotlin already has except better because they can modify JVM to support the feature such as sealed interfaces.

I don’t know about you but I don’t want to wait 4 more years for Java to maybe come near parity to what Kotlin is right now especially considering that Kotlin is going to jump on anything in case 2) the minute they can also use the new JVM features.

Plus, I think the fact that Java might break the Java Beans conventions in their record type implementation will cause A LOT of controversy and problems in the next few years, all of which you can neatly side step by using Koltin which will just “Do The Right Thing”.

4 Likes
29

I don’t think that anybody here genuinely thinks that Java will be catching up any time soon. However, it is still nice talking about those ideas that might come to Java in some years. Discussion is beneficial, and Java has more semi-official discussion going on right now when it comes to potential language features.

1 Like
30

There are plenty of features in this 2.5 years old survey: Kotlin Future Features Survey Results, some of them are already implemented, but there are plenty to go.

Also my personal wish is string interpolation (not dumb concatenation, but actually allow access to all arguments with optional format parameters). Something which allows print("${x:.2f}") or execute("insert into t values (${x:varchar})").

31

Ok so why dont you define your own extension properties and methods for your smart string interpolation
instead of writing ${x:.2f} do something like ${x.f2} or ${x.float2} (imho this is more straight forward and easy to understand), usually i keep around one long named self explanatory version and one short version that simply calls the long name one inlined…

Personally i often find myself defining lots of methods and extension properties, and later i see jetbrains adding something similar sometimes identical to standard library. The language has all the tools you need to write concise and performant code imho

32

I don’t understand you. I need value and type of variable x. I can’t write it with my own extension. I need compiler not to concatenate interpolated string, but to collect all substrings and all values (and better not values, but Supplier-s) and pass them to my function where I’ll construct the resulting string or object.

.2f is easy to understand because it’s standard Java format derived from C printf format which everyone knows and it makes sense to re-use it. But it’s just an example. It’s not supposed to be built into compiler, it’s supposed to be implemented as a library function.

33

Ok i see what you mean, well yeah thats something one could do, but take into consideration the more smartness you ask from the compiler the slower and clumsier its gonna get…

Look at scala and sbt… every time i worked with it with anything bigger than simple project i hated it, every full build meant a coffee break, incremental build was not reliable, all because language has so many features you have 15 different ways of doing the same thing.

I’m very much agnostic to programming languages, i don’t obsess over one and prefer to use the best tool for the job, and for last couple of years i do not know any backend typesafe language that does something in more readable and performant way than kotlin… there is no case where i would think oh you know i could do this much better in language ${X}… that is typesafe stuff (but then kotlin is slowly adding support for native and js…) so i think they are doing everything right and i’m super happy someone actually stepped up the game for backend jvm languages.

As for java for me its dead, i only care for better jvms cos thats where my stuff runs, and to be honest if there was no kotlin we probably were still stuck with stone age with oracle… no competition no incentive to improve, so i do not imaging what java needs to do for me to consider relearning all the good stuff i already know how to do.

1 Like
34

I know most things that need to be said on this have already been said but to throw my two cents in I don’t think Java will ever surpass Kotlin for one reason, null safety. Java is a very old language and many Java libraries, frameworks, and applications are set in their ways and because of that Java can never be truely null safe, that’s the beauty of modern languages though, they can see the mistakes of the past and improve upon them like Kotlin has and in the future I wouldn’t be surprised if there was a better language made to replace Kotlin.

35

Introducing null safety to an existing language in my opinion seems to be on par with introducing parameterized types / generics. I don’t say that Java will ever do this, but it seems doable.

3 Likes
36

Yeah it’s definitely without a doubt doable but it seems highly unlikely that it would be done and even if it is there are still other benefits Java can’t touch Kotlin in like the native compiler.

37

Oracle’s GraalVM seems promising. It attacks native from a different direction than Kotlin native does.

2 Likes
39

Kotlin Native is far more memory efficient than JVM or GraalVM and will probably improve in speed in the future too, we also don’t know if the Kotlin Native examples had optimizations enabled so Kotlin Native might perform even better with this example than we think.

1 Like
40

Regarding introducing null safety to an existing language, Dart is preparing to go down that road now: Null Safety: Sound non-nullable types with incremental migration (NNBD) · Issue #110 · dart-lang/language · GitHub

41

Overall, I am proud of the progress of the past few years.
The only thing I miss in Kotlin are collection literals. Implementing nested lists or maps is so ugly.
I played with Flutter/Dart a little bit which is also statically typed and holy… UI design has lots of nested lists and doing it in Kotlin is even worse. And this “to” keyword when defining maps, is this even concise? A simple “:” is enough!

4 Likes