94 comments on "Java vs Kotlin: Quantitative Analysis"

1. Great article again Vasiliy! You should promote this post and maybe search for a publication on Medium to publish it and get some traction. I had some thoughts regarding this too. A lot of developers are praising Kotlin, but yet I could not find any case where it would be much better than Java.

   Reply

   • Thanks Dragos,
     I believe that many professional developers share your opinion on this matter (incl. myself), but they are not interested in taking part in language “flame wars”. Therefore, we don’t hear them as much.
     I hope that this article will help developers to argue against “new shiny language” in objective, economic terms.
     And I will definitely cross-post this article to Medium as you suggested.

     Reply

2. Thanks for article!

   But I have the opposite opinion. You do not take into account not all. Kotlin not only improve code writing speed, but also decrease time needed to read code. In Java it’s difficult to express thoughts. Kotlin on the other hand give a possibility to write code more simpler and impressively.

   Reply

   • Hello Evgeny,
     Thanks for your comment.
     Unless you have a hard data to support your claim, the opinion that you expressed is another example of subjective judgement. It might be true for you, but it is far from being generally applicable.
     BTW, the 10% productivity boost for Kotlin that I assumed in the estimations takes into account everything – potentially better syntax, potentially better readability, etc. And, as I said, this 10% improvement is unrealistically high number in favor of Kotlin.

     Reply

     • Your assumption about 10% of productivity boost not based on any real measurement.
       Company in which I worked moved from Java to Kotlin (mostly on backend development). And we done at the beginning of 2016. My opinion is that productivity has increased at about 15-30%. But more importantly that Kotlin code has less bugs and it’s easier to maintaince. Therefore, in the long run this also plays an important role.

       Reply

       • First of all, on a non-trivial project, I don’t think that productivity increase of 15-30% is something that can be achieved by switching to a different programming language that has the same level of abstraction. But don’t take my word for that – read this article by Uncle Bob (the same one that I referenced in the post).

         However, for the sake of an argument, let’s assume that Kotlin does improve productivity during coding and debugging by 30% (instead of 10% that I used in my calculations). If you perform the calculations using this number, you will find that, for the project I estimated in the article, the additional effort due to switch to Kotlin would be: 86 + 5 * N_developers (man-days)

         Reply

3. Using the same approach it would be easy to prove we should have stayed with FORTRAN or BCPL and never choose anything new (for it is always additional effort).

   Reply

   • Hi Jarek,
     It could be a nice thought experiment – give it a try.
     I don’t have experience with either of the languages you mentioned, but I think that you’ll find out that your statement is not exactly correct in the general case. Several reasons for that:

     1) There were fundamental changes in programming languages that added real value (e.g. object-orientation, multi-threading, generics, etc.)
     2) The size and complexity of the programs grew enormously
     3) The cost of computer memory and processing power dropped significantly
     4) The tooling became much more important

     You might be surprised, but until recently Fortran was more popular than Kotlin. Therefore, what you say did happen on a smaller scale – many people stayed with Fortran. The same goes for many other older languages.

     In fact, Python, which is also relatively old language, is the fastest growing language in the world.

     On the other hand, “new” and “better” languages, like PHP and Ruby (which are not really new, but their mass adoption happened after 2000) are already past popularity maximum.

     Subjectively speaking, looks like we don’t need yet another language which is essentially just Java equivalent. Objectively speaking, Kotlin will cost our community a lot (numbers in the article).

     Reply

     • And that is wrong assumption. Kotlin is absolutely not Java equivalent. Not even close.
       Same as C++ is not just C equivalent.

       This is the language that allows you to write efficiently functional code with immutable/functional data structures – something like Scala but a little bit less complicated (I call Kotlin Scala– ).

       This is a huge difference. Writing such (functional) code with java is painful. (No, lambdas are not enough).
       Kotlin allows you to use efficiently more powerful tools than Java standard. (for instance Ktor as webserver). In java there is Ratpack (ktor equivalent) – but writing functional web servers with java is a mess.

       Reply

       • I guess we won’t be able to agree on whether Kotlin is equivalent to Java or not, which is totally subjective judgement 😉

         Reply

         • How is that subjective? You can compare equivalence based off of language features exclusively. You could argue that such features are not beneficial or do not provide much gain but the fact that one language offers more built in features proves that they are not equivalent regardless of whether you think they are good or bad.

         • It seems that you distinguish languages by features exclusively. I distinguish languages by things like threading model, memory model, modeling capabilities (abstraction level), etc.
           If you judge by features then yes – these are different languages (though not very different). If you judge by underlying principles, then these languages are almost totally equivalent. The fact that Kotlin needs to be inter-operable with Java restricts it to be very much like Java.
           But, again, this is a subjective discussion which is not the point of this post. Regardless of whether we agree or not on subjective stuff, the objective figures derived in this article are the ones that should be taken into account (or debated).

4. I’m sorry, but I think the article is based on some shaky foundations. I haven’t seen much success from using Cocomo2, and the productivity increase, experience lost, etc. are all guesses, so all the calculations made afterwards are fallible. To crunch numbers that way, I would rather see some measurements from actual projects that made the transition, not just estimations. And I respectfully don’t mind about Uncle Bob’s opinion that much. 😉

   Apart from that, what I think is missing is the amount of bugs that will arise after the language transition, or more exactly the time spent fixing them. The biggest one I’m expecting is the anhilation of all NPEs… and that’s not a minor detail.

   Reply

   • I too would want to see real numbers from real projects. Unfortunately I haven’t found any that look legit and representative.

     Yes, Cocomo2 is not a very accurate model, and it became outdated too. But, at least, it is a model that shows which factors should be taken into consideration. You are more than welcome to plug in the numbers that you find reasonable and share your results.

     The “annihilation of NPEs” was already factored in into “coding and debugging” productivity boost, therefore it is not an additional factor. Subjectively speaking, I have never seen NPEs as a major problem on any project, and I almost never see NPEs in my production code because I unit test.

     Reply

     • If you haven’t needed to hunt down a NPE in production you’re truly a blessed man. From legacy projects with little or no tests to recent ones where an effort to apply TDD is made, NPEs can be easily at the heart of, more or less, one in four bugs I have to look for.

       Unit tests can mitigate them. But in Kotlin the compiler makes them impossible, with no added effort. Easier AND better? What’s not to love? 🙂

       Reply

       • Serandel,
         I would say that 25% bugs caused by NPEs is high. Either you guys are awesome and there are not very many bugs to start with, or you have a special affection towards NPEs.
         In any case, Kotlin does not make them impossible. From the top of my head – null returned from Java library or framework and reflective assignments are two occasions where Kotlin null safety may be insufficient.
         And, for sure, it is not “with no added effort”.
         I haven’t used Kotlin on a real project yet (hope to avoid this experience), but I did read articles written by people who used it and reported back professionally. It takes actual effort to make Kotlin code null-safe. In addition, it looks like there are multiple tricky operators related to null-safety in Kotlin, which can increase the mental overhead and barrier for entry.

         Reply

         • I can’t for the life of me understand why trying to not have null values helps you write less buggy code. If you’re getting nulls when you don’t want them, then thats just your programming. It shouldn’t be a mystery why you have a null & dont want it. And if its from an external source – then thats gonna be the same regardless of your language.

           A lot of language improvements seem to stem from making things easier for people who probably shouldn’t have their needs catered to.

5. I’m an editor at InfoQ.com.cn，May I translate your post into Chinese for appropriate credit?

   Reply

   • Hello Martin,
     You are more than welcome.

     Reply

