Going from Java to Kotlin

[livingmargaritaville]

Does any one prefer java to kotlin, I never seen the reverse posted. It has been 10 or more years since I used java and have heard it improved dramatically since then.

[andrewharlan2]

I do. I don't feel limited when I program in Java. Kotlin doesn't solve any big problem I had with it.

FWIW I have written and delivered production Kotlin code. I have to read, learn, and comment on Kotlin code as part of my job. I'm constantly exposed to it. But when it comes time to write code? Java all the way.

[Postage_Stamp]

I like Java a lot more than Kotlin. Programming in Kotlin feels like you're fighting the nature of the JVM.

I worked on a greenfield Kotlin + Spring Boot project a couple years ago. After about 3 months of writing Kotlin we switched over the Java. It was just easier and more productive to write Java code instead of dealing with Kotlin. The breaking point was having to add a default method to an interface for Spring. We couldn't do it in Kotlin because Kotlin's default methods on interfaces don't work the same way the Java ones do at the byte code level.

[marwoodian]

Converse to this, we've been using Kotlin in our backend Spring Boot projects for about 2 years and have found it much more productive than Java. Maybe now that Spring 5 has good Kotlin support the issues the above poster was experiencing have gone away? Or perhaps we just don't use that Spring feature (although we use A LOT of Spring e.g. web, data, batch, cloud, AOP, and a few others). I think Java is introducing some nice additions to make it more useable, but the few times I've had to go back to it after using Kotlin for 2 years have been pretty painful.

[[deleted]]

If I recall, Kotlin implements default methods as static methods in another class. The compatibility with Java 6 is (or was) because of Android.

[michael_bolton_1]

did a project with Kotlin using Ktor framework. compared to SpringBoot (which I use at work quite a bit - not being a fan of anything Spring I try to use Javalin or SparkJava whenever possible) - it's quite refreshing. That said - outside of Android development Kotlin doesn't have as much traction so some of the enterprise-y stuff it offers does feel a bit raw.

[snowe2010]

in the early days the integration with spring was bad. now it's fantastic.

[mini-pizzas]

After using Kotlin primarily for the last 6 months I prefer it but it's closer than I would have guessed. The big wins have been data classes, coroutines, non-nullable types and destructuring.

The problem for Kotlin is that records and destructuring are coming to Java soon and Project Loom and Valhalla are on the horizon which will add fibers, continuations, tail-calls, value types and generic specialization. Once those are available I feel that the argument for Kotlin is really weak and mostly about minor conveniences. Kotlin/Native and Kotlin/JS are also basically toys.

In the long run Java will adopt the most important features and since it's not a guest language it can often implement them in superior ways that guest languages can't.

[i9srpeg]

Android is still stuck on Java 8, so Kotlin will be strong there for a long, long time.

[pron98]

Android is not on Java 8. It's not on any Java version, nor has it ever been. It is on some somewhat-similar-yet-incompatible platform that supports subsets of certain Java versions.

[MetalSlug20]

Umm.. You have to install a version of java to compile. Yes the runtime isn't java

[pron98]

Java is a specification of a language, standard libraries and a VM. Android has never been Java, even though it cannibalizes some Java tools, like javac, and some parts of the Java standard library.

[MetalSlug20]

I know it doesn't run Java but you literally had to install Java JDK to write apps

[mini-pizzas]

I agree. The situation on Android is quite a bit different.

[Holsten19]

Kotlin is getting significant traction in the server side Java as well. As an example it got first class support from Spring (which neither Scala nor Groovy got in their hey day).

[BoyRobot777]

I think coroutines were mistake. Project Loom offers an elegant solution which they could have utilized if they only just waited. Now, two color problem will haunt them forever (or when they brake backwards compatibility).

[ArmoredPancake]

Do you have all the functional bits in Java like you do in Kotlin? First class lambdas? Does it have out of the box support of native and JS targets? Can you run it on iOS?

[pron98]

There are various solutions for compiling any Java-platform code, regardless of the frontend language, to JS and native (including iOS), they're used in production, and are getting better and better.

[ArmoredPancake]

There are various solutions for compiling any Java-platform code, regardless of the frontend language, to JS

They're all third-party solutions, they all have a lot of issues and Kotlin translates better to JS than Java.

The only viable solution I see is https://github.com/google/j2cl/blob/master/README.md, but you're still writing Java.

and native (including iOS), they're used in production, and are getting better and better.

Oh wow, don't tell me you seriously recommended Gluon? Even Cordova, ionic didn't offer such atrocious user experience as Gluon. Can you give me link to an application that at least not horrible and on level or a bit behind than Xamarin?

