15 ms·

Can I get some reasons to use Java instead of Kotlin?

152 points by azth 5y ago

pjmlp 5y ago
Basically either use the platform, or be faced with the dilemma of eternal catch-up, features duplication and opposing roadmap goals.
- OJFord 5y ago
  What does that mean here? I'm not an Android dev but I cobbled together a couple of tiny PRs for something recently, and Google's Android docs cover both, with toggles to flip between Java & Kotlin example code.
  - pjmlp 5y ago
    Android Java doesn't count, it is a Java 8 subset, with cherry picked features from OpenJDK, stagnated on purpose as means to sell and market Kotlin on Android. The article is talking about proper Java.
    - curt15 5y ago
      If Google wants to let Java developers use their existing skills on Android, what is the point of promoting Kotlin on Android?
      - pjmlp 5y ago
        They don't, otherwise Android Java wouldn't be on its current state, a stagnated implementation, that fairs quite poorly against Kotlin when comparing language features.
    - OJFord 5y ago
      Oh, then I misinterpreted your comment. (To something like 'if you don't use Java like Android expects you to then expect pain and suffering'.) I just assumed it was about Android because I've never heard about Kotlin being used besides Android. But then I suppose I don't hear about (because I don't work with) Java much either.
namelessoracle 5y ago
The reason i've heard voiced by managerial types is that it lets you have access to alot more off shore resources or contracted resources. TCS/Accenture/Infosys has a firehose of Java devs to throw at a project. Not so much Kotlin. This is of course ignoring quality issues....
- hellow0rldz 5y ago
  Even assuming more Kotlin devs are coding gods (BIG if), the sheer number difference means you have where to pick good Java devs from. Plus... if Kotlin really is the new hotness and companies want it then mediocre devs can also learn it. So any "genius early adopter" advantage that Kotlin might have is short lived.
  - namelessoracle 5y ago
    This isn't a "kotlin coding god" argument. Tata Consultantcy Services (to use an example) has thousands if not tens of thousands of Java "devs". Quality isn't great, but Java has been around long enough that at this point, at least some of who they send to your project actually do have the java experience they claim. Though speaking from personal experience, the dude/lady with 5 years of java 7 and below experiences gets stuck in their ways and doesnt write more modern Java code. I had one dude who got mad and would try to block PRs if you did lambda functions from those bodyshops. My experience dealing with body shops. If you ask for Kotlin, the body shops will send you devs that have Kotlin on their resume, and if your lucky the body shop had them do a 10 hour online course on it. If your corporate model uses body shops you are probably gonna get better results from them with a more mature language than something newer.
- blacktriangle 5y ago
  I can second both the availability and quality issues. Tried to get a Kotlin dev for Android via Toptal and settled for Java when they said they basically had 0 Kotlin experience on staff. As for quality, the app worked and works well, but there were some serious WTF design decisions made that have made it impossible to maintain the app, not to mention total lack of testing.
ta988 5y ago
I've been considering Scala recently to move from Kotlin that seems to slow down in its evolution and future perspectives. But two points are still pain points for me 1) toxic community members 2) there is a NIH syndrome where there is pressure to rewrite everything in Scala when a Java lib exists (and I still don't know if it is because using Java libs is hard or just because of something else).
- anorwell 5y ago
  Using java libraries from scala is very easy. In my experience, there are two reasons why java libraries are either re-written, or more often, wrapped with a wrapper library: - To make library usage more idiomatic in Scala. This usually means replacing nulls with Options, exceptions with Try, and mutable or java collection data structures with immutable or scala collection data structures. - To provide idiomatic concurrency interfaces, such converting a synchronous libraries or internal threadpools to scala.util.concurrent.Future (or scalaz.concurrent.Task)
  - ta988 5y ago
    Thanks. That makes it more attractive seen like that.