6. I think there is one stuff which probably can’t be measured, but might have impact during transition to Kotlin in short term. It is actual developer satisfaction (subjective) to migrating and using the language. If your company force devs to code only in Java when all want to move to Kotlin, your productivity and morale in company can drop significantly up to devs leading for other companies which migrate to kotlin.
   Yes in long term and statistically you might turn out right, but that exact company which looses half of their devs coz of not letting them try out Kotling, might not be very happy with these calculations. And also, sometimes adopting something innovative might be expensive in short term but can turn out to be very good in long term. At the beginning of Java itself nobody was planning that it will be the server language of the net, in opposite it was planned as lightweight language for frontend applets.
   Also I agree somewhat with Jerek that Kotlin is not exactly Java, though being on JVM it might inherit some of it’s limitations. But even by your standards – Kotlin has some important things which goes over Java and it impacts not only coding, but also design and maintanance costs.
   1. Threading model – Kotlin bringing old good coroutines will dominate Java on paralellism
   2. That NPE – much much less bugs in production, though I agree with Uncle Bob, NPE is not language problem, but developer problem
   3. Functional types. They are natural to Kotlin where for Java they are addon, so dev coming to Kotlin is not restricted by thinking patterns of Java, thus more design freedom is given to them for implementing things better and faster than Java
   4. After Oracle JAVA API war, it is walking over mine field to stay with Java for long time
   5. DSLs – good luck writing useful DSL in Java, where exactly DSL is project delivery booster in giantic business heavy projects

   Me – Writing Java since 1997 and one of rare beasts having Java 1.1 developer certificate since 1999 🙂

   Reply

   • Janis,
     Thanks for jumping in and sharing your opinion in such a detailed manner.

     This post is not for companies/managers. It is for developers. Maybe I’m a bit naive, but I believe that most developers want to do a good job, and when presented with facts and numbers – they will make a decision as grown-ups.

     BTW, I’ve never seen a developer leaving a good workplace because the other company worked with language X. And I would never want to work with a developer who did something like this.

     However, I did see professional developers leaving because they were forced to spend time on migrations to “new shiny techs and processes” instead of doing their actual work.

     Reply

7. ‘I distinguish languages by things like threading model, memory model, modeling capabilities’

   Are you aware of coroutines support in Kotlin?

   Reply

   • Hello Dmitry,
     Yes. Very interesting feature. Not sure why I would use it over regular thread pool that I’m so accustomed to though. In addition, I expect a high amount of concurrency bugs being introduced while people get accustomed to coroutines.

     But, again: you might like the coroutines, and I might not see their point. Unless there is a research that shows that coroutines have some real impact – their discussion is subjective.

     This thread specifically starts to resemble a classical languages “flame war” where people exchange statements like “my language has feature X” and “feature X is not important”. This leads nowhere.

     I wouldn’t like host a flame war on my blog, therefore let’s get back to objectivity. The article lists the assumptions and the techniques that I used in order to get to the stated results. You can challenge and discuss any of these.

     Reply

8. This is exactly the kind of article the management of many companies will link in a mail to prevent their devs from using Kotlin. It hinders long term positive progress.

   Code a simple program in both languages and you will realize how outdated and unnecessarily verbose Java is compared to how much more flexible, concise and less error prone Kotlin is to develop with.

   If you’re afraid of moving on to a better language, that’s fine. Stay with Java, it’s inter-operable with Kotlin. But don’t mislead everyone else.

   This is the article is the equivalent of saying SVN is just as good as GIT, and the company will lose money by learning GIT.

   Reply

   • Hello MisterJay,

     All these are your subjective opinions about Java and Kotlin. I could disagree with you on many points, but that would lead us to having a subjective disagreement which, in turn, can evolve into flame war.

     In this article I intentionally attempted to present an objective picture of the matters, while consistently assuming the best possible outcome for Kotlin. Therefore, even if what you say is the universal truth – the effect of Kotlin being a better language (which is a debatable statement) has already been taken into account.

     You can challenge the assumptions and the models used in the estimations and calculations, but as long as the only argument is that Kotlin is a better language – it changes nothing about the conclusion of this post.

     Reply

9. This post is rubbish and FUD. Go ahead and use the language, then you will see and quit theorycrafting.

   I am a daily Kotlin user for two years and I can tell that my productivity skyrocketed from objective metrics: story points and closed tasks.

   It is also an objective metric that I rewritten a project in Kotlin from java and the LOC is around 30% of the original. You just can’t dismiss the fact that you hace to write so much less code.

   Reply

   • Hello Adam,
     Rubbish is relatively harsh word, don’t you think? Such a statement requires justification.
     I presented all the assumptions and models that were used during calculations. Therefore, if this post is indeed “rubbish”, it should be not that difficult to point out where the erroneous assumption or model was used, and then perform calculations that shows the actual state of the matters.
     Your claims about productivity “skyrocketing”, on the other hand, are not supported by any data as far as I’m concerned. If you had such a great experience with Kotlin, why don’t you write a post and show us your objective metrics?
     I find it really difficult to believe your claim about the fact that the same design converted to Kotlin reduced line count by 70% (even if your project consists entirely of value objects).

     Reply

     • A I have said before: you can craft theories but it is a moot point until you try out the language and gather empirical facts. This is what I did and you should. It is clear from your article that you did not ship production code with Kotlin so you are really not entitled to evaluate it.

       Reply

       • Adam,
         I think that neither your statements are empirical facts (more like subjective opinions), nor that the concept of “entitlement” has a place in software development.
         Thank you for sharing your opinion with us.

         Reply

         • My statements are **by definition** empirical evidences:

           > Empirical evidence, also known as sensory experience, is the knowledge received by means of the senses, particularly by observation and experimentation.

           Of course everybody can say anything but if it is not backed by empirical evidences (e.g: you didn’t even try it out) it will look funny at best.

         • Adam,
           Your statements are neither empirical facts nor empirical evidence. Allow me to explain.

           You started by claiming that the article is “rubbish and FUD”, then presented a number of 70% code reduction without any additional information and then proceeded to suggesting that I should “gather empirical facts”.

           Now you quote a single line from Wiki article and apply it to your own statements…

           If you read the same article you copied the sentence from to the end, you will learn that, in scientific context, there is a link between empirical evidence and scientific method. Scientific method states several criteria that should be fulfilled in order for any data to become empirical evidence.

           One of the most important criteria is that the “experiment” that produced the data should be reproducible, and the measurement outcome should be independent of who performs the “experiment”. Since none of your statements is supported by any information that describes what you did and which measurement techniques were used, your statements, by definition, are not empirical evidence.

           What are your statements then? Objectively speaking, all your statement are just anecdotal evidence. As stated in Wiki (it looks like you consider it to be the source of truth), in scientific context:

           > Anecdotal evidence is considered the least certain type of scientific information. Researchers may use anecdotal evidence for suggesting new hypotheses, but never as validating evidence.

           If you’d like to learn how empirical evidence should be reported, then you can read the definition manual of Cocomo2 estimation model that was used in this article – this model is based on empirical evidence.

           Since the article is based in part on a real empirical evidence, states its assumptions and techniques explicitly, and allows for easy verification or adjustement of the results – this article might be considered a scientific publication. Since it has open comments section – it is even peer-reviewed.

           Therefore, your anecdotal evidence (subjective opinion) is not relevant in context of article’s conclusion.

           P.S. Please don’t bother responding. I’m not interested in hosting comments that are unrelated to the content of the published article, based on a very limited understanding of discussed topics and rude. If you want to continue this discussion – send me email or ping me on twitter.

10. Nice. But you are missing important points by reducing the conversation to development time. Things like immutability or null safety can prevent errors, and that alone can mean money and time savings more significant than any development time. Same reason why I consider compiled and type-safe languages superior to interpreted ones, without even having to debate subjective things.

    Reply

    • Hello Daniel,
      Software development is a process that has several stages. We discussed which of these stages might be affected by Kotlin and the assumed productivity increase of 10% during “construction and debug” stage that was used in estimations already includes all potential benefits due to e.g. immutability and null safety.

      Reply

