15 ms·
Let me ask a question as someone with pretty minimal Java experience. If someone was starting a greenfield JVM project today, is there really any compelling rea
by dcolkitt 7y ago
Let me ask a question as someone with pretty minimal Java experience. If someone was starting a greenfield JVM project today, is there really any compelling reason not to choose Kotlin over Java?
Because the impression I get is that Kotlin is a strict improvement along every dimension. But as an outsider, I'm not sure if I"m just being blinded by hype.
- abraxas 7y agoThere are far more resources out there for learning Java, better tooling support beyond IntteliJ and many of the cool features of Kotlin are slowly making their way to Java.
- hv42 7y agoWhile some of the features in Kotlin are slowly coming to Java, that also means that one has to update Java (while you can use all the new kotlin while still targeting Java 8). Some features like named parameters or null checking might probably never make it to Java. There is a nice talk about this that compares Kotlin to what will be in Java 19: https://youtu.be/te3OU9fxC8U https://youtu.be/te3OU9fxC8U
- vbezhenar 7y agoIf you want null-checking, you can use Nullable annotations. While they're not as good as proper type system, they mostly do the job.
- wtetzner 7y agoBut you have to remember to use them in all the right places. Yes, they help, but it's not just about how good they are, it's about people actually using them too. If you're working on a team, you need to worry about whether or not everyone else is correctly using the annotations.
- pjmlp 7y agoIt also means that Kotlin doesn't get all Java goodies, like virtual threads, value types or GPGPU support.
- thu2111 7y agoVirtual threads (Loom) are also not anything affecting bytecode generation, so Kotlin will work with them out of the box. Really, I don't get this claim Kotlin will lack Java features. Most big Java upgrades these days are at the VM level. Kotlin gets those mostly for free, once they choose to upgrade to newer bytecode features (which they are slow at doing admittedly, but that's because they're in the middle of a compiler rewrite).
- pjmlp 7y agoNo it won't, because Kotlin also needs to target other platforms, and exposing JVM APIs or new bytecodes needs to have to have that into consideration. It also means that Kotlin on Android cannot just consume any random Java library, only those that are compatible with Android Java flavour of the month.
- thu2111 7y agoKotlin does expose JVM specific stuff though. Like the entire class library. You have to specifically opt in to the multiplatform subset to avoid that. It's not like they whitelist APIs. The only time they need to do anything to add new Java features is when the bytecode patterns change.
- pjmlp 7y agoYeah and then funny things happen when one tries to use libraries written in Java with Kotlin ones together. https://dev.to/martinhaeusler/why-i-stopped-using-coroutines-in-kotlin-kg0 https://dev.to/martinhaeusler/why-i-stopped-using-coroutines... https://dev.to/domnikl/kotlin-coroutines-and-javafx-threads-26od https://dev.to/domnikl/kotlin-coroutines-and-javafx-threads-... https://blog.danlew.net/2020/01/28/coroutines-and-java-synchronization-dont-mix/ https://blog.danlew.net/2020/01/28/coroutines-and-java-synch...
- yardstick 7y agoIf you are still targeting java8, isn’t that due to organisational constraints about software version management and wouldn’t that normally also imply issues around getting new tools like kotlin into the org too?
- vips7L 7y agoAgreed. I highly doubt someone that doesn't want to upgrade their Java version (outside of Android) will be willing to learn and introduce a whole new language.
- diehunde 7y agoAlso more experienced developers.
- BossingAround 7y agoThere's also the question of long-term sustainability. Groovy was very cool and popular in 2010. Ten years later, Groovy is still in the production codebase while the language is essentially dead. I personally wouldn't go for anything but Java (on JVM, that is) for anything that isn't a pet project.
- msclrhd 7y agoNote that with Kotlin, JetBrains created it initially for working on their IntelliJ IDE and are porting their Java codebase to use Kotlin. So that is a good indicator of long-term sustainability.
- moron4hire 7y agoYeah, it's not like it's a Google project. You can probably expect JetBrains to support Kotlin going long into the future.
- pjmlp 7y agoNowadays there are trying to just get Kotlin anywhere and it remains to be seen how Valhalla and Panama will be usable from Kotlin.
- thu2111 7y agoPanama would not seem to pose any problems as it's all code generation with MethodHandles/VarHandles. That should be directly callable from Kotlin. As for Valhalla, it remains to be seen how it's usable from Java, let alone anything else. But Kotlin already has a form of value type (inline classes) so perhaps it'll be an extension of that.
- pjmlp 7y agoKotlin inline classes are heap allocated, they are just syntax sugar for regular classes. One cannot just change their semantics after the fact.
- sinstein 7y agoOne of the reason to not consider Kotlin would be lack of resources. We run Kotlin services on Production at work and whole writing and reading Kotlin is so much better than Java, finding ways to do things still means having to fall back on Java examples. There are still resources available for Kotlin + Android development but non Android resources are very few. The plus side is because of the First Class Support in Intellij Idea for Kotlin, I can always take Java snippets and have the IDE convert them to Kotlin.
- gibolt 7y agoI would mostly disagree. You get all the Java solutions plus the Kotlin ones. Few languages have that much support. Within ~2 years, native things will hopefully become sufficient, but the state now isn't gloom and doom.
- sinstein 7y agoWe use a Dropwizard Application written in Kotlin and I have had a very hard time finding examples and tutorials and have had to translate from Java most of the time. Ofcourse I am banking on resources improving with time.
- davnicwil 7y agoOther than that, what's been your experience using kotlin with dropwizard? How would you compare it to Java?
- pjmlp 7y agoThat is exactly the biggest problem with guest languages, instead of being happy with what is already there, they duplicate the eco-system. So now for every problem we need to consider Java + Guest Language idiomatic libraries + alternative build tools + alternative IDE, across the whole corporation.
- damnyou 7y agoYeah well, it's hard to be happy with what's already there when that's fucking Java.
- awild 7y agoJava isn't the terrible language it used to be before Java8. Especially with Lombok it feels very lean and snappy. There are still some functional sheanigans missing but they're coming. Sometimes I wish it were less verbose, but I also think it's good to be very explicit about what you're doing.
- tracer4201 7y agoLombok? My first encounter with it was years ago with some annotation called sneaky throws. shudders
- awild 7y agoYou can very selectively disable features and behavior of Lombok. While I've never used the annotation in my current project I can see the use of it in cases where Java's forcing of exception annotation is in your way or forces unnecessary verbosity.
- sgt 7y agoDo you recommend using Lombok now for new Android projects written in Java?
- lmm 7y agoLombok is pretty much the same amount of trouble as using a different JVM language, IME. (Though by the same token I'd always pick Scala over Kotlin: if you're going to go to the effort of using another language, you might as well pick the one that offers the most power rather than using the equivalent of CoffeeScript)
- t-writescode 7y agoI would not make Kotlin my first language. It is absolutely a language that requires you already know the patterns and mannerisms of OO languages, like Java or C#. Once you do, its syntactic sugar and features are amaaaaazing. If you’re already familiar with OO languages and their standard coding patterns, then there’s little reason to use Java over it. To clarify, for the Kotlin / Java users out there that might not get what I mean: the syntax for classes and constructors and default constructors and all can be very confusing when reading Kotlin compared to C#, Java or Python, since the constructor and the class declaration are halfway merged.
- The_rationalist 7y agoActually you can code in kotlin exclusively with a functional style, especially with Arrow. since the constructor and the class declaration are halfway merged. this is an optional sugar (data classes)
- t-writescode 7y agoIndeed, but if you want any OO, it’s a liiiittle weird looking at first, since it’s so much syntactic sugar. Only a little, though. It was a stumbling block when I was learning it at first.
- lllr_finger 7y agoAs much as I like FP and Kotlin, we ended up removing Arrow and hand rolling the few things we really wanted, like a Result sum type. It's an impressive project, however adding FP to an intentionally multi-paradigm language can lead to rough ergonomics in some places.
- The_rationalist 7y agoInteresting, but did you check out arrow-meta? It should really improve expressiveness and ergonomics.
- 7y ago
- vbezhenar 7y agoI used to like Kotlin, but now I switched back to Java. The only thing that I miss in Java is short property syntax. And praised null-safety just gets in the way too much. Kotlin adds new layer of complexity to tooling, etc. I don't like some Kotlin idioms. Kotlin made a bet to features I don't need (Kotlin native; coroutines). Kotlin compiler is slow comparing to Java. That said, Kotlin is awesome language with awesome tooling. I don't think that it'll go anywhere since Google declared it as a preferred Android language. So you won't make a wrong choice, it's just a matter of personal preferences. I'm more of old guy who's not afraid of writing XML and repetitive code and don't like all that modern functional one-liners.
- fulafel 7y ago"Do I choose Kotlin over Java" is not the choice you face though - you can choose from a bunch of JVM languages. Clojure is pretty nice, for example.
- eloisant 7y agoClojure is very different from Java, so there are definitely cases you might prefer Java over Clojure. Scala also is a different beast (the one I prefer personally). I can understand people not choosing Scala if they're not into FP and are afraid to be unable to recruit Scala developers. But Kotlin being some sort of "improved Java", the philosophy stays the same, Java developers can seamlessly switch to Kotlin... The benefit of picking Java over Kotlin is pretty slim.
- fulafel 7y agoSure. But it's the same thing as in the JS platform, it's good to be aware that you don't just have a choice between JS and eg TypeScript, but a choice between all the JS platform languages that seem attractive.
- iLemming 7y ago> you might prefer Java over Clojure There are good, explainable reasons why people hate Java and Javascript. Fundamentally, one can argue that they are very nice and solid languages and all those complains aren't warranted. On the other hand if you look at them differently and treat them as low-level, sorta "assembly" languages for their respective platforms, then probably you would find out that Clojure is an amazing tool, because it can perfectly be hosted on both of them. And given all the good design decisions that went into Clojure, one might argue that it's almost always better to choose Clojure instead of Java.
- nullifidian 7y ago>is there really any compelling reason not to choose Kotlin over Java? Kotlin is being developed primarily by developers based in Russia. Putin relies on geopolitical conflict for consent manufacturing within the country. One of his future antics could turn into a real crisis, where Russia ends up sanctioned and isolated as a result, after a series of tit-for-tat moves, with the corresponding disruption to normal business processes. Being a Russian product it also carries a risk of one day receiving an update with a payload from Russian secret services, if they find your firm sufficiently interesting. But it's a general consideration with software/hardware from "adversary" countries like China or Russia. The story with Huawei is the same.
- pyuser583 7y agoWhat!? It’s being developed by JetBrains, which is headquartered in the Czech Republic - a NATO member!
- nullifidian 7y agoIt's registered/incorporated in the Czech Republic, but it's a Russian company. Same way Russian search giant Yandex is incorporated in Netherlands.
- isbvhodnvemrwvn 7y agoKotlin is named after an island protecting the entry to St. Petersburg. While they have some developers in Germany and Czech Republic (plus some remote IIRC), their main development center is in St. Petersburg. I guess they were incorporated in Czech republic due to political issues, but they would still be crippled if they were somehow cut off from their St. Petersburg office.
- tomerbd 7y agoMany companies started using Scala a ~5 years ago, it was better, there was no reason not to, until the developers found that better is not as good as do the basic stuff that works and holds to the future have proven past, and have many more developers and more people in community this is what rules the game.
- CuriouslyC 7y agoI don't think Scala is a good comparison. Due to the fact that it has a large surface area and there is a lot of magic in places, it's harder to learn than Kotlin. Also, Scala suffers from C++ syndrome, where a team of developers that all nominally know the same language can actually know somewhat incompatible subsets of it. I think the Typescript/Javascript comparison is more apt, and at this point I'm pretty sure that Typescript will win.
- gbersac 7y agoAs a scala fan, I think comparing Java and Scala is a bad idea. Scala is functionnal programming on the JVM and Java is OO. Kotlin and Java, on the other hand are both OO programming language and should have a smooth transition.
- vips7L 7y agoModern Java is actually quite good. The main three things that Kotlin offers, in my eyes, are Data classes (in preview in JDK 14), Coroutines (should be coming soonish with loom), and nullable reference types (not big enough for me to switch). Outside of Android I wouldn't choose Kotlin.
- watt 7y agoNull safety is the one big win for Kotlin. https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html
- vips7L 7y agoI agree, but like I said it's not enough for me to switch. I use Optional<T> whenever I need to return null. The only outlier there is the JDK which most devs should know when it's returning null to you.
- dajohnson89 7y agoisn’t optional just replacing the null check with if(optionalRef.isPresent)?? i kinda get how this is safer, but clients can just call optionalRef.get() without checking, and boom there goes the safety. compiler warnings be damned.
- vips7L 7y agoOptional is just signaling to the user that they should check. You could also do this in Kotlin and boom there goes the safety: fn nonNull(): String { val s: String? = null return !!s }
- lllr_finger 7y agoI would tout sealed classes as well, although I think Java has a proposal that's getting traction. For back-end service/API type things in an enterprise setting, Kotlin is a good value proposition. There's also probably some truth to the idea that one reason modern Java is adding these things is because of Kotlin's existence.
- pts_ 7y agoLast I checked the IDE costs money for web dev.
- tommyage 7y agoAbout one and a half year ago we also decided to give kotlin a shot. After a few months my opinion was similiar to yours. Extension-functions, yeah! Anyway, nowadays you wouldn't see me making the same statements anymore. My first issue appeared when I was maintaining an Android app written in Java. I needed an library for some functionality. The only maintained ones were kotlin-libs. But interoperability, right? I didn't hesitated to include it. There is no way to use or extend functionality with typealiases in your java code. IntelliJ can compile Kotlin into Java and it is easily accessible. But there is no adb debugger for kotlin. Null Safety is just overhead imho. I know when it is appropriate or neccessary to check for null, otherwise i can get rid of it. And its more easily grep-pable the Java way. Writing Kotlin is not so fluent as one would guess, the tooling only fools you, that it is. You can easily make use of actions like typing pfi (extends to public final int) for java aswell. But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything. Additionally, i do not like the implicit type on member property declarations used by almost anybody. The benefit of typing less boilerplate becomes annoying when reading sources outside your ide. Boilerplate in my opinion is code i need to write by myself. When it is generated by any IDE, i do not bother about it. We are so familiar with Java that we can abstract this boilerplate when reading sources. Spelling Kotlin to somebody via telephone is also strange for me. I stopped promoting Kotlin as a Java killer. Code style is too different between different developers. And why are we creating the same libraries once again?
- tommyage 7y agosorry, first comment and i referenced somehow the wrong content.
- choward 7y ago> Null Safety is just overhead imho. Not having null safety seems like overhead to me. > I know when it is appropriate or neccessary to check for null, otherwise i can get rid of it. How do you know? Do you have the entire code base in your head. What about when someone new works on the project? > And its more easily grep-pable the Java way. What does this mean?
- jillesvangurp 7y agoEverything Java does (including considering recent updates), Kotlin does better. So no. I made the switch to Kotlin two years ago and I'm not looking back. It doesn't matter what frameworks you use, Kotlin is a drop in replacement for Java. Though obviously, if you are doing greenfield use something that makes the most of the language. There's this misconception that Kotlin is an Android only thing or a JVM only thing. The reality in both Android and server side frameworks is that the big frameworks are all moving towards being Kotlin friendly/ready. Additionally, Kotlin is rapidly moving towards being a proper full stack language with a native compiler (currently in beta), a javascript transpiler, and lots of other tooling maturing. People are already doing cross IOS/Android libraries in Kotlin. A big advantage of Kotlin over e.g. Scala and other JVM languages that are not Java is that it is designed from the ground up make the transition as seamless as possible. Scala is so far removed from Java that it's generally a completely separate ecosystem with its own libraries, tools, frameworks, idioms, etc. Yes you can use Java stuff but it's generally frowned upon by Scala people. This is not the case with Kotlin at all. The Android ecosystem started transitioning to Kotlin long before Google recommended that and before Kotlin 1.0 because the pain of having to deal with Java 6/7 just made that development so much better. A few years ago they started endorsing and recommending it and at this point they are clearly deprecating a lot of stuff that they did for Java that can be done better with Kotlin e.g. embracing co-routines over rxjava, adding extension functions and kotlin dsls and designing new features that really only make sense if you use Kotlin. On Android, if you are doing Java, you are working on a legacy code base. On the server side the same is happening with e.g, Spring, which is basically the dominant server side framework for the JVM. I used Kotlin with Spring Boot 1.x/Spring 4.x, and it was a nice upgrade despite the lack of Kotlin support for it. With Spring 5 and Spring Boot 2.x they started adding a lot of Kotlin extension functions, co-routine support (which generally makes using their reactive stuff less painful), and there's an experimental project for Kotlin DSL (https://github.com/spring-projects-experimental/spring-fu https://github.com/spring-projects-experimental/spring-fu) to replace the mess of annotations that is currently needed and which reduces the need for reflection, proxies, and other tricks that currently make using Spring with Graal vm hard. Basically, what that means is that if you use Spring in a new project and you are not using Kotlin, you are probably making a mistake because you are missing out on a lot of good stuff. They'll likely not deprecate Java entirely for a long time just because there are a lot of very conservative projects in e.g. banks using Java but if you read between the lines they are basically saying Kotlin is it going forward. IMHO, the Java language is definitely improving but just not at a pace where it actually keeps up and a lot of the stuff they add is a big compromise compared to what you get in Kotlin. and of course Kotlin is improving as well and a lot of the Java changes (and related JVM changes) also benefit Kotlin.
- cryptos 7y agoJava gets better with every release and is a pretty decent language today. But Kotlin feels just more consistent with less corner cases. Let me name a few things: * No checked exceptions destroying lambda expressions and leading to architecture problems (since exceptions are oft not used like the inventors of checked exceptions assumed). * Functions are real first class citizens and don't need artificial interfaces. * Named parameters with default arguments are very practical. * `name: Type` is a better fit for type inference than `Type name`. * Null-safety helps to avoid lots of bugs. * The type system with `Any` as a unified root and `Unit` instead of the special case `void` makes programming with generics much easier. * Constructors are always lean, not only for data classes (record in Java 14). * Most things are expressions, so you can write `val a = if(cond) 1 else 99`. * Extension functions and operator functions can be used to write simple to use and elegant APIs. So at least for me Kotlin is definitive the better Java and I wouldn't start a new project with Java, if I could use Kotlin instead.
- Stratoscope 7y agoMobile-readable version of your list: * No checked exceptions destroying lambda expressions and leading to architecture problems (since exceptions are oft not used like the inventors of checked exceptions assumed). * Functions are real first class citizens and don't need artificial interfaces. * Named parameters with default arguments are very practical. * `name: Type` is a better fit for type inference than `Type name`. * Null-safety helps to avoid lots of bugs. * The type system with `Any` as a unified root and `Unit` instead of the special case `void` makes programming with generics much easier. * Constructors are always lean, not only for data classes (record in Java 14). * Most things are expressions, so you can write `val a = if(cond) 1 else 99`. * Extension functions and operator functions can be used to write simple to use and elegant APIs.
- gmiller123456 7y ago>is there really any compelling reason not to choose Kotlin over Java? IMHO, any language features rank incredibly low on the list of reasons you might use a language. Things like how long has the language been popular, how long will the language be popular? How strong is the community around the language, how long will it stay strong? What else can you use the language for? What tools are available, is the tooling in a competitive market? Which of those things is most important to your application? A lot of those questions can't be answered directly, and have to be guessed at. But in the Kotlin vs Java scenario, the choice is pretty obvious for most applications.