Shadonototro 5y ago
faster perf faster compile time
cs-szazz 5y ago
As soon as I opened the page, I searched for "null" and saw it didn't show up in the original post. Leaving that out is almost a bad faith argument, because it is the number 1 Kotlin feature I doubt Java will ever get. Now, I will say that build times are way better on Java. A large part of this is the ability to generate ABI jars with Gradle, which you can't do with Kotlin. If anyone from Gradle or Jetbrains are reading this, please please please try and make this work, I know there's ongoing tickets but in larger projects Kotlin and Java are not even close, for this specific reason.
- usrusr 5y ago
  It's funny actually: my java code had mostly made peace with null. A combination of tireless performance of that if-dance where necessary, generous use of static methods for certain routine tasks on nullables and most importantly, @NonNull and null object singletons creeping into more and more code. Now in kotlin it feels like it's just "drown it in question marks". I certainly end up with lots of nonnull signatures and far more reliable null handling than in java, but the ease almost feels wrong.
  - wombat-man 5y ago
    I am using more and more kotlin these days as an Android app dev it starts that way, but over time you don't need the question marks as much because you're dealing with more and more code where the variables are guaranteed to not be null.
    - usrusr 5y ago
      Where my code is mostly interacting with itself I see question marks almost as rarely as I saw Optional during my scala adventures (still can't believe a decade went by!), but the android API provokes it's share of nullability and the kotlin approach to deal with it is just so "why didn't we have that back in the MIDlet days!" Some coworkers seem to type questionmarks faster than that IntelliJ "convert to kotlin" button and I hate it, but much less than I'd expect.
  - 5y ago
christkv 5y ago
Does it have to be an either or? Our project is mixed allowing us to leverage newer java things where appropriate but still getting the more concise code of kotlin for the majority of our project.
- ludamad 5y ago
  Sure, you can write Java libraries for a Kotlin project, but I'd argue that for the majority of the code you did make a firm choice
  - christkv 5y ago
    There are still things I think is harder to tap into using kotlin directly, such as record types or upcoming simd stuff (I might be wrong here).
afavour 5y ago
Some interesting points in there. My personal summary as someone who's done plenty of JS and Android work: Kotlin is to Java as CoffeeScript is to JavaScript. I loved using CoffeeScript at the time because JavaScript felt like an incredibly stagnant language. CoffeeScript brought so many usability improvements. But that in turn inspired ES6 JavaScript and now no-one uses CoffeeScript. I wouldn't be surprised if we see something similar with Kotlin. But it has an invested and motivated corporate backer that CoffeeScript never had who are branching out in new directions like Kotlin Native, so I wouldn't count it out yet. Native offers some interesting possible futures for cross-platform development (for instance you can deploy to both Android and iOS, WASM soon I believe?). That alone might justify keeping it around.
- cs-szazz 5y ago
  (not a frontend dev, so excuse any ignorance) I agree CoffeeScript usage has gone down dramatically, but has Typescript not usurped it? It doesn't seem like everyone just went back to using JS, so maybe Scala was CoffeeScript, and Kotlin is closer to Typescript?
  - afavour 5y ago
    I don't want to stretch metaphors too far here but there's some truth in what you're saying. TypeScript usage is a tiny minority of JavaScript usage but it's climbing and I'm sure it's much higher than CoffeeScript ever was. But I see TypeScript as a different beast altogether because of its aims. CoffeeScript and Kotlin were both created to make a complicated messy language more straightforward and powerful. TypeScript aims to make JavaScript safer by introducing types. If anything it slows development down, not makes it faster (and before someone jumps on me for saying that: yes, I think it's worth the price). IMO that makes comparisons difficult.
    - cs-szazz 5y ago
      That's fair, though I will say Kotlin's type system having nullability built-in is something I doubt Java will ever fully add (instead of the annotations it currently uses). So in that respect, it's making it more type safe, but the delta between Kt and Java isn't near as big as TS and JS.
brotherofsteel 5y ago
In my experience, the automated refactorings in IntelliJ work better for Java than for Kotlin.
- MrBuddyCasino 5y ago
  The Kotlin ones are sometimes so buggy it defies belief, especially considering Kotlin is a JetBrains invention. The Java tooling & speed are leagues above Kotlin.
jggonz 5y ago
If you're like me and have spent several years working with Java projects, moving to Kotlin will slow you down at first. You also may not know all the cool new features available in Kotlin from day 1, so you may find yourself doing "java" things in Kotlin, or not knowing how to do some things in Kotlin at all. If you're on a tight deadline for something, you might want to just stick with Java (if you know it) until you can dedicate enough time to learn Kotlin well. If you're new to both Java or Kotlin, then learn both. :)
deccanchargers 5y ago
As a person who is just starting to learn Kotlin for Android Development, Can you please tell me which language is better to pursue for android development? I also recently read this https://billthefarmer.github.io/blog/android-kotlin/ https://billthefarmer.github.io/blog/android-kotlin/ adding to dilemma of choice.
- kmonsen 5y ago
  Kotlin
- thecupisblue 5y ago
  As someone who's been in that field for the last, uhhh, 8 or 9 years, I'd say feel free to go with Kotlin. You will understand java the moment you see it later on, meanwhile Kotlin is easier to write, understand and think it. It will get you where you want to be faster than Java. All modern examples will be written mostly in Kotlin, so you won't have trouble adjusting. But in the end, just pick one and go with it, being paralysed by analysis won't help you at all, and after you're fluent in one the other will be familiar too.
- nindalf 5y ago
  I have nothing to say about the rest of the article, but here's one bit that doesn't make the point the author hopes for. > The obvious difference with the app is that the Java version size is 74Kb, the Kotlin version is 781Kb. Rather a lot of bloat for a small simple app. No, it really isn't. Anything less than one MB is negligible. Importantly, since we have exactly one sample for each we don't know if that's fixed overhead or variable. Does a 5MB Java app become a 5.7MB Kotlin app? Then the overhead is fully fixed and it doesn't matter. Does a 5Mb Java app become a 50MB Kotlin app? That's a problem. The truth is probably somewhere in between. We don't know because the author made the unfounded statement about bloat with just one data point.
- pjmlp 5y ago
  I would like to say Java, but given the way Google stagnates Android Java on purpose, and pushes Kotlin no matter what, Kotlin is the way to go for serious app development. Then if you want to do anything related to 3D, realtime audio or machine learning, you also need either C or C++, as those APIs are NDK only (OpenGL is actually also available to Java, but Vulkan is the official 3D API since Android 10). Now if you want to target Android only as hobby, use whatever you feel like.
ashishb 5y ago
Checked Exceptions. I wish Kotlin had it too.
- kubb 5y ago
  They don't have it by design. The Java community has collectively decided it's a bad idea and they're discouraged even in Java.
  - inshadows 5y ago
    No it didn't. And they're not discouraged in Java SE. Ignoring errors and letting them propagate to thread's main is just stupid. I haven't heard single argument except "Meh, I have to write throws Exception to every method". It's either "throws Exception" or something like "Either<Exception, String>". Same principle, you declare errors in type system. And if you have reason to believe that it's a good thing to hide errors from type system, then please, convince me.
- blacktriangle 5y ago
  Checked exceptions sound good in theory but to make it works it requires the whole community to buy into that level of paranoia right from the beginning. It's a much better concept for a language like Ada or Eiffel more design-by-contract style. Java already plays fast and lose with safety, checked exceptions are closing the barn door after the horses bolted. In reality checked exceptions in Java just means everybody swallows exceptions by doing nothing and moves on.
  - ashishb 5y ago
    > It's a much better concept for a language like Ada or Eiffel more design-by-contract style. I'm not familiar with this. Please elaborate how you would handle say an I/O failure while R/w a file with this approach?
    - blacktriangle 5y ago
      I'm not familiar enough with either of those platforms to answer that specific question, it was more a general comment on the respective developer cultures. I've worked on several Java codebases where swallowing exceptions was the norm, but in their defense it was because several libraries were way too chatty in their use of exceptions.
RocketSyntax 5y ago
Surrounding enterprise-grade toolset built up over decades. Android. Desktop apps. Hiring and outsourcing. Millions of Java devs.
bitcharmer 5y ago
Performance. There's a very good reason why low-latency and high performance computing crowd don't use inventions like Scala or Kotlin but they do use Java. Yes, they all run on the same JVM but most of the nice features and syntactic sugar comes at a price of generating huge amounts of garbage. It's possible to achieve zero- or low-allocating code with almost fully idiomatic Java but not so much with the alternatives.
- weego 5y ago
  Those people are a frankly unimportant niche in the JVM world. Even in areas where its relevant (banking etc) 99%+ of the codebase is not coded for those tolerances.
  - bitcharmer 5y ago
    Not sure what gave you that idea; it seems you have never been part of that crowd so just throwing unsubstantiated claims around. Performance has always been one of the major drivers in the JVM development. Just read the JEPs and see for yourself.
- jcadam 5y ago
  I'd argue that Java is a poor choice for this use case as well.
  - Pet_Ant 5y ago
    There is a GC specifically for this use case: https://openjdk.java.net/jeps/318 https://openjdk.java.net/jeps/318
    - lolinder 5y ago
      An experimental one. There are still many far better choices for low-latency programming.
      - pjmlp 5y ago
lmilcin 5y ago
There is a lot of reasons to prefer Java (Disclamer: I don't use Kotlin all that much). First, there is really not that much reason to use Kotlin for the type of applications that would normally be written in Java. When I look at Kotlin code in my org most of it looks like Java with some very slight, cosmetic differences. The reality is overwhelming majority of people writing Kotlin is Java developers and overwhelming majority of those continues what they were doing in Java but now in Kotlin. It is more difficult to find people with experience to work on Kotlin. Kotlin is slower than Java, but for most applications it shouldn't really matter (in that if you make it your focus you are probably wasting time while you could be doing something more worthwhile). To develop in Kotlin well, you should also know Java. So now you really need to know two languages. Let's face it, people who go to work with Java projects are not exactly cream of the crop (and I am saying this after working with Java for the past 20 years). Java has some excellent frameworks (ie. Spring), documentation and guidance (ie. stack*) on how to structure your application that makes it much easier for a junior developer to start writing new service and for everybody to understand existing code (because it all looks alike). As a tech lead this lets me focus on other stuff rather than telling developers how to write a controller, how to read configuration file, how to structure your database layer, etc. And bunch other reasons...
- qsort 5y ago
  I agree with the gist of your comment, but this: > Let's face it, people who go to work with Java projects are not exactly cream of the crop is a bit of a weird take. If you're saying that most people working in software engineering aren't "exactly cream of the crop" to begin with, then you probably have a point (I'm a java dev as well, by the way), but I don't see how the programming language changes the equation.
  - tga 5y ago
    http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html True in 2004, probably still true to some extent in 2021.
    - deleted 5y ago
usrusr 5y ago
Not something big enough to overrule other arguments, but the old fashion imperative java as in "mutate stuff in your local scope as if there's no tomorrow" is much nicer to consume in a debugger than the declarative "describe what you want and let the compiler figure out that it fits together or not once and for all" style that kotlin pushes even more than modern java. You certainly don't need the debugger as much for trivial mishaps that are simply not possible in the new style, but if something isn't working at all it's much harder to get your bearings with a quick step-through than in imperative. Of course it's just as possible to go all-imperative in kotlin as it is in java (even scala would allow it), but it's just painful to see an elaborate step by step block full of possible bug hiding places where a simple val...filter...map... expression could provide a clear description of the result. That being said, my mind still hasn't adjusted at all to thinking about names before thinking about types, guess that's very much to expect after a decade of naming 95% of variables "class name, but lowercase". (PS: I actually maintain the fantasy that there might be room for a language that abandoned the entire idea of local variable names and just referred to e.g. parameters as "the {type} parameter", pushing typical cases of more than one instance of a certain type sharing a scope into the type system)
Juntu 5y ago
Script(;:)
flerchin 5y ago
My problem with kotlin is not that it's not better, or not fun. It's that we have millions of lines of java code across hundreds of projects that will not be ported. Having to context switch in between maintaining projects is another stone on top of tech-debt mountain.
nobleach 5y ago
I have microservices in production using both. Kotlin the language, I absolutely love. I'd put it in my top 5 languages. I don't hate Java but I've never really enjoyed writing it. Even with all the cool new features, it's always felt bloated to me. I can't see that ever going away. With that said, I really hate how tight of a hold JetBrains has on Kotlin. While you may find an outlier here or there, (someone using Eclipse/NetBeans - heck, I've even used Visual Studio Code and Vim to hack on some stuff) 99% of the people writing Kotlin are using IntelliJ. Kotlin is built to sell IntelliJ. (And the lock-in is pretty apparent) I don't begrudge a company the right to do this. I don't like it, but I have a choice whether or not to use the language. Lastly, Kotlin feels unencumbered. One can program in a functional style like Scala. One can program in an OO style like Java. It feels "free". The sugar that it adds to Java makes my day to day a pleasure. So consider me a fan of the language itself. I highly recommend building things with it. Am I optimistic about its future? That's really hard to say. Google's behind it at the moment, but Google's attention span rivals that of a fruit fly.
- blacktriangle 5y ago
  The Google question really can't be ignored, to the point where "Should I use Java or Kotlin on Android?" and "Should I use Java or Kotlin for <any other use of the JVM>?" are two totally different questions.
  - nobleach 5y ago
    I agree. Using Kotlin with Spring Boot and Micronaut are no-brainers for me. The Kotlin support for both projects is fantastic. I do feel that if Google pulled the plug and started putting their emphasis on DartVM for Android projects (or something like that), we'd see a reduction in Kotlin adoption in other areas though.
    - throwaway3699 5y ago
      FWIW, Dart and Kotlin are being pushed by two completely different parts of Google. It's safe to say that Kotlin is the future on Android.
kubb 5y ago
As far as I can tell, the central point is that Kotlin and Java will drift away in the future as Java gets more features. One example is given (instanceof). OTOH, Kotlin is growing extremely fast. It was already top 8 in the global developer population report in Q4 2018. Will it gain enough critical weight that it will become one of the standard JVM languages and influence how features are added to Java? https://slashdata-website-cms.s3.amazonaws.com/sample_reports/EiWEyM5bfZe1Kug_.pdf https://slashdata-website-cms.s3.amazonaws.com/sample_report...
wildmanx 5y ago
The name.
gautamdivgi 5y ago
One important consideration is if you need to scale up your team it is much easier to do it with Java than with Kotlin. I know the code/implementation aspect exists but scaling a development team quickly has a much greater chance of success with a "boring" platform.
strulovich 5y ago
I’m working on converting a huge codebase from Java to Kotlin. I like Kotlin and would recommend it, but to answer the question: - slower complication time - more complicated language: this means code that’s harder to optimize, or that can be overly complex when written by junior developers or language aficionados. (This doesn’t have to happen, but it does in my experience) - lack of libraries means you will use Java code, and Java and Kotlin code mixing is really well done, but will still expose you to many quirks. This will mean developers will need to know Java on top of Kotlin. - less stable: things are changing faster in Kotlin, and you’re more likely to see breaking changes if you have a big codebase when the next version comes out. - performance: in the same way C++ can be as fast as C code - Kotlin can be as safe as Java. In practice though, you will use more abstractions and you may want critical components to remain in Java. From my experience though, runtime performance is not an issue in practice for all examples I’ve seen tested.
Ancapistani 5y ago
I worked in Kotlin for a few months, having very little experience Java to begin with. I have/had deep experience in several other languages, though - Python, Ruby, Clojure, etc. Kotlin was nicer to work in that Java, but 99% of the concepts seemed to transfer neatly between the two. Server-side web app development was somewhat limited by the lack of a mature ORM. Exposed and ktorm were the big ones; Exposed explicitly didn't support many PostgreSQL features and had no plans to do some, while ktorm is a small project seemingly maintained primarily by a single developer.
- vbsteven 5y ago
  > Server-side web app development was somewhat limited by the lack of a mature ORM. I assume you mean a mature ORM written in pure Kotlin with this statement. Because Kotlin interopts so well with Java, you can use any of the battle tested web frameworks like Spring (Boot) with ORM's like Hibernate. Most of these frameworks/libraries even have additional kotlin extensions to enhance the experience. Kotlin + Spring + Postgres is my default stack to do a web/api project in 2021. Super productive environment with good configuration/cloud/di/orm support and a huge ecosystem of available libraries.
vanviegen 5y ago
One reason not to use Kotlin: its syntactic sugar makes it harder to read for someone who doesn't know the language. Most Java syntax and semantics are pretty much self explanatory for anyone who has worked with any object oriented language before. (Java programs are often rather difficult to understand though, but that's due to overengineering, not the language itself.)
barrkel 5y ago
The single biggest reason is to avoid getting stuck with a codebase written in an evolutionary dead end. Java and Kotlin will gradually diverge, particularly as Java gains features which are similar to Kotlin features but implements them slightly differently. Third party library APIs will start use the new constructs and you'll be stuck with two slightly different ways of doing something very similar in your codebase. Over the course of 10 or 20 years, that will probably happen again and again. Java evolution used to be pretty conservative but it's picked up pace and its closest non-JVM competitor C# is miles ahead in expressiveness. For example, CoffeeScript seemed like it made sense 10 years ago. JavaScript was full of defects and CoffeeScript fixed a lot of them, at the cost of a slightly different syntax, though not so different that you couldn't debug the resulting JS. But you wouldn't want to be stuck with a CoffeeScript codebase today.
- rrevo 5y ago
  Completely agree on aspect of kotlin being an evolutionary dead end. For anyone interested in looking at C#, look at https://rahulrevo.substack.com/p/language-ecosystems-net https://rahulrevo.substack.com/p/language-ecosystems-net and how they have evolved differently.