11. A quick note about release cycles: Java’s current release cycles are very slow in comparison with Kotlin. So while I follow your point when comparing their volatility I think it would also be constructive to compare and contrast how often they release language updates. Of course I would prefer Kotlin have less volatility, however, I think weighing that with the average period of release is important, too. Java would likely benefit from have more regular releases where large new features aren’t holding back small language changes and fixes. It’s a bit hard for me to grab detailed release stats at the moment since I am mobile so forgive me for not providing the data. Would be interested in reading your thoughts on this.

    Reply

    • Hi Adam,

      This would be a very interesting discussion, but, unfortunately, I’m not enough of “java expert” to have a say here.

      However, this post from several days ago suggests that Java might indeed get a shorter release cycle. Looks like your line of thought is aligned with Java officials 🙂

      If you’re interested in MY VERY SUBJECTIVE OPINION, I don’t think that Java should evolve more rapidly. Explanation below.

      What many developers fail to acknowledge is that Java is a good language – it is sufficiently feature rich, mature and stable.

      Yes, we all have specific parts of the language that we don’t like or miss, but, overall, Java is one of the only solid choices available today. In my opinion, ignoring the fact that for the past 20 years or so Java has consistently been in the top programming languages, or attributing this fact to any other reason except Java being a good programming language, is arrogance.

      So, how did Java managed to stay relevant for such a long period of time, during which languages like PHP and Ruby saw a rise and a decline?

      I think that the secret of Java is its stability. Java evolves by observing patterns that succeed in other languages and then carefully picking very few of them to be incorporated in it. This slows down the evolution, but prevents Java from being bloated. It also allows the coding practices to slowly evolve as the language progresses and prevents a mess.

      Experience of past 20 years of so show that this is indeed a very good strategy.

      I’m a bit afraid that if Java will be switched to a more rapid release cadence, it will be too easy to add new features to it. Thus, the risk of bloating the language and the risk of not being able to adjust development practices increase.

      As I said, the above is just my subjective opinion and I shared it only because you asked. Therefore, I would ask other developers not to jump in and demolish my claims (potentially starting a flame war) – I acknowledge ahead of time that these claims are totally subjective opinions of mine and that they are probably wrong.

      Reply

12. Another “opinion” but I am vastly more efficient writing Kotlin, measurable, possibly, but as stated difficult?
    Greater than 10%? probably.
    However if Android had Java 8/9 at lunch then this would be a different argument and Kotlin might never have had such a large uptake or even been officially supported.
    Being an independent language to Java, Kotlin will have the mobility to side step around Java – I mean we are still waiting for Java 9 after it’s been delayed again.
    One thing you didn’t account for is error and bug rate, there is an argument bugs are developer issues, which isn’t false, but I would rather have a car that stops me from crashing than one I have to remember to do everything, that leaves my brain cycles for other things like writing actual logic – I generally find it much much harder to write “mistakes” in Kotlin.

    Reply

    • Hi Christopher,
      Thank you for sharing your experience.
      I would be very much interested in knowing why you find it “harder to write mistakes in Kotlin” (except null safety, which we already discussed with other commenters).
      I assumed that Kotlin will not have a noticeable effect in architecture and design stages, but maybe I was wrong? Are there any special features in Kotlin that prevent design mistakes?

      Reply

13. Really good article. Just putting some engineering mindset on this Kotlin hype.
    I have seen a lot of hype in Kotlin, and everytime I try to discuss about it…. never find a good reasons to switch from Java.
    I could say that Kotlin is for guys who could not learn Scala, but, you know, this would not sounds good. haha
    []’s

    Reply

14. This is a completely ridiculous article. You may be right, but it would be absolutely accidental.

    You take no considerations for readability (it is after all, subjective), but the fact that the majority of people find it more readable isn’t nothing. Your claim to the contrary, that readability isn’t affected by language is similarly subjective, and contrary to what most developers believe.

    What you don’t consider at all, is the additional features in Kotlin which affect both testing and design. Functional programming in general greatly effects design, and can also facilitate easier testing. This is to say nothing of the more expressive list features, optionals in methods and async/await.

    On top of this, null safety and real language level singletons do a great deal to reduce bugs which is a significant portion of any project.

    Is Kotlin ready yet? It’s hard to say, the tooling isn’t equivalent to Java yet, or C# (though probably already ahead of any other language I’ve used). It takes time and effort to switch (though 100% interop with Java and the various Java->Kotlin tools greatly reduces this overhead), and it’s not as stable.

    You have a point of course, your article is FAR from objective.

    Reply

    • I don’t see a way to edit this, my response was a bit rudely worded, especially at the beginning.

      I apologize about that, but I do believe that this isn’t at all objective and no more valid an argument than any others I have seen, and it annoys me a bit that you are purporting these wild estimates of yours to be some sort of strong objective fact, repeatedly referencing them as people disagree with you in the comments.

      Reply

      • Hello Josh,
        Thanks for sharing your opinion. No worries – I don’t take offense when my ideas are being criticized (in fact, I learn a lot when they are).

        First of all I think you misunderstood the article a bit.

        The section where I share my subjective opinion about readability is there in order to demonstrate that subjective opinions are effectively worthless. Therefore, there is no point in attempting to prove that my subjective opinion about readability is wrong – it does not change the conclusion of this article at all.

        Furthermore, potentially better readability of Kotlin was factored into 10% improvement during “coding and debugging”. If you think that this number is too low – go ahead and tell us why and what’s the correct number in your opinion.

        Now to your points.

        I never know what people mean by “functional programming” – there is so much confusion about this term. Therefore you’ll have to be more specific about this one.

        In respect to Kotlin, I would guess that you’re referring to higher-order functions and clojures. I did contemplate whether these aspects give Kotlin any edge in design activities, and decided that it is probably not the case.

        Regardless of my opinion, if you believe Kotlin has anything to offer in context of design – name it, estimate its effect and plug it into the formulas. Let’s see how the overall picture changes when you inject your own assumptions into the estimation process.

        We have already discussed null-safety with other commenters, but I’ll repeat it here: I have never seen NPEs being a major issue on a project, and I almost never get NPEs in my code because I unit test. If anyone wants to factor null-safety as productivity advantage, I think it is up to this individual to show the statistical data over a set of projects that supports this claim.

        Singletons. While there are use cases for Singletons, they are very limited in my opinion. Making Singleton a language level construct will probably encourage developers to use them more. I worked on a project that used Singletons extensively – very bad experience. However, regardless of what I think, if you think that Singletons give Kotlin any advantage – go ahead and factor it into the estimations.

        Last word.

        You might feel that my estimates are wild. That’s alright, but it doesn’t mean that the article is not objective.

        Since I clearly stated all my assumptions and techniques, you can change any of them and get a different result. You can even account for additional effects that I did not take into account at all.

        So, I’m not “purporting these wild estimates of yours to be some sort of strong objective fact, repeatedly referencing them as people disagree with you”. I totally acknowledge that my estimates might be wrong.

        But the method is correct.

        Therefore, what I say to all commenters who attempt to inject their subjective opinions into the discussion is that if they want to prove me wrong, they must convert their subjectivity into objective terms first.

        Otherwise, it is just a classical languages flame war.

        Reply