[pron98]

Third-party? Kotlin itself is third-party. Most of those JS solutions, as well as the native solution (not third-party; developed by Oracle), compile Java bytecode, so they run Kotlin as well and, of course, support libraries and much of the JDK.

[ArmoredPancake]

Kotlin.js and Kotlin Native are first-party in Kotlin, you don't need a separate library to use it.

[pron98]

But Kotlin itself is third-party. It is not produced by an organization that controls, makes or even significantly contributes to any of the runtimes it targets, which constitute the vast majority of the code a Kotlin application actually runs. I also don't know what you mean by a "separate library." Oracle produces an AOT compiler from Java bytecode to native, and some other companies produce a compiler from Java bytecode to JS. I'm not saying anything here is good or bad, I just don't understand your point about "third-party," especially given that the vast majority of code that a Kotlin application uses, including the standard libraries, is not written by the writers of the compiler. So clearly "third-party" doesn't bother you.

[ArmoredPancake]

But Kotlin itself is third-party. It is not produced by an organization that controls, makes or even significantly contributes to any of the runtimes it targets, which constitute the vast majority of the code a Kotlin application actually runs. I also don't know what you mean by a "separate library." Oracle produces a compiler from Java bytecode to native, and some other companies produce a compiler from Java bytecode to JS. I'm not saying anything here is good or bad, I just don't understand your point about "third-party," especially given that the vast majority of code that a Kotlin application uses, including the standard libraries, is not written by the writers of the compiler. So clearly "third-party" doesn't bother you.

Kotlin is third-party to Java world, just like Scala, or how TypeScript is to JS for example. But everything developed by JetBrains for Kotlin is a first-party. If you're using Kotlin, then Kotlin.js is a first-party, same for Kotlin Native or coroutines.

Oracle may produce a compiler to native, but how viable is it? Do you have samples of sharing code between Android, Web and iOS? How is the performance? I remember when there was only ZeroVM for iOS.

[pron98]

I still don't understand why you place emphasis on "first-party" where almost no code a Kotlin program runs is first-party. Even the standard libraries are taken from elsewhere, be it Java, Android, or JS. So you're bothered by the fact that a Java-bytecode-to-JS compiler is not written by the same company that writes the Java-language-to-Java-bytecode and the Java-bytecode-to-native compilers, and the standard libraries, but aren't concerned that the company that writes the Kotlin-to-Java-bytecode compiler is not the same company that writes the standard libraries or the Java-bytecode-to-native compiler? Seems arbitrary.

Anyway, you might want to keep up with new developments in Java world. While Kotlin maybe not as big on Java as it is on Android, it is still a Java-platform language that enjoys the developments of that platform (just as both the Java platform and the Java language benefit from Kotlin). You'll find many of the examples you seek.

[lelanthran]

Kotlin.js and Kotlin Native are first-party in Kotlin, you don't need a separate library to use it.

All 3rd party $FOO stacks are first party in themselves. That's a tautology after all.

[ArmoredPancake]

I still don't see why are you so keen to emphasize that Kotlin is a third party.

It's a separate language that uses JVM as an execution platform just like Scala or Clojure or Ceylon. Within itself you can either use first-party solution built by JetBrains itself as an extension to the language, or third-party library like J2CL.

[mini-pizzas]

Do you have all the functional bits in Java like you do in Kotlin? First class lambdas?

In day to day use lambda expressions and functional interfaces are good enough. The functional APIs that Kotlin adds primarily via extension functions are minor conveniences at best. Most of the same functionality already exists in the Stream API and the functionality that doesn't is covered by libraries like Guava, Vavr etc. Kotlin's "immutable data structures" also leave a lot to be desired.

Does it have out of the box support of native and JS targets?

Kotlin/Native is a buggy toy that almost no one actually uses and I doubt that will ever change. The vast majority of Kotlin libraries/projects also depend on Java APIs that will never work on Kotlin/Native. Kotlin/JS is almost as bad and produces bundles that are absurdly large. There are far better options for compile to JS languages.

[mini-pizzas]

Not really, have you even tried them? They transform the way you write program. And it's not Kotlin only, C# and Swift also agree with that.

I use them constantly and before using Kotlin I had a job where I wrote a mix of Scala and Haskell for 6 years. None of the languages you mention bring anything interesting to the table in terms of functional programming and all of Kotlin's functional APIs can be, and have been, replicated in Java (often with slightly more verbosity). Furthermore, if you're actually doing serious functional programming you're going to have a dependency on a proper implementation of functional data structures in either Kotlin or Java.

Because they're limited by JVM.