gutta-percha 5y ago
Incidentally, the author of the linked post is one of the lead maintainers of Lombok, a widely-used Java enhancement library. So he knows of which he speaks. https://projectlombok.org/features/all https://projectlombok.org/features/all https://github.com/rzwitserloot https://github.com/rzwitserloot
twic 5y ago
> Java is trying to figure out smart ways to access CPU-native 80-bit registers What? Java has made use of extended precision floating point on x86 (well, x87) since 1.2. There is actually a proposal to stop doing this now that the x87 instructions are no longer the best way to do floating-point arithmetic [1]. Or is this about something else? EDIT: Why am i asking here? I asked on the Reddit thread. [1] http://openjdk.java.net/jeps/306 http://openjdk.java.net/jeps/306
- cpleppert 5y ago
  Glad I wasn't the only one to notice that. No one idea what he could possibly mean but given that Java hasn't used x87 in forever and there is no reason to ever want to use them I guess he is just completely wrong here?
  - twic 5y ago
    Based on the response on Reddit, yes, i think they are just confused.
AncoraImparo 5y ago
Yeah, Java works. You have to sneak up on Kotlin to make it do anything. Also, when you have questions, the java community is a lot better. The Kotlin community is made up of the same tweed jacket wearing losers that were doing rails back in the day.
- NoahTheDuke 5y ago
  Do you have anything of substance to add or is this just an opportunity to insult communities you don’t like?