15. Ok, so I found this article disturbing yersterday, still don’t really like it but it provoked in me a thought you may find interesting.

    The reason we can decipher without too much trouble the paragraph “This message proves how your mind can do amazing things…” is that you have a very high proficiency in english. You have figured all that out already and that gibberish is not much more than an annoyance. Maybe you could read it only 20% slower.

    Now our industry is a bit special because every few years the number of programmers doubles, which means most of us have a few years of experience and are learning their way to proficiency.

    So now imagine a teenager girl in Asia, and you are given learning material that look somewhat like “This message proves how your mind can do amazing things…”. What is the effect on her learning?

    So your article made me reconsider. I now think the main reason I am grateful for Kotlin is that while practicing it, the compound effects of so many things being designed with taste had a dramatical effect on the speed on my learning. Not 10%, more like 3x.

    Reply

    • Hello Jean-Michele,
      Thanks for sharing your thoughts.

      First of all, I’m not linguist, which means that my ideas about languages are just subjective opinions which, probably, do not worth much anyway.
      Said that, you might have noticed that I noted that alphabet substitution is not exactly a syntactic change. I think this is what you imply by saying “the reason we can decipher […] very high proficiency in english”. Since the syntax did not change and some letters were substituted with similarly looking numbers, we can still use our pattern recognition abilities trained for regular English. I agree with you on this point.

      As for the speed of learning – it is very interesting idea. Currently I still think that you judge it subjectively and not very accurately because 3x increase in learning speed of Kotlin as compared to Java seems unrealistic. However, it would be nice to see some real empirical or research data in this context.

      By the way, your mention of industry doubling every few years – is that Uncle Bob’s influence? 😉

      Reply

      • Yes, I got that line by hearin him on a podcast. Also in the article you posted, Uncle Bob made two points that sounds like Kotlin design goals : don’t start a flamewar between function programming and OOP when you can combine both, and great tooling matter at least as much as shinny new language features.

        My guesstimate lacks scientific value- I cannot do double-blind trials because I have only one life and other people’s situation are different. Still the effect was dramatic. It helps when design patterns are backend into the language. New things are easier to grasp when the relevant information fits on one side. So many times, where I could have been stuck, an handy extension function from the stdlib helped fluidify the learning experience. I really enjoyed the “kotlintest” framework and it got me into the testing habit. Also now each time I come accross a new java library, instead of just looking at the docs, unsure wether I understood it or not, I wrote a 10-50 lines kotlin script or test. All of this can be done with java. (And I’m confident that I will be able to retrofit most of my new skills if I work on a java codebase). But a lower cognitive overhead / signal over noise ration helps a lot to get into the habit.

        Reply

16. @Vasily
    At the end of day the history will sort this out. I think the article is good at least in the matter of invoking discussion and thinking. Businesses and devs need to thnk about “new shiny things”, and to not jump onto sinking train is as important as not missing the one heading into the future.
    Me, personally, believe kotlin is here to stay, but I will not bet my head on it fully.
    I know occasions of devs leaving company for other, where things are being done by “feng-shui” – using modern libraries, modern approaches and modern languages.
    At least we live in interesting time… though not so interesting as 60ies and 70ies of IT

    Reply

17. Thought has struck me.
    I think there is portion of Java developers who are eager for something modern, current and good, so they are frustrated that somebody tells that this new “kotlin thingy” will not give them expected boost. But here is history in play. Programmers feel the expanded freedom when they are given new (actually old from 60ies and 70ies) toys which they can’t get in Java or it is very clumsy.
    Functional programming is comming and staying, but Java coz of it’s contract of backward compatibility becomes little bit clumsy with 8 and 9 so programmers might not realize it but they feel by their guts, that Java is morally and technically old… and they are looking for something new. And funny – but kotlin promises and (as far as I can see) fullfils the promises.
    Kotlin interop with Java is big thing – not like with Scala
    Kotlin functional paradigms are easy to understand for Java guys
    Kotlin syntax has “fun” all around the code 🙂
    So I would say there is much more psychological than technical joy around the kotlin, and having fun in your everyday life is good to have even if it doesn’t bring the expected performance boost immediately.

    Reply

    • Janis,
      I wish I could get as much joy from just switching to a different programming language as you do 🙂

      Reply

18. This article is ridiculous. You say over and over that one shouldn’t be subjective, but you make an extremely high amount of assumptions throughout this article. You grabbed a topic (Kotlin vs Java), and put numbers and equations to it with numbers pulled out of thin air. Based on this article, as well as your replies to other comments, you very much have an opinion you are trying to share, but are placing it under a facade and acting like everything here is “objective.”

    Maybe listen to the comments that are from those in the industry (as well as myself at a big 4) expressing the true time gained with the switch rather than guessing numbers and equations. Take the comments seriously rather than saying “I unit test, I don’t get NPEs”. That’s simply garbage and is adding another assumption, that everyone unit tests every line of code and therefore doesn’t get NPEs. I unit test everything, but you can’t assume every project is, on top of the fact that Kotlin prevents the NPEs pre-unit testing.

    Reply

    • Hello Earl,
      Thanks for sharing your opinion.
      The sources and the references for the numbers and techniques are explicitly stated. If you don’t agree with any of them, then you can change them in whatever fashion you see fit and share your results with us.
      That’s the beauty of objective comparison – it allows people to present and criticize ideas without resolving to stamping each other’s opinions as “ridiculous” or “garbage”.
      As for whether the comments from other readers express “true time gained”. With all due respect, I find it difficult to believe that switch to Kotlin reduces the amount of code by 70%, or that Kotlin is 3x easier to learn than Java. I think that these numbers, stated by other commenters, show how flawed our subjective judgement is.

      Yes, I have an opinion to share and I shared it.
      In my opinion, when considering one language as a replacement to another, subjective judgement of developers is usually misleading and does not take into account all factors. Therefore, objective metrics should be used in order to estimate the true cost of a switch from Java to Kotlin.

      Reply

19. At last, I’ve found a sensible article regarding this “new and shiny thing”. Now I understand that all those unrealistic development speed, skyrocketed productivity and heavenly happiness in using Kotlin were subjective opinion far from an objective one. As all things subjective, my opinion to disagree is as good as theirs. Thanks for the read.

    I’m very much interested in second article about why did google supported a second language on the android platform which seems to add more complexity rather than to reduce it. Not to mention that android platform itself is a quite complex one with various edge cases, lack of clear architecture, inconsistent documentation, etc which need to be solve first. Adding another language just doubling it rather than to solve anything. I might say that without Stack Overflow, one can’t write a non-trivial app in an acceptable time from scratch to production with all those edge cases. To be honest, I’m quite baffled with the announcement in IO17. It doesn’t make sense from developer perspective but it might from google’s. No official statement and no clear road map except we like to give more options to developer. Google might like it very much to impose Kotlin on developers but then decide to let peer pressure to do the work for them. Clever but sorry, I’m not easily succumb to peer pressure. Looking forward to it.

    Reply

20. Great article. Kotlin is more readable than Java – this is the most arrogant of all things that Kotlin people say. It uses so many abbreviations, shorthands, and various syntax sugars, that the amount of mental mapping required to be able to hold all the actual meanings of everything you see, is unbearable, and it requires several read-overs. On the other hand, in Java everything is written out in front of you, and you can use your brain’s RAM to think on solving business problems rather than mental-mapping obscure characters to idiomatic funcitonalities. Kotlin is faster to write, but not easier to read. Not to mention, our job is not to write stupid stuff as fast as we can, we are not data entry operators. Our job is to think a lot and seldom touch the keyboard.

    Reply

    • Kaloyan,
      Thanks for sharing your opinion.
      FWIW, my personal subjective view of this matter is very similar to yours. Your last two sentences deserve to be carved in stone IMO.

      Reply

21. This article is clearly an attempt to support a subjective preconceived opinion with arbitrarily chosen assumptions.

    Reply

    • Hello cobolforever (cool nick btw),
      Thanks for sharing your opinion.
      While I do have subjective opinion about this matter, it is not being expressed in the article itself (you can see parts of it in my replies to some of the commenters).
      This article uses scientific approach – all the assumptions, techniques and results are being explicitly listed. If you feel that the assumptions were chosen arbitrarily, you are more than welcome to choose other assumptions (or techniques), perform calculations and share the results with us.

      Reply