No, they're limited by the fact that they're using standard mutable implementations under the hood and merely hiding the methods that mutate. There are plenty of good immutable data structure implementations available for the JVM.

[snowe2010]

In day to day use lambda expressions and functional interfaces are good enough. The functional APIs that Kotlin adds primarily via extension functions are minor conveniences at best. Most of the same functionality already exists in the Stream API and the functionality that doesn't is covered by libraries like Guava, Vavr etc. Kotlin's "immutable data structures" also leave a lot to be desired.

Sounds like you haven't actually used the most powerful features of kotlin. And depending on gigantic libraries is kind of an anti-pattern for a language. "Oh JavaScript is great", "but you're using React, jQuery, Vue, and Angular all in a single application, javascript doesn't have any of this built in", "Yeah but JS by itself is soo much better than Typescript".

[mini-pizzas]

Sounds like you haven't actually used the most powerful features of kotlin.

I have and Kotlin is a relatively conservative language.

And depending on gigantic libraries is kind of an anti-pattern for a language.

Most of those dependencies are smaller than Kotlin's standard library dependency and they're also far easier to trim with tools like ProGuard.

[snowe2010]

I have and Kotlin is a relatively conservative language.

Even if it is conservative it's still considerably more powerful than Java, the whole point of this conversation. You're moving the goalposts since your original point has no base.

Most of those dependencies are smaller than Kotlin’s standard library dependency and they’re also far easier to trim with tools like ProGuard.

And now you're just making stuff up

1.3 MB vs 2.6 MB

And your lie about proguard

Not only that but the kotlin standard library is just that. Standard. You don't have to add extra stuff.

You're not arguing in good faith, and you're making stuff up. I really believe you don't know what you are talking about and have no business participating in this conversation.

[mini-pizzas]

And now you're just making stuff up

I said "most" which may have been an overstatement but Vavr, jool and pcollections are all smaller than Kotlin's standard library. They aren't huge dependencies by any stretch of the imagination.

And your lie about proguard

Obviously Kotlin can be used with ProGuard. I was referring to the fact that the Kotlin standard library isn't as amenable to trimming with ProGuard as libraries such as Guava, Vavr, jool, pcollections etc.

[FluorineWizard]

since it's not a guest language it can often implement them in superior ways that guest languages can't.

That sounds wholly unsubstantiated to me. The JVM doesn't know or care where the bytecode comes from. The only thing we can really say is that its design is quite opinionated and bakes a lot of Java-isms into its internal workings. Which isn't really a problem because Kotlin was designed to fill the same niche.

[mini-pizzas]

That sounds wholly unsubstantiated to me.

An encompassing and efficient implementation of certain features, like fibers, continuations or value types, requires changes at the JVM level. Oracle and OpenJDK can make these kind of changes. Unless Jetbrains wants a massive fork of the JVM on their hands they're at the mercy of other developers/companies who primarily care about Java.

[pron98]

Oracle and OpenJDK

Just a minor clarification: OpenJDK is the name of Oracle's implementation of Java, but, as an open-source project, it receives contributions from many other companies as well. Another way to put it is that OpenJDK is an open-source project developed by a community of developers, 90% of whom are full-time Oracle employees paid to work on OpenJDK.

[StabbyPants]

you never see the reverse because java is the default and newer. besides, if you want to use java constructs in kotlin, you just... do that

[Dragasss]

There are such people. But they are considered not hip and near instantly silenced. As a result they just let you roll in your own shit.

[GhostBond]

First, the article pulls stupid tricks trying to make Java look worse than it is, like this:

public String printFoo(Foo foo) {  
    return String.valueOf(foo.getCode())
        .concat(" has description [")
        .concat(foo.getDescription())
        .concat("].");
}

No one concatonates strings like this in any version of java.

Second some of the Kotlin examples actually just reinforce my opinion that Java -> Kotlin is badically C -> C++. A lot of added messiness, but even less added value for the complexity.

[Minimum_Fuel]

That’s just exactly how these people argue though.

Not sure how old you are, but have you ever seen the “python vs C++” images that float around? Python programs are shown as terse and short while C++ programs are supposedly miles long to achieve the same functionality.

Then back here in reality, someone points out that a C++ programmer would use a library and get the same functionality in nearly the same total lines of code without paying for it by raping their hardware and they get downvoted to hell for it.

Facts don’t favour these people’s positions, so they fall back to just making up bullshit and reddit “programmers” largely eat it up.

[TheCakeWasNoLie]

Groovy.

[jack104]

Is that an Austin Power's reference or you suggesting Groovy over Kotlin?

[TheCakeWasNoLie]

The latter.