MrBuddyCasino 5y ago
More args in favour of Java: - coroutines in Kotlin are a crappy solution compared to the future Java one, which is to keep using the Thread API and switch to an async model underneath, without the developer having to care about it at all - multi-line Strings aren't fucked like in Kotlin (leading-whitespace behaviour) - superior tooling: IntelliJ works much faster, refactorings are more reliable in Java - build times are much better
vbsteven 5y ago
The HN crowd is not very fond of the magic in popular Java frameworks but to me that magic is what makes those frameworks so good, although with a bit of a learning curve at first. Kotlin/Java with a framework like Spring is the sweet spot for web/api development. Fast enough for most use cases, great tooling, huge ecosystem, just the right level of abstraction, easy to deploy, easy to debug, very expressive code using annotations. An API backed by an ORM can be written in 10 minutes with less than 50 lines of Kotlin. The cons are mostly compile time and startup time. Startup time isn't very relevant for backend services. Compile times aren't great but not horrible either. The pain point with Java as mentioned in other comments in this thread is the presence of null, which among some other things make it a little verbose. That's where Kotlin comes in. Usually my projects will use framework libraries in Java and my own code is all Kotlin. The nulls go away once code exits from Java land into Kotlin land.
- mhoad 5y ago
  I'd be totally OK with the magic in something like Spring or Ruby on Rails is another good example if it had code I could inspect when things go wrong. That is really my one and only complaint that I have about "magic". I currently find myself playing around now a lot with Dart which has a lot of the same convenience and just handles it via code generation rather than dynamic magic at runtime. For me at least, it's a really nice trade off. It also for the record has fully sound null safety which is something I have only ever seen in Swift previously but is a real pleasure to work with. I guess in the Java world you have options like Quarkus that also give you a similar kind of experience.
- InvOfSmallC 5y ago
  I cannot agree more. Also maturity of the ecosystem which whichever you don't find in go for example.
- lazaroclapp 5y ago
  While admittedly not as nice as having it built into the type system from day one, there are a number of tools one can integrate into their build to add various degrees of null safety to Java. Disclaimer: I am one of the maintainers of one such tool, namely https://github.com/uber/NullAway https://github.com/uber/NullAway It certainly won't help with verbosity (in fact, it does the opposite to at least a small degree :)), but it can dramatically reduce the number of actual NPEs when running your Java code. Obviously I am not saying this is a reason to not use Kotlin. But, when, e.g. based on the things mentioned elsewhere in this comment section, you are deciding to stick with Java for a particular codebase, it doesn't mean static null checking is not an orthogonal option to consider.
trulyrandom 5y ago
I think Kotlin is great. I feel much more fluent when writing Kotlin than I do when writing Java. The thing I really miss though, is checked exceptions. I have no clue which exception types a library function might be throwing unless they're explicitly documented (which is rare). Does anyone know if this is planned to be addressed at some point?
- alanfranz 5y ago
  Add exception to the signature, I suppose. At leasy in Java, you can add unchecked exceptions to function signatures. Checked exceptions are an old idea. Good to see them go away. Just use a “context manager” by passing a callable somewhere.
astral303 5y ago
Kotlin’s closed/final by default is a huge flaw when working with a large codebase. Code is not left extensible by default. I don’t want to sprinkle my code with the open noise. False performance optimization, big maintenance/flexibility expense.
- anoncake 5y ago
  That is not a performance optimization.
- garethrowlands 5y ago
  It's not a performance optimisation, it's to avoid codebases accidentally becoming a big ball of mud. Prefer composition over inheritance. Definitely do not inherit accidentally or from a class that wasn't designed for inheritance. The JVM can already optimise classes with no subclasses because it knows all the classes that are currently loaded, so it doesn't need language support.
rrevo 5y ago
Context matters. I think kotlin definitely works for android developers but other cases need more thinking. If you're building webapps in smallish teams then maybe those work too. Some reasons against Kotlin are- * If you are working in a mid to large team then having all developers learn a new language is a massive cost. Learning Java is also still a requirement if you're developing in Kotlin since many open source libraries are in Java. So teams need to be aware of 2 similar but different tech stacks. * If you are developing platform libraries then you would look at higher adoption by using Java 11 LTS as the baseline. You could add an optional kotlin library for a better experience. * Others have pointed out how Kotlin will be an evolutionary dead end as Java catches up on features.
jollybean 5y ago
I think the question should be why Kotlin instead of Java because it provides part of the answer. When I switched to Kotlin, I liked some nice things, but found that in the big picture, it wasn't a huge advantage, and many of the language artifacts I didn't like. Most importantly: Kotlin doesn't produce more succinct code. The code is not really that much shorter. If you go to Android and look at all the Java/Kotlin examples, they are almost always similar in terms of length and complexity. Once you find yourself dealing in an entirely Java world, with Java idioms, libraries, builds, jars and reading java source ... the bit of 'impedance mismatch' to your own Kotlin code then becomes a pain. Kotlin is no way better than having to work in 'two languages at once' with the constant switching. And of course a whole bunch of extra tools as well. Also, Kotlin is more of a 'bunch of features' than a cleanly designed language. So in the end if you are using K for a very specific reason (maybe js compile target), or if you can do the whole project cleanly in K (maybe Android) etc. then maybe K is the choice. But I've switched back to Java and accepted slightly more verbose typing and never missed it. The IDE's do a lot of that work anyhow. Even more qualitative ... I find Java easier to read and maintain for some reason. I would almost prefer a few small changes to Java than I would a new language.
newobj 5y ago
Code size, which can matter on mobile, if your app gets big enough. Build times. kotlinc still has codegen bugs. Been a while since I saw one in javac.
SergeAx 5y ago
I beleive that Kotlin was built not to sell IntelliJ, but to build IntelliJ. JetBrains has that line of about 20 IDEs all written in Java sharing an awful lots of common code. I think that together it is among largest Java codebases still in super-active development. So, you have to code on Java 40 hrs per week year by year. All those `Foo foo = new Foo();`, every day. And you think: "If only there was a language like Java, but better, and it was interoped with Java, so you can gradually introduce it into Java codebase!".
- distribot 5y ago
  I can only speak for myself, but I've never found the `Foo foo = new Foo()` that onerous. In fact, it seems kinda quaint after a bunch of Guice and Dagger stuff