22. Great article! I agree. I’m looking forward to your next article reasoning as to why Google would support another first class language. Does it have to do with Oracle? Wink. Wink. ?

    Reply

23. I disagree about the skill lose. I have 5 years in Java development, when i switched to Kotlin, i didn’t feel any skill lose, because kotlin shares the same frameworks and libs to Java, spring is still spring, netty is still netty, hibernate is still hibernate, mybatis is still mybatis, JVM is still JVM…

    Can you tell me what i lost?

    BTW oracle is going to have two major java releases every year, 0.82 in your assumption should be 1.00.

    The subject of your article is kotlin vs java, your calculation is switch from java to kotlin, but how about switch from kotlin to Java?

    Reply

    • Hello Sagaxu,
      Thank you for sharing your experience.

      What you lost is 5 years of experience with programming language. Since, like you said, most of the tools can still be used, and the languages share many concepts, it would be appropriate to say that you kept most of your LTEX. How much exactly? Impossible to say. I would estimate it to be in the range of 2-4 years.

      It is not yet clear what cadence will Java have, and what is being designated by “major change” in this plan. For me, transition from Java7 to Java8 wasn’t a major change at all, though I don’t know whether there were any non-backward-compatible changes that did not affect me.

      Going from Kotlin to Java is pretty much impossible I think. And it is not a coincidence.

      Reply

24. Hello Vasiliy, I find your article good, but I disagree with many points.

    In your text and in your answers to comments, I’ve noticed that you’re kind of “avoiding” direct answers that include functional programming and code maintenance. Actually it seems that you “lower” the value of functional programming. With Kotlin you can do some of functional programming (not as much as with Scala though), in Java, on the other hand, I don’t know anyone using functional programming.

    On the point of maintenance, you are just mentioning a development time for creating new projects, but many projects live much longer after they are fully developed. Can you analyze that aspect of Java vs. Kotlin?

    Also you have not mentioned anywhere a similarity between Kotlin and Swift.
    I find this important, since many Android developers are iOS developers as well.

    Also, you have not mentioned a lack of support for Java 7 and Java 8 on Android (not to mention newest Java 9). They probably will never be supported fully.

    Reply

    • Hello Aleksandar,
      Thanks for sharing your opinion and criticism.
      These are very interesting points that you raised. Allow me to address some of them.

      I don’t think I’m “avoiding” talking about FP. All improvements that Kotlin brings as a language were already factored into 10% increase in productivity during “coding and debugging” stage. If you think that FP’s impact is higher than this, or that it stretches to other areas as well – go ahead and choose other numbers that you’re comfortable with, plug them into equations and share the results.

      On a very subjective note I can say the following about FP: the impact of FP is way overrated, and its drawbacks are being underestimated IMHO. Even the meaning of FP is being generally misunderstood in Kotlin’s context.

      Contrary to many Android devs, I actually had a chance to write real FP code in Perl some time ago. Back then I worked in semiconductors industry and we used Perl for many tasks. Among the more complex of the scripts/programs that I wrote/maintained with Perl were code parsers, generators and converters.

      From my experience I learned that FP is super-hard not to abuse and it is way too easy to write messy, unreadable and unmaintainable code using FP approach. I would speculate that one of the main differences between Python and Perl is the degree of their FP’ness, and the adoption stats speak for themselves.

      I guess that the problem is not FP by itself, but a very different mindset and techniques that developers need in order to tame this beast and know the limits. Object oriented programmers don’t have the required experience, therefore I expect to see a lot of super complex, unreadable and unmaintainable code written in Kotlin in the next several years.

      I think that we already see ever increasing complexity of FP code presented on conferences. Even though I have some FP background, I couldn’t understand the last presentation about FP and Kotlin that I attended, and the code that was presented there is just a maintenance nightmare IMHO.

      The maintenance story is way too early to be analyzed objectively. Some devs say subjectively that Kotlin code will be easier to maintain. I, subjectively, can’t see this happen in the nearest future. As I said before, it will take some time until the community will develop understanding of Kotlins strengths and weaknesses, and will capture this understanding into a set of best practices. Until then I expect to see a lot of hardly maintainable Kotlin code to be written. Time will tell…

      The impact of Kotlin and Swift similarity is very interesting topic. Unfortunately, I don’t have any iOS experience, therefore I can’t really jump into it, but do feel free to expand on it if you have some specific thoughts in this context.

      Support of newer Java versions is very interesting topic that I might touch upon in the next articles, but why do you bring it up? I personally don’t find lack of Java 8 support very restricting. In fact, when developing backend, I’m free to use all Java 8’s goodies, and the only ones that I actually use are lambdas and time. Lambdas already natively supported on Android and time was adapted by Jake Warthon (who would guess that, right?).

      The most of the above are my subjective opinions, therefore they do not relate directly to the article itself.

      As I said, you are more than welcome to change any of the assumptions or the techniques that I used in the article and share your own results with us.

      Reply

25. You can’t compare two languages without actually going into the language details, this is just wrong.

    Also, you should take into account that developers (most of the time) do enjoy learning new languages (if they good look to them). Developers (at least good developers) do not want to work always with the same languages and same frameworks. If they are forced to do so they usually leave after some time. Productivity may even increase despite the time taken into learning (because of motivation) That doesn’t mean that you have to change language for the sake of changing, but in this case it can be a good fit for something new without major risks.

    Reply

26. The most hilarious part of this article and the comments is that it is in defense of Java!! Which made wild claims about its superiority to first C++ and then CORBA and all other enterprise object models when it rolled out EJBs, and it did so with ZERO metrics studies. Irony overload.. (that the author clearly does not get).

    But most of this is the same pablum over and over ‘if you like Kotlin that’s your opinion..’

    Yet when coroutines comes up he says ‘I don’t know why I would use it instead of thread pools I am used to.’ Ok, let me decode that statement for the author: I was too lazy to read a single thing about coroutines, but I am willing to spend seemingly an infinite amount of time supporting my baseless opinions. That’s about all you need to know about what you can get from this well.

    Reply

    • Hi Rob,

      I see you did not understand the article, its conclusions and the motivation behind it.

      I honestly don’t understand how it is possible to be “in defense” of a programming language? For me, programming languages are just tools. There are many different kinds of tasks, some of which require different tools. I would not write a script in Java. I would not write a comprehensive software in Perl (even though some people do and it works fine for them).

      However, as with any other tool, there are many alternatives of different quality, and the longer one uses specific programming language, the better he/she becomes at it.

      The point of this article is not to “defend” Java, but to show the factors that should be taken into account when evaluating Kotlin as a replacement. This is purely professional discussion of two alternative tools, and I don’t understand why you take it personally.

      As for subroutines you’re completely wrong.

      I’m following subroutines development very closely because, at some point, I expect to be asked to come and debug a huge pile of buggy concurrent code that uses them. When I say “I don’t know why I would use them” I’m not saying that I don’t want to learn about subroutines, but that I learned a whole lot about them and still can’t see a general valid use case for their introduction.

      But I might be mistaken.

      Therefore, please share your understanding with us: except for in highly concurrent I/O bounded parts of the system (which is a small niche), where would you use subroutines and why?

      Reply

      • The question was actually about “coroutines” not “subroutines”.

        Reply

        • Hey,
          You are right. Even though I used “subroutines” in the reply, it is clearly about coroutines 😉

          Reply