mcv 5y ago
I don't think "being like Java" is all that important. These slight variations between related languages are easy to learn. I know a lot of people put a lot of importance on it, but I find the language the least interesting part of programming. Recently someone suggested rewriting our Node.js backend in Python. I've never worked in Python (except the few times I helped my son with his homework), but I'm all for it (as soon as we have some room in our planning, which we currently don't). It's a great opportunity to learn something new. Although apparently it's because other teams in our current department (we've moved around a bit) also use Python on the backend, and they want to be able to move programmers around between projects, but then I wonder if those programmers understand the concepts behind our application, because that's the interesting part of programming.

152 points by azth 5y ago

Basically either use the platform, or be faced with the dilemma of eternal catch-up, features duplication and opposing roadmap goals.

OJFord 5y ago
What does that mean here? I'm not an Android dev but I cobbled together a couple of tiny PRs for something recently, and Google's Android docs cover both, with toggles to flip between Java & Kotlin example code.
- pjmlp 5y ago
  Android Java doesn't count, it is a Java 8 subset, with cherry picked features from OpenJDK, stagnated on purpose as means to sell and market Kotlin on Android. The article is talking about proper Java.
  - curt15 5y ago
    If Google wants to let Java developers use their existing skills on Android, what is the point of promoting Kotlin on Android?
    - pjmlp 5y ago
      They don't, otherwise Android Java wouldn't be on its current state, a stagnated implementation, that fairs quite poorly against Kotlin when comparing language features.
  - OJFord 5y ago
    Oh, then I misinterpreted your comment. (To something like 'if you don't use Java like Android expects you to then expect pain and suffering'.) I just assumed it was about Android because I've never heard about Kotlin being used besides Android. But then I suppose I don't hear about (because I don't work with) Java much either.

namelessoracle 5y ago

The reason i've heard voiced by managerial types is that it lets you have access to alot more off shore resources or contracted resources. TCS/Accenture/Infosys has a firehose of Java devs to throw at a project. Not so much Kotlin. This is of course ignoring quality issues....

hellow0rldz 5y ago
Even assuming more Kotlin devs are coding gods (BIG if), the sheer number difference means you have where to pick good Java devs from. Plus... if Kotlin really is the new hotness and companies want it then mediocre devs can also learn it. So any "genius early adopter" advantage that Kotlin might have is short lived.
- namelessoracle 5y ago
  This isn't a "kotlin coding god" argument. Tata Consultantcy Services (to use an example) has thousands if not tens of thousands of Java "devs". Quality isn't great, but Java has been around long enough that at this point, at least some of who they send to your project actually do have the java experience they claim. Though speaking from personal experience, the dude/lady with 5 years of java 7 and below experiences gets stuck in their ways and doesnt write more modern Java code. I had one dude who got mad and would try to block PRs if you did lambda functions from those bodyshops. My experience dealing with body shops. If you ask for Kotlin, the body shops will send you devs that have Kotlin on their resume, and if your lucky the body shop had them do a 10 hour online course on it. If your corporate model uses body shops you are probably gonna get better results from them with a more mature language than something newer.
blacktriangle 5y ago
I can second both the availability and quality issues. Tried to get a Kotlin dev for Android via Toptal and settled for Java when they said they basically had 0 Kotlin experience on staff. As for quality, the app worked and works well, but there were some serious WTF design decisions made that have made it impossible to maintain the app, not to mention total lack of testing.

ta988 5y ago

I've been considering Scala recently to move from Kotlin that seems to slow down in its evolution and future perspectives. But two points are still pain points for me 1) toxic community members 2) there is a NIH syndrome where there is pressure to rewrite everything in Scala when a Java lib exists (and I still don't know if it is because using Java libs is hard or just because of something else).

anorwell 5y ago
Using java libraries from scala is very easy. In my experience, there are two reasons why java libraries are either re-written, or more often, wrapped with a wrapper library: - To make library usage more idiomatic in Scala. This usually means replacing nulls with Options, exceptions with Try, and mutable or java collection data structures with immutable or scala collection data structures. - To provide idiomatic concurrency interfaces, such converting a synchronous libraries or internal threadpools to scala.util.concurrent.Future (or scalaz.concurrent.Task)
- ta988 5y ago
  Thanks. That makes it more attractive seen like that.

Shadonototro 5y ago

faster perf faster compile time

cs-szazz 5y ago

As soon as I opened the page, I searched for "null" and saw it didn't show up in the original post. Leaving that out is almost a bad faith argument, because it is the number 1 Kotlin feature I doubt Java will ever get. Now, I will say that build times are way better on Java. A large part of this is the ability to generate ABI jars with Gradle, which you can't do with Kotlin. If anyone from Gradle or Jetbrains are reading this, please please please try and make this work, I know there's ongoing tickets but in larger projects Kotlin and Java are not even close, for this specific reason.

usrusr 5y ago
It's funny actually: my java code had mostly made peace with null. A combination of tireless performance of that if-dance where necessary, generous use of static methods for certain routine tasks on nullables and most importantly, @NonNull and null object singletons creeping into more and more code. Now in kotlin it feels like it's just "drown it in question marks". I certainly end up with lots of nonnull signatures and far more reliable null handling than in java, but the ease almost feels wrong.
- wombat-man 5y ago
  I am using more and more kotlin these days as an Android app dev it starts that way, but over time you don't need the question marks as much because you're dealing with more and more code where the variables are guaranteed to not be null.
  - usrusr 5y ago
    Where my code is mostly interacting with itself I see question marks almost as rarely as I saw Optional during my scala adventures (still can't believe a decade went by!), but the android API provokes it's share of nullability and the kotlin approach to deal with it is just so "why didn't we have that back in the MIDlet days!" Some coworkers seem to type questionmarks faster than that IntelliJ "convert to kotlin" button and I hate it, but much less than I'd expect.
- 5y ago

christkv 5y ago

Does it have to be an either or? Our project is mixed allowing us to leverage newer java things where appropriate but still getting the more concise code of kotlin for the majority of our project.

ludamad 5y ago
Sure, you can write Java libraries for a Kotlin project, but I'd argue that for the majority of the code you did make a firm choice
- christkv 5y ago
  There are still things I think is harder to tap into using kotlin directly, such as record types or upcoming simd stuff (I might be wrong here).

afavour 5y ago

Some interesting points in there. My personal summary as someone who's done plenty of JS and Android work: Kotlin is to Java as CoffeeScript is to JavaScript. I loved using CoffeeScript at the time because JavaScript felt like an incredibly stagnant language. CoffeeScript brought so many usability improvements. But that in turn inspired ES6 JavaScript and now no-one uses CoffeeScript. I wouldn't be surprised if we see something similar with Kotlin. But it has an invested and motivated corporate backer that CoffeeScript never had who are branching out in new directions like Kotlin Native, so I wouldn't count it out yet. Native offers some interesting possible futures for cross-platform development (for instance you can deploy to both Android and iOS, WASM soon I believe?). That alone might justify keeping it around.

cs-szazz 5y ago
(not a frontend dev, so excuse any ignorance) I agree CoffeeScript usage has gone down dramatically, but has Typescript not usurped it? It doesn't seem like everyone just went back to using JS, so maybe Scala was CoffeeScript, and Kotlin is closer to Typescript?
- afavour 5y ago
  I don't want to stretch metaphors too far here but there's some truth in what you're saying. TypeScript usage is a tiny minority of JavaScript usage but it's climbing and I'm sure it's much higher than CoffeeScript ever was. But I see TypeScript as a different beast altogether because of its aims. CoffeeScript and Kotlin were both created to make a complicated messy language more straightforward and powerful. TypeScript aims to make JavaScript safer by introducing types. If anything it slows development down, not makes it faster (and before someone jumps on me for saying that: yes, I think it's worth the price). IMO that makes comparisons difficult.
  - cs-szazz 5y ago
    That's fair, though I will say Kotlin's type system having nullability built-in is something I doubt Java will ever fully add (instead of the annotations it currently uses). So in that respect, it's making it more type safe, but the delta between Kt and Java isn't near as big as TS and JS.

brotherofsteel 5y ago

In my experience, the automated refactorings in IntelliJ work better for Java than for Kotlin.

MrBuddyCasino 5y ago
The Kotlin ones are sometimes so buggy it defies belief, especially considering Kotlin is a JetBrains invention. The Java tooling & speed are leagues above Kotlin.

jggonz 5y ago

If you're like me and have spent several years working with Java projects, moving to Kotlin will slow you down at first. You also may not know all the cool new features available in Kotlin from day 1, so you may find yourself doing "java" things in Kotlin, or not knowing how to do some things in Kotlin at all. If you're on a tight deadline for something, you might want to just stick with Java (if you know it) until you can dedicate enough time to learn Kotlin well. If you're new to both Java or Kotlin, then learn both. :)

deccanchargers 5y ago

As a person who is just starting to learn Kotlin for Android Development, Can you please tell me which language is better to pursue for android development? I also recently read this https://billthefarmer.github.io/blog/android-kotlin/ https://billthefarmer.github.io/blog/android-kotlin/ adding to dilemma of choice.

kmonsen 5y ago
Kotlin
thecupisblue 5y ago
As someone who's been in that field for the last, uhhh, 8 or 9 years, I'd say feel free to go with Kotlin. You will understand java the moment you see it later on, meanwhile Kotlin is easier to write, understand and think it. It will get you where you want to be faster than Java. All modern examples will be written mostly in Kotlin, so you won't have trouble adjusting. But in the end, just pick one and go with it, being paralysed by analysis won't help you at all, and after you're fluent in one the other will be familiar too.
nindalf 5y ago
I have nothing to say about the rest of the article, but here's one bit that doesn't make the point the author hopes for. > The obvious difference with the app is that the Java version size is 74Kb, the Kotlin version is 781Kb. Rather a lot of bloat for a small simple app. No, it really isn't. Anything less than one MB is negligible. Importantly, since we have exactly one sample for each we don't know if that's fixed overhead or variable. Does a 5MB Java app become a 5.7MB Kotlin app? Then the overhead is fully fixed and it doesn't matter. Does a 5Mb Java app become a 50MB Kotlin app? That's a problem. The truth is probably somewhere in between. We don't know because the author made the unfounded statement about bloat with just one data point.
pjmlp 5y ago
I would like to say Java, but given the way Google stagnates Android Java on purpose, and pushes Kotlin no matter what, Kotlin is the way to go for serious app development. Then if you want to do anything related to 3D, realtime audio or machine learning, you also need either C or C++, as those APIs are NDK only (OpenGL is actually also available to Java, but Vulkan is the official 3D API since Android 10). Now if you want to target Android only as hobby, use whatever you feel like.

ashishb 5y ago

Checked Exceptions. I wish Kotlin had it too.

kubb 5y ago
They don't have it by design. The Java community has collectively decided it's a bad idea and they're discouraged even in Java.
- inshadows 5y ago
  No it didn't. And they're not discouraged in Java SE. Ignoring errors and letting them propagate to thread's main is just stupid. I haven't heard single argument except "Meh, I have to write throws Exception to every method". It's either "throws Exception" or something like "Either<Exception, String>". Same principle, you declare errors in type system. And if you have reason to believe that it's a good thing to hide errors from type system, then please, convince me.
blacktriangle 5y ago
Checked exceptions sound good in theory but to make it works it requires the whole community to buy into that level of paranoia right from the beginning. It's a much better concept for a language like Ada or Eiffel more design-by-contract style. Java already plays fast and lose with safety, checked exceptions are closing the barn door after the horses bolted. In reality checked exceptions in Java just means everybody swallows exceptions by doing nothing and moves on.
- ashishb 5y ago
  > It's a much better concept for a language like Ada or Eiffel more design-by-contract style. I'm not familiar with this. Please elaborate how you would handle say an I/O failure while R/w a file with this approach?
  - blacktriangle 5y ago
    I'm not familiar enough with either of those platforms to answer that specific question, it was more a general comment on the respective developer cultures. I've worked on several Java codebases where swallowing exceptions was the norm, but in their defense it was because several libraries were way too chatty in their use of exceptions.

RocketSyntax 5y ago

Surrounding enterprise-grade toolset built up over decades. Android. Desktop apps. Hiring and outsourcing. Millions of Java devs.

bitcharmer 5y ago

Performance. There's a very good reason why low-latency and high performance computing crowd don't use inventions like Scala or Kotlin but they do use Java. Yes, they all run on the same JVM but most of the nice features and syntactic sugar comes at a price of generating huge amounts of garbage. It's possible to achieve zero- or low-allocating code with almost fully idiomatic Java but not so much with the alternatives.

weego 5y ago
Those people are a frankly unimportant niche in the JVM world. Even in areas where its relevant (banking etc) 99%+ of the codebase is not coded for those tolerances.
- bitcharmer 5y ago
  Not sure what gave you that idea; it seems you have never been part of that crowd so just throwing unsubstantiated claims around. Performance has always been one of the major drivers in the JVM development. Just read the JEPs and see for yourself.
jcadam 5y ago
I'd argue that Java is a poor choice for this use case as well.
- Pet_Ant 5y ago
  There is a GC specifically for this use case: https://openjdk.java.net/jeps/318 https://openjdk.java.net/jeps/318
  - lolinder 5y ago
    An experimental one. There are still many far better choices for low-latency programming.
    - pjmlp 5y ago

lmilcin 5y ago

There is a lot of reasons to prefer Java (Disclamer: I don't use Kotlin all that much). First, there is really not that much reason to use Kotlin for the type of applications that would normally be written in Java. When I look at Kotlin code in my org most of it looks like Java with some very slight, cosmetic differences. The reality is overwhelming majority of people writing Kotlin is Java developers and overwhelming majority of those continues what they were doing in Java but now in Kotlin. It is more difficult to find people with experience to work on Kotlin. Kotlin is slower than Java, but for most applications it shouldn't really matter (in that if you make it your focus you are probably wasting time while you could be doing something more worthwhile). To develop in Kotlin well, you should also know Java. So now you really need to know two languages. Let's face it, people who go to work with Java projects are not exactly cream of the crop (and I am saying this after working with Java for the past 20 years). Java has some excellent frameworks (ie. Spring), documentation and guidance (ie. stack*) on how to structure your application that makes it much easier for a junior developer to start writing new service and for everybody to understand existing code (because it all looks alike). As a tech lead this lets me focus on other stuff rather than telling developers how to write a controller, how to read configuration file, how to structure your database layer, etc. And bunch other reasons...

qsort 5y ago
I agree with the gist of your comment, but this: > Let's face it, people who go to work with Java projects are not exactly cream of the crop is a bit of a weird take. If you're saying that most people working in software engineering aren't "exactly cream of the crop" to begin with, then you probably have a point (I'm a java dev as well, by the way), but I don't see how the programming language changes the equation.
- tga 5y ago
  http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html True in 2004, probably still true to some extent in 2021.
  - deleted 5y ago

usrusr 5y ago

Not something big enough to overrule other arguments, but the old fashion imperative java as in "mutate stuff in your local scope as if there's no tomorrow" is much nicer to consume in a debugger than the declarative "describe what you want and let the compiler figure out that it fits together or not once and for all" style that kotlin pushes even more than modern java. You certainly don't need the debugger as much for trivial mishaps that are simply not possible in the new style, but if something isn't working at all it's much harder to get your bearings with a quick step-through than in imperative. Of course it's just as possible to go all-imperative in kotlin as it is in java (even scala would allow it), but it's just painful to see an elaborate step by step block full of possible bug hiding places where a simple val...filter...map... expression could provide a clear description of the result. That being said, my mind still hasn't adjusted at all to thinking about names before thinking about types, guess that's very much to expect after a decade of naming 95% of variables "class name, but lowercase". (PS: I actually maintain the fantasy that there might be room for a language that abandoned the entire idea of local variable names and just referred to e.g. parameters as "the {type} parameter", pushing typical cases of more than one instance of a certain type sharing a scope into the type system)

Juntu 5y ago

Script(;:)

flerchin 5y ago

My problem with kotlin is not that it's not better, or not fun. It's that we have millions of lines of java code across hundreds of projects that will not be ported. Having to context switch in between maintaining projects is another stone on top of tech-debt mountain.

nobleach 5y ago

I have microservices in production using both. Kotlin the language, I absolutely love. I'd put it in my top 5 languages. I don't hate Java but I've never really enjoyed writing it. Even with all the cool new features, it's always felt bloated to me. I can't see that ever going away. With that said, I really hate how tight of a hold JetBrains has on Kotlin. While you may find an outlier here or there, (someone using Eclipse/NetBeans - heck, I've even used Visual Studio Code and Vim to hack on some stuff) 99% of the people writing Kotlin are using IntelliJ. Kotlin is built to sell IntelliJ. (And the lock-in is pretty apparent) I don't begrudge a company the right to do this. I don't like it, but I have a choice whether or not to use the language. Lastly, Kotlin feels unencumbered. One can program in a functional style like Scala. One can program in an OO style like Java. It feels "free". The sugar that it adds to Java makes my day to day a pleasure. So consider me a fan of the language itself. I highly recommend building things with it. Am I optimistic about its future? That's really hard to say. Google's behind it at the moment, but Google's attention span rivals that of a fruit fly.

blacktriangle 5y ago
The Google question really can't be ignored, to the point where "Should I use Java or Kotlin on Android?" and "Should I use Java or Kotlin for <any other use of the JVM>?" are two totally different questions.
- nobleach 5y ago
  I agree. Using Kotlin with Spring Boot and Micronaut are no-brainers for me. The Kotlin support for both projects is fantastic. I do feel that if Google pulled the plug and started putting their emphasis on DartVM for Android projects (or something like that), we'd see a reduction in Kotlin adoption in other areas though.
  - throwaway3699 5y ago
    FWIW, Dart and Kotlin are being pushed by two completely different parts of Google. It's safe to say that Kotlin is the future on Android.

kubb 5y ago

As far as I can tell, the central point is that Kotlin and Java will drift away in the future as Java gets more features. One example is given (instanceof). OTOH, Kotlin is growing extremely fast. It was already top 8 in the global developer population report in Q4 2018. Will it gain enough critical weight that it will become one of the standard JVM languages and influence how features are added to Java? https://slashdata-website-cms.s3.amazonaws.com/sample_reports/EiWEyM5bfZe1Kug_.pdf https://slashdata-website-cms.s3.amazonaws.com/sample_report...

wildmanx 5y ago

The name.

gautamdivgi 5y ago

One important consideration is if you need to scale up your team it is much easier to do it with Java than with Kotlin. I know the code/implementation aspect exists but scaling a development team quickly has a much greater chance of success with a "boring" platform.

strulovich 5y ago

I’m working on converting a huge codebase from Java to Kotlin. I like Kotlin and would recommend it, but to answer the question: - slower complication time - more complicated language: this means code that’s harder to optimize, or that can be overly complex when written by junior developers or language aficionados. (This doesn’t have to happen, but it does in my experience) - lack of libraries means you will use Java code, and Java and Kotlin code mixing is really well done, but will still expose you to many quirks. This will mean developers will need to know Java on top of Kotlin. - less stable: things are changing faster in Kotlin, and you’re more likely to see breaking changes if you have a big codebase when the next version comes out. - performance: in the same way C++ can be as fast as C code - Kotlin can be as safe as Java. In practice though, you will use more abstractions and you may want critical components to remain in Java. From my experience though, runtime performance is not an issue in practice for all examples I’ve seen tested.

Ancapistani 5y ago

I worked in Kotlin for a few months, having very little experience Java to begin with. I have/had deep experience in several other languages, though - Python, Ruby, Clojure, etc. Kotlin was nicer to work in that Java, but 99% of the concepts seemed to transfer neatly between the two. Server-side web app development was somewhat limited by the lack of a mature ORM. Exposed and ktorm were the big ones; Exposed explicitly didn't support many PostgreSQL features and had no plans to do some, while ktorm is a small project seemingly maintained primarily by a single developer.

vbsteven 5y ago
> Server-side web app development was somewhat limited by the lack of a mature ORM. I assume you mean a mature ORM written in pure Kotlin with this statement. Because Kotlin interopts so well with Java, you can use any of the battle tested web frameworks like Spring (Boot) with ORM's like Hibernate. Most of these frameworks/libraries even have additional kotlin extensions to enhance the experience. Kotlin + Spring + Postgres is my default stack to do a web/api project in 2021. Super productive environment with good configuration/cloud/di/orm support and a huge ecosystem of available libraries.

vanviegen 5y ago

One reason not to use Kotlin: its syntactic sugar makes it harder to read for someone who doesn't know the language. Most Java syntax and semantics are pretty much self explanatory for anyone who has worked with any object oriented language before. (Java programs are often rather difficult to understand though, but that's due to overengineering, not the language itself.)