27. Why is “the whole story” only about Android? Kotlin enables same project crosscompilation to all platforms in a much more straightforward way than any tooling I’ve seen in Java, and from personal experience I can now start a new project and have something up and running to show in a couple of days instead of a week. Kotlin is really a godsend for us developers coming from C/C++ and Java.

    Things that save me time;
    – It literally takes less than half the lines of codes to implement tests, and the tests are so much more concise understandable. Writing tests are a huge time factor for me.
    – You can adapt a thirdparty API to your project without the need to try to break it down through reflection using aliases, extensions and so on. This adds even more timesaving to writing tests.
    – Gradle with kotlin DSL is amazing for managing the project build and deployment, it really saves a lot of brainpain and especially downtime. (This even makes Kotlin save you time and effort when programming in other languages)
    – Kotlin scripting saves you from having to create whole temporary projects, just put a few classes and functions in a file and test them out on the command line. This really saves time for every developer that knows how to do this.
    – I recently tried Kotlin JS, and it was almost effortless to set up compared to TypeScript, and even though we’re not comparing with anything else than Java, you’re never really getting a way with a project written in just one language nowadays, especially on Android and IOS. Oh, but hey, yeah, with Kotlin you actually might as it has all 3 domains covered: Jvm, Javascript/Web, Native!

    The question should not be so onesided, try turning it around, why would anyone developing in Kotlin switch to Java? What are the added costs of learning Java while rewriting the code previously written in Kotlin. And then go back again, what would be the added cost of taking previously written Java code and convert it to Kotlin. It won’t take much time before any decent sized java project will need to use code written in Kotlin too, and what is less effort? Using Java with Kotlin, or using Kotlin with Java?

    When comparing 2 different things, can we at least try to see it both ways.

    That gives a much better perspective than only trying to find what possibly could be wrong with one of the things compared to the other as in this article.

    Reply

    • Hello T Karlsson,

      Thank you for your comment. This is probably the best and the most though provoking criticism that I received.

      Allow me to share my thoughts on the points you raised.

      – This post is about a migration from Java to Kotlin, regardless of the platform or framework used. Therefore, it is not specifically about Android.

      – I don’t see how Kotlin can save half the lines in the test code. Either you use JUnit, or Spok, or any other testing framework – the code is relatively the same. I recently published a video tutorial on TDD, and now I tried to understand what would change if I would use Kotlin. Almost nothing. Am I missing something? Maybe there is some special testing technique for Kotlin which is no possible to do in Java?

      – Not sure what you mean by “adapt a third-party API to your project without the need to try to break it down through reflection using aliases, extensions and so on”. I usually wrap third party APIs into my own classes in order to remove dependency on third party stuff and “translate” third party language into my apps domain language.

      – I did not try Gradle with Kotlin DSL, but it is not something related to Java, right?

      – I did not try Kotlin scripting, but it sounds like a cool thing. Honestly, I don’t find it time consuming to open Emacs, type some Java and then javac and java the result, but yeah – interpreted languages are much better at quick prototyping. However, I think that this is more of a niche use.

      – I’m eagerly waiting for a proper Kotlin frontend framework. Something along the lines of Ember and Angular, but written in a proper object-oriented language. Will grab it with both hands, and, maybe, even contribute. But this is also not directly related to Java.

      As for whether we should look at it from Kotlin to Java point of view. You can use the assumptions and the techniques used in this post in reverse order and estimate how a group of Kotlin devs will be affected by transition to Java. However, this will be a purely theoretical experiment because, even if Kotlin will turn out to be yet another “better Java” that will die in several years, such transition will only happen several years from now.

      Kotlin and Java do not have the same starting point, and this important fact often overlooked by developers who want to use Kotlin in their projects. Java is vastly more popular, familiar and stable. Java is taught in universities. There are best practices for writing Java code, and good books written specifically about Java.

      Kotlin has almost nothing of what Java ecosystem already have. Yes, it is compatible, and, maybe, even slightly better in some aspects (while inevitably worse in others), but the fact remains – Kotlin is the new guy in town, and a migration to Kotlin is a big risk.

      What do you think about the above thoughts of mine?

      Reply

      • Thank you for your thoughtful answer!

        I’m sorry in advance, this turned out to be a long one and I don’t have any TL;DR;. It;s all written with a light mind, and not nearly as provocative as it might seem, please keep that in mind. Kotlin

        As for where my heart lives, it lives with C++.. I can program forever in it and not get anything done but unnecessary but creative code. Luckily we have more straight forward languages though, bringing me back to earth to actually get something finished once in a while. =)

        And a couple of questions back to you, Vasiliy, that I would like to be enlightened about:

        “Kotlin has almost nothing of what Java ecosystem already have”
        I would like to know what in Java’s ecosystem can’t be used in Kotlin, if anything?

        “(while inevitably worse in others)”
        This feels like truthism, can you mention at least some aspect that is worse in your point of view, so that we at least know why you don’t like promoting Kotlin or think Kotlin is a risk to use?

        “Java is taught in universities”
        That’s good, as well as C#/C++/Scala/HTML/Javascript/Basic/SQL/Matlab/Python/ObjectiveC as so on depending on the Where and the What. You don’t learn to be very good in a computer language in the university though, you get the basics in the context of your studies so that you can practice on that or any other languages for years to come. I bet Kotlin will be (or even is being) taught at places too, especially when it comes to android development.

        “Kotlin and Java do not have the same starting point, and this important fact often overlooked by developers who want to use Kotlin in their projects.”
        I really agree with this!
        Although for young people coming into functional style languages to begin with, Kotlin is a natural starting point when making apps for mobile devices and the web as they really don’t need the detour around Java country then, and the absolute alternative to Swift, Go and modern versions of C#.

        About the title, it clearly puts Kotlin vs Java at opposite sides, to be compared. That is the mindset you enter with as you’re reading the content of the article. I think the whole story part is about to come in the next article. Your writing is really good and I can understand where you come from in your assessments, and that what I’ve said is more about the context than the content of article. I can discuss a lot if it’s worth adding a perspective, but it doesn’t happen very often and in this case I wrote like.. A LOT.

        If this had been twitter before the 280 limit, this would’ve been 51 tweets.

        Thanks for reading!

        Reply

        • I think you misunderstood my previous reply a bit…

          “I would like to know what in Java’s ecosystem can’t be used in Kotlin, if anything” – the paragraph starting with “Kotlin and Java do not have the same starting point” in my previous reply lists parts of Java ecosystem that Kotlin lacks as of today. It includes maturity, best practices, books, etc.

          “This feels like truthism, can you mention at least some aspect that is worse in your point of view,” – you can read my replies to many other commenters where I shared parts of my subjective opinion. Things like stability and maturity, functional programming, coroutines were mentioned.

          By the way, it is not about “not promoting Kotlin” or “risk to use Kotlin” – it is about switching to a different language in general.

          Reply

          • The comment system cut out about half of my text, so it doesn’t make much sense. Thanks for reading and responding to the last half though.

28. mmm I think that this great opinion in general is a little oriented to save java, personally I think without many metrics or statistics or expert opinion support, I think that if a language saves me time to develop an application with a clear language and with less code lines that’s fine with me. and the time of adaptation and other things I will charge it to the greater time of adaptation that I had to invest for java.
    and I ask you a question, if a young person asks for your advice to learn kotlin or java, what would you advise and why?

    and I apologize for my bad I am South American

    Thank you

    Reply

    • Hello Ez,
      Thanks for your question.

      If you’re a backend developer, then I think that Java is the way to go. Whatever Kotlin fans say, the chances of Kotlin replacing Java for backend development are very low IMHO.

      If you’re Android developer and know neither of the languages, then I think that learning Kotlin is the better option right now. Not because it is better in any way (maybe it is, maybe it isn’t), but just because it looks like Kotlin will eventually become the standard language for Android. Keep in mind, though, that you’ll still need to learn Java in order to be able to read existing and new Java code.

      By the way, I don’t think that this post is “oriented to save java”. I don’t even understand what does it mean to “save” a programming language.

      All I wanted to do is to show that there are more costs involving in switching from Java to Kotlin than most developers think about.

      Reply

29. the point is clear, thank you.
    In my opinion, I can say that all languages ​​have their maturation cycle, you must wait until your community grows, kotlin is a relatively new language, because the vast majority of them just take it into account from the moment that Google presents it and for It gives you a good backup.
    To start kotlin born with clear and concrete ideas and even more allows us to write less code and that for a programmer is important as is also the clear reading of the code.
    I think it is not the time to think about migrating applications from java to kotlin but that does not mean that we close the door to that idea, surely in a year more may be a migration or if it is not so at least face the new developments in Kotlin, everything will depend on how active your community is and the effort and hours that the creators of Kotlin should keep getting,
    that’s why I think we should wait a short time before making decisions.
    I personally like the simplicity of Kotlin and that this would have fixed the eternal java bugs.
    a greeting
    P.S. Sorry my bad english

    Reply

30. The comparison between natural languages and computer languages is interesting. One would assume that the same area of the brain is used for both.

    At school, specifically secondary education, I’ve had formal language education in Dutch (6 years), English (6), German (5), French (4), Latin (2) and Greek (1). And because I’m good at pattern matching, I can look at Spanish, Italian, Portuguese, Danish, Norwegian and Swedish, and sort of figure out what’s going on, especially within a certain domain (let’s say, football).

    As for computer languages, I started with BASIC and Z80 assembler in the early 1980s, and moved through both major and obscure languages, before settling on Java. I’ve seen and written a lot; over the past 20 years, mostly C, Perl and Java.

    For me, the negatives of Java are obvious, but usually boil down to one and the same thing: you need to write, or generate, an awful lot of boilerplate code. It’s therefore that I’m investigating how Java could be evolved –I’m carefully avoiding the phrase “improved”– and as such, sooner or later I had to run into Groovy, Scala, and Kotlin.

    It’s remarkably difficult to find any articles that offer a level-headed, objective overview of both the advantages and disadvantages of Kotlin (or Scala, for that matter). The vast majority are less than 10 lines of code, showing some edge case where you need fewer code in Kotlin than in Java.

    Guess what: I don’t get paid to write “Hello world!”, or finding if a number is odd or even.

    That Kotlin would be more readable that Java is indeed subjective; I personally find it less readable. What does a colon after a class definition mean? With “extends” and “implements”, there’s no such confusion. Yes, you have to type slightly more: probably “” instead of “”. But if this drives up your productivity by more than a fraction of a percent, you don’t spend nearly enough time thinking about and designing your application.

    Oh, you don’t have to type semicolons. The use of semicolons doesn’t appears to have harmed the popularity of C, C++, C#, Perl, or Java, has it? And I happen to like context-free grammars.

    Sure, given enough time, you can learn to read anything. When watching “The Terminator”, I looked at the hex dump scrolling across the screen and recognised it as 6502 machine code. A friend of mine went a step further and recognised ROM routines of the Commodore 64. But one cannot equate “I learned to read Kotlin” with “Kotlin is easy to read”.

    I’ve finally managed to track down some real-world Kotlin code, and from what I can tell, it’s not at all shorter or more concise than Java 8 with lambdas and the stream API. Maybe that’s relevant if you develop on Android, but I don’t. And I don’t trust Google not to have some hidden agenda towards Oracle in supporting Kotlin.

    This is really my biggest beef with developments like Kotlin. It’s developer-driven, but what drives the adaptation of a new language is not developers, but the companies that employ these developers. Companies can ill afford to waste resources on all sorts of adventures with no proven (please note, PROVEN) business benefit.

    Sure, Java could do with improvements. In my opinion, the best attempt at creating a better Java is C#, but that language is again too much developer-driven, and introduced as many new problems as it solved.

    Java isn’t perfect, far from it, but it drives an enormous amount of business, and that’s what counts.

    Reply

    • What I forgot to mention: I want to know the disadvantages of anything. I’m not interested in the advantages. It’s like an honest critique: if nobody tells you what you’re doing wrong, you’ll never learn anything new.

      This article doesn’t cover Kotlin’s disadvantages either, but at least it’s not the typical “Kotlin is the best thing since sliced bread” post.

      Reply

      • Hello Peter, thanks for your comment.
        I very much enjoyed reading your thoughts and criticism of my article.
        Since you mentioned companies agenda, you might be interested in reading the subsequent post about Why JetBrains Invented and Promotes Kotlin. I also plan to analyze the entire situation from Google’s perspective in the future. I almost completed the required research, and plan to write the article when I have 2-3 spare days in my schedule.

        Reply

31. Just thought I’d throw this in here, aspect of the argument was that if Uncle Bob says so then it gives more weight to the argument. I certainly respect his opinion so I went to read his article and he indeed believes these new languages are a waste, the main reason he says they are a waste is because every new languages throws away the old IDE functionality. He specifically talks about Intellij and how good it is, well all the java functionality of Intellij works for kotlin too so I’m not sure that specific article from him would denounce kotlin as his reason of even if the languages are better it’s not worth losing tooling doesn’t really apply to kotlin.

    Reply

    • Hey Jacob,
      I would like to know what Uncle Bob really thinks about Kotlin, but you are most certainly right. However, note that I did try to account for the transfer of tools knowledge and maturity in my estimations.

      Reply

32. You forgot to mention some **very important** things like developer happiness, and the Dead Sea Effect. You only analyzed a tiny part of the whole spectrum of costs. For example, a lot of Java developers who care to learn new languages are also more skillful than other “hardcore” Java devs who don’t really care. If you have a project where you allow devs to user Kotlin you have a comparative advantage over other shops who only use Java. This means that if you need 5 more people for your project you can hire more easily than the other Java shop which means that you’ll have human capital sooner and the talent pool will be better. This is just an example but there are many more which I will not go into detail in this comment. You should have performed an analysis which takes into account every major factor not just the learning experience.

    Reply

    • Hello Adam,
      Thanks for sharing your opinion.
      I completely disagree with all your premises. Especially the idea that “developer happiness” is derived from programming languages and that “Java developers who care to learn new languages are also more skillful than other hardcore Java devs”.
      I’m sure that you don’t have any stats to back either of these statements and they are your personal anecdotal experience at best.
      My personal anecdotal experience says that developers become happy when they feel that they work on important stuff and are treated properly by the employer. If developers need a new programming language for happiness, that’s a huge warning sign.
      I’m sure that there are more factors that I missed in my analysis. However, I don’t think that the ideas that you listed should be taken into account because, AFAIK, there is no data to back them up and my personal experience says that they are incorrect.

      Reply

33. I also disagree with all your premises. First of all, you admittedly made up numbers but it is never mentioned that you actually made some work with Kotlin which means that you don’t have stats to back up your claims. The numbers you present are some general stats which may r may not apply to most situations. They fly in the face of empirical evidence I have. I’ve been part of 3 successful projects in the last 3 years written in Kotlin and I have countless Scrum boards to back that up which show 10-20% speedup in team velocity compared to Java.

    Another problem is that even if your numbers are applicable it is only true in general and not on a case-by-case basis. For example, you claim that according to the release notes there were breaking changes. If you read through the notes it turns out that all those problems were Android related. So when we look at PVOL these Android problems are responsible for the 11% loss (0.89 platform volatility). I’ve been using Kotlin on the backend and I experienced none of these problems (nor any of my current or former team members). So you can’t really talk about Kotlin in general, you have to differentiate “plain” Kotlin and Kotlin on Android.

    “Instability” is indeed an advantage. For example, since they added data classes my code became much simpler. In Java, these changes are much slower since they have to maintain backward compatibility. You never mention the force multiplier of this nor the force multiplier of extension functions and other language features. For example with extension functions, I can augment even JDK classes. There are a lot of problems which can be fixed by this simple feature and which can’t be done in Java which is a huge net loss of developer time.

    Another problem is that you claim that there is “ramp up” and “skill loss”. You basically build a strawman where every negative aspect is present:

    – Inexperienced Java devs who know nothing about Kotlin
    – Android platform which is much more problematic than a “plain” Kotlin backend
    – A project rewrite

    What if you start a project (no rewrite) with devs who already know Kotlin, and your project is a “plain” backend project? All your negative multipliers go away.

    Lastly, the design, debugging, testing claim is simply false in a lot of cases since they are only applicable on a project rewrite, or a new project, but not in a project which you are just maintaining / improving.

    Reply

    • Adam,
      If you read my post carefully, you’ll notice that it is written in the context of a specific situation (project, team, etc.). Your arguments about e.g. devs who already know Kotlin are irrelevant here. It might be true that if you replace Java devs with devs who have the same amount of experience with Kotlin then some of the factors don’t apply, but that’s a different situation. As of today, you have many experienced Java devs and very few devs who know Kotlin beyond basics.
      Let me propose the following: if you’ve been on “3 successful projects in the last 3 years written in Kotlin” and you indeed have “countless Scrum boards to back that up which show 10-20% speedup in team velocity compared to Java”, then, instead of arguing with me, just write a post about that.
      I’m eagerly waiting for any quantitative information to be presented in respect to Java to Kotlin migration. If you have this info, then I don’t understand why you’re arguing with me over my post instead of sharing your stats and seeing what the community has to say…

      Reply