barrkel 5y ago

The single biggest reason is to avoid getting stuck with a codebase written in an evolutionary dead end. Java and Kotlin will gradually diverge, particularly as Java gains features which are similar to Kotlin features but implements them slightly differently. Third party library APIs will start use the new constructs and you'll be stuck with two slightly different ways of doing something very similar in your codebase. Over the course of 10 or 20 years, that will probably happen again and again. Java evolution used to be pretty conservative but it's picked up pace and its closest non-JVM competitor C# is miles ahead in expressiveness. For example, CoffeeScript seemed like it made sense 10 years ago. JavaScript was full of defects and CoffeeScript fixed a lot of them, at the cost of a slightly different syntax, though not so different that you couldn't debug the resulting JS. But you wouldn't want to be stuck with a CoffeeScript codebase today.

rrevo 5y ago
Completely agree on aspect of kotlin being an evolutionary dead end. For anyone interested in looking at C#, look at https://rahulrevo.substack.com/p/language-ecosystems-net https://rahulrevo.substack.com/p/language-ecosystems-net and how they have evolved differently.

gutta-percha 5y ago

Incidentally, the author of the linked post is one of the lead maintainers of Lombok, a widely-used Java enhancement library. So he knows of which he speaks. https://projectlombok.org/features/all https://projectlombok.org/features/all https://github.com/rzwitserloot https://github.com/rzwitserloot

twic 5y ago

> Java is trying to figure out smart ways to access CPU-native 80-bit registers What? Java has made use of extended precision floating point on x86 (well, x87) since 1.2. There is actually a proposal to stop doing this now that the x87 instructions are no longer the best way to do floating-point arithmetic [1]. Or is this about something else? EDIT: Why am i asking here? I asked on the Reddit thread. [1] http://openjdk.java.net/jeps/306 http://openjdk.java.net/jeps/306

cpleppert 5y ago
Glad I wasn't the only one to notice that. No one idea what he could possibly mean but given that Java hasn't used x87 in forever and there is no reason to ever want to use them I guess he is just completely wrong here?
- twic 5y ago
  Based on the response on Reddit, yes, i think they are just confused.

AncoraImparo 5y ago

Yeah, Java works. You have to sneak up on Kotlin to make it do anything. Also, when you have questions, the java community is a lot better. The Kotlin community is made up of the same tweed jacket wearing losers that were doing rails back in the day.

NoahTheDuke 5y ago
Do you have anything of substance to add or is this just an opportunity to insult communities you don’t like?

MrBuddyCasino 5y ago

More args in favour of Java: - coroutines in Kotlin are a crappy solution compared to the future Java one, which is to keep using the Thread API and switch to an async model underneath, without the developer having to care about it at all - multi-line Strings aren't fucked like in Kotlin (leading-whitespace behaviour) - superior tooling: IntelliJ works much faster, refactorings are more reliable in Java - build times are much better

vbsteven 5y ago

The HN crowd is not very fond of the magic in popular Java frameworks but to me that magic is what makes those frameworks so good, although with a bit of a learning curve at first. Kotlin/Java with a framework like Spring is the sweet spot for web/api development. Fast enough for most use cases, great tooling, huge ecosystem, just the right level of abstraction, easy to deploy, easy to debug, very expressive code using annotations. An API backed by an ORM can be written in 10 minutes with less than 50 lines of Kotlin. The cons are mostly compile time and startup time. Startup time isn't very relevant for backend services. Compile times aren't great but not horrible either. The pain point with Java as mentioned in other comments in this thread is the presence of null, which among some other things make it a little verbose. That's where Kotlin comes in. Usually my projects will use framework libraries in Java and my own code is all Kotlin. The nulls go away once code exits from Java land into Kotlin land.

mhoad 5y ago
I'd be totally OK with the magic in something like Spring or Ruby on Rails is another good example if it had code I could inspect when things go wrong. That is really my one and only complaint that I have about "magic". I currently find myself playing around now a lot with Dart which has a lot of the same convenience and just handles it via code generation rather than dynamic magic at runtime. For me at least, it's a really nice trade off. It also for the record has fully sound null safety which is something I have only ever seen in Swift previously but is a real pleasure to work with. I guess in the Java world you have options like Quarkus that also give you a similar kind of experience.
InvOfSmallC 5y ago
I cannot agree more. Also maturity of the ecosystem which whichever you don't find in go for example.
lazaroclapp 5y ago
While admittedly not as nice as having it built into the type system from day one, there are a number of tools one can integrate into their build to add various degrees of null safety to Java. Disclaimer: I am one of the maintainers of one such tool, namely https://github.com/uber/NullAway https://github.com/uber/NullAway It certainly won't help with verbosity (in fact, it does the opposite to at least a small degree :)), but it can dramatically reduce the number of actual NPEs when running your Java code. Obviously I am not saying this is a reason to not use Kotlin. But, when, e.g. based on the things mentioned elsewhere in this comment section, you are deciding to stick with Java for a particular codebase, it doesn't mean static null checking is not an orthogonal option to consider.

trulyrandom 5y ago

I think Kotlin is great. I feel much more fluent when writing Kotlin than I do when writing Java. The thing I really miss though, is checked exceptions. I have no clue which exception types a library function might be throwing unless they're explicitly documented (which is rare). Does anyone know if this is planned to be addressed at some point?

alanfranz 5y ago
Add exception to the signature, I suppose. At leasy in Java, you can add unchecked exceptions to function signatures. Checked exceptions are an old idea. Good to see them go away. Just use a “context manager” by passing a callable somewhere.

astral303 5y ago

Kotlin’s closed/final by default is a huge flaw when working with a large codebase. Code is not left extensible by default. I don’t want to sprinkle my code with the open noise. False performance optimization, big maintenance/flexibility expense.

anoncake 5y ago
That is not a performance optimization.
garethrowlands 5y ago
It's not a performance optimisation, it's to avoid codebases accidentally becoming a big ball of mud. Prefer composition over inheritance. Definitely do not inherit accidentally or from a class that wasn't designed for inheritance. The JVM can already optimise classes with no subclasses because it knows all the classes that are currently loaded, so it doesn't need language support.

rrevo 5y ago

Context matters. I think kotlin definitely works for android developers but other cases need more thinking. If you're building webapps in smallish teams then maybe those work too. Some reasons against Kotlin are- * If you are working in a mid to large team then having all developers learn a new language is a massive cost. Learning Java is also still a requirement if you're developing in Kotlin since many open source libraries are in Java. So teams need to be aware of 2 similar but different tech stacks. * If you are developing platform libraries then you would look at higher adoption by using Java 11 LTS as the baseline. You could add an optional kotlin library for a better experience. * Others have pointed out how Kotlin will be an evolutionary dead end as Java catches up on features.

jollybean 5y ago

I think the question should be why Kotlin instead of Java because it provides part of the answer. When I switched to Kotlin, I liked some nice things, but found that in the big picture, it wasn't a huge advantage, and many of the language artifacts I didn't like. Most importantly: Kotlin doesn't produce more succinct code. The code is not really that much shorter. If you go to Android and look at all the Java/Kotlin examples, they are almost always similar in terms of length and complexity. Once you find yourself dealing in an entirely Java world, with Java idioms, libraries, builds, jars and reading java source ... the bit of 'impedance mismatch' to your own Kotlin code then becomes a pain. Kotlin is no way better than having to work in 'two languages at once' with the constant switching. And of course a whole bunch of extra tools as well. Also, Kotlin is more of a 'bunch of features' than a cleanly designed language. So in the end if you are using K for a very specific reason (maybe js compile target), or if you can do the whole project cleanly in K (maybe Android) etc. then maybe K is the choice. But I've switched back to Java and accepted slightly more verbose typing and never missed it. The IDE's do a lot of that work anyhow. Even more qualitative ... I find Java easier to read and maintain for some reason. I would almost prefer a few small changes to Java than I would a new language.

newobj 5y ago

Code size, which can matter on mobile, if your app gets big enough. Build times. kotlinc still has codegen bugs. Been a while since I saw one in javac.

SergeAx 5y ago

I beleive that Kotlin was built not to sell IntelliJ, but to build IntelliJ. JetBrains has that line of about 20 IDEs all written in Java sharing an awful lots of common code. I think that together it is among largest Java codebases still in super-active development. So, you have to code on Java 40 hrs per week year by year. All those `Foo foo = new Foo();`, every day. And you think: "If only there was a language like Java, but better, and it was interoped with Java, so you can gradually introduce it into Java codebase!".

distribot 5y ago
I can only speak for myself, but I've never found the `Foo foo = new Foo()` that onerous. In fact, it seems kinda quaint after a bunch of Guice and Dagger stuff

mcv 5y ago

I don't think "being like Java" is all that important. These slight variations between related languages are easy to learn. I know a lot of people put a lot of importance on it, but I find the language the least interesting part of programming. Recently someone suggested rewriting our Node.js backend in Python. I've never worked in Python (except the few times I helped my son with his homework), but I'm all for it (as soon as we have some room in our planning, which we currently don't). It's a great opportunity to learn something new. Although apparently it's because other teams in our current department (we've moved around a bit) also use Python on the backend, and they want to be able to move programmers around between projects, but then I wonder if those programmers understand the concepts behind our application, because that's the interesting part of programming.