34. Great post. Thank you for giving me a clearer vision that to stop looking on Language comparison post.

    Reply

35. I think there’s one thing you’re overlooking in your article: the hype effect that a new language can have on developers. Developers are like everyone else, they like a new toy, and that makes them enthusiastic and motivated, whether for good or bad reason is irrelevant. So you’re certainly right, there will be a cost to migrating to Kotlin, but if the developers can convince their management that they must absolutely migrate because that’s the future, then they will, and no amount of reasoned cautioning can prevent that.
    So you get to choose: ride the wave, or not.
    As a solace though, think that in 5 or 10 years, some other new toy will come, and that will be the new hype, and among those guys that advocated Kotlin, there will a Vasiliy that will write an article warning about switching to that shiny new toy prematurely, and advocating considering the advantages of a using a proven technology like Kotlin that has evolved so much over the past years to meet the demands of developers (because yeah, it had lots of flaws at the beginning, but not so much nowadays).
    The wheel keeps on turning, and it’s bigger than any of us.

    Reply

    • Hey Guy,
      Thanks for your insights. I agree on almost all the points, especially the future version of Vasiliy 😉
      However, I don’t think that it’s reasonable to say “that’s the way things are” and just blindly accept the transition to Kotlin. This specific post is about one year old, but IMHO, even today it’s still a bad idea to migrate existing codebase to Kotlin.
      You might find my latest post interesting in this regard. Note that even a year after I wrote this (a bit prophetic) post, there is still build times issues with Kotlin. This is exactly what I predicted – it will take a considerable time until Kotlin tooling will catch up to Java standards. Therefore, while it might be the case that Kotlin will completely replace Java in Android, we still need to carefully plan the migration.
      By the way, I universally find that there are much better ways to get developers excited than just new programming languages. IMHO, it’s a curse of our profession that we find joy and pride in associating with new and shiny things.

      Reply

      • Yep, I read your other post and yes, you were right of course. History repeats itself: Apple made the same move by introducing Swift as a replacement for Objective-C and I had that same reaction (duh, what’s wrong with Obj-C?). That was Swift 2 back then and we’re now at Swift 4 and it is still lacking in some respect compared to Obj-C (@synchronized anyone?), but the point is, you can’t get where it’s really better than the previous technology without having loads of people embracing it with blind enthusiasm and feeding the feedback loop (and paying the price on the way).
        So you can warn to you heart’s content, you will be right, but you will be fighting wind-mills and facing flame wars.

        Reply

36. I wonder how often a new language is worth adopting at inception. Almost never. But, some companies still blaze the trail and eventually the language grows successfully and gains marketshare. Or it dies out of course. I’m talking popular languages.

    It’s kind of like IT in general. Studies have shown that IT has not benefited companies at all. Still all those companies that did not implement a robust IT strategy are all out of business now.

    Reply

37. According to this “don’t change anything without hard data” line of thinking, Apple wouldn’t have switched from Objective-C to Swift. But there is such a thing as computer science, we have an accumulated body of knowledge about what things are good and bad in computer languages, and sometimes we have to move because of that body of knowledge.

    Reply

    • Hello Chris,
      I’m not sure what you tried to say.
      As far as I know, there is no “accumulated body of knowledge about what things are good and bad in computer languages”, but I’m open to be corrected. What kind of “body of knowledge” are you talking about and where can I find it?

      Reply

38. One aspect not overly covered in the article (great read, loved it) and comments is maintenance as in getting new people (as the old ones leave) to maintain your ageing Kotlin code base and before that recruiting new Kotlin proficient developers to create that code base too. Also the risk of Kotlin not making it to the big league in which case what becomes of your investment in learning it and your investment in your code base…

    Reply

    • Hey Kusti,
      In my opinion, the point you raised is very important. Kotlin will most probably become the dominant way to write Android apps in a couple of years, but if it won’t become mainstream outside of Android, then Android engineers will actually lose from their market value if they don’t know Java.
      I didn’t address this point in the article because I don’t know how to quantify it. Thanks for bringing it up nonetheless.

      Reply

39. The essay pretends to be objective. Indeed it presents some formulas. Why those and not other formulas? Why this model is good? How do you know that it doesn’t have gaps? It is science? Is it just me that I have problems following the argument? How come this mix of formulas, numbers, selective citations can be considered objective? Is not engineering either. It feels like chained associations of ideas. And any kind of counterargument is either subjective or outside of discussion because doesn’t accept the same premises, model and authorities.

    For example using “statistical data” from a time when waterfall was considered a methodology is perplexing. Using data from a period when lisp/functional paradigm was ignored in mainstream projects and when pointer arithmetic was still considered normal hardly can convince me that the computation model is realistic and doesn’t have gaps. Besides, in an agile project the effort spent on inception, planning, designing is minimal. The effort on debugging is also reduced since the bugs are new and shiny added in the last sprint. All these many gaps, outdated assumptions and selective bias are the reason that your conclusions are contradicting personal experience of the other commentors.

    Anyway there is a strategic move that a company must make independent of the transition costs. Java is under a tight control now and the community is wondering what are the safe escapes related to the language and jvm. With this move Google can secure the entire stack. And Google has a better relationship with the community like for always.

    Reply

    • Hi Costin,
      Thanks for your comment.
      If you read the subsequent posts, you’ll understand that whether “Google can secure the entire stack” is questionable. In addition, you’ll see that Google is the only reason the stack need to be “secured” in the first place – they knowingly broke the law and undermined the entire ecosystem out of what appears to be a pure greed.
      As for relationship with the community – Google indeed excels at PR.

      Reply

40. Interesting to read to discover others point of view. But in my “subjective” opinion very simplistic, and even if the author tried to be objective he didn’t. The sad part is that this article may mislead some people (like managers) . I hope that at least the author tried Kotlin in production before…

    Reply

    • Hello Mouna,
      Thanks for your comment.
      Please note that I wrote this article two years ago. At the time it was very controversial, but today we already know that my preditctions and warnings were more than appropriate. If anything, I underestimated the issues that Kotlin brought into Android world.
      For example, Uber’s and OkHttp’s benchmarks show that Kotlin compilation is up to 4x slower than Java. This limitation alone most probably negated any other potential benefit that Kotlin might’ve brought. Projects which adopted Kotlin probably paid a huge cumulative productivity tax in form of developers waiting for builds longer. And that’s just one issue from a whole set of issues.
      Therefore, if any manager indeed delayed Kotlin adoption after reading this article two years ago, they can rightfully pat themselves on the shoulder today.

      Reply