kotlin_vs_java

Kotlin:

Kotlin is a relatively new JVM language that has been in active development by JetBrains since 2011.

It has seen a growing interest in Android community over the past few years, and eventually became the hottest topic in Android development after Google IO 2017, where an official support for Kotlin on Android was announced.

Unfortunately, even though many articles about Kotlin were published, there is not much objective information available, and many developers still contemplate whether a migration to Kotlin is the way to go.

In the remaining of this post I will attempt to provide a more complete list of considerations that should be taken into account when evaluating Kotlin as a replacement for Java.

Subjective comparison of Kotlin to Java:

Statements like “Kotlin is better than Java”, “Kotlin is more readable than Java”, “Kotlin is faster to develop with than Java”, while not supported by relevant and accurate data, all fall into category of subjective opinions.

Subjective opinions form when individual developers make one or more subjective judgements about subjects related to Kotlin or Java.

There are several issues associated with subjective judgement of developers:

  1. There are no quantitative metrics associated with subjective judgement.
  2. Subjective judgement is extremely biased.
  3. The biases of subjective judgement can differ substantially between developers.

Since there are no metrics associated with subjective judgements, opinions that were built upon these judgements are just reflections of developers’ pre-existing biases. Different developers might have vastly different biases, therefore the fact that some developers consider Kotlin a good (or bad) replacement for Java does not necessarily mean that other developers agree.

Furthermore, since there are no objective metrics, subjective disagreements can’t be resolved in objective ways, which often leads to so called “flame wars”.

Subjective judgement fallacy:

In order to demonstrate how subjective judgements can be misleading, let’s scrutinize one very common subjective opinion:

Kotlin is more readable than JavaCountless articles on the web

Theoretically, an experiment that attempts to measure readability differences between Kotlin and Java can be designed, but I’m not aware of any that was actually carried out. Therefore, as of today, this opinion is not backed by any data.

One aspect that many developers who praise Kotlin associate with readability is language’s syntax. The reasoning goes like this:

Kotlin has a better syntax, therefore it is more readableCountless articles on the web

The part about better syntax is another subjective judgement which can be debated by itself, but let’s assume for the sake of the argument that Kotlin’s syntax is indeed better. Does this imply that Kotlin is more readable?

In order to observe the effect of syntax on readability please read this “text”:

hard_to_read_text

This “text” was hard to digest initially, but, gradually, became much easier to read. If you read it another two or three times, you will stop noticing that it is composed of a non-standard alphabet at all. Substitution of alphabet is not exactly a syntactic change, but it does demonstrate that external appearance is rarely a barrier to readability for a proficient reader.

We can extend this example to natural languages too. I know 3 languages which differ substantially from one another. Even though the languages are very different, I find it difficult to read texts in any of these languages only when I don’t understand the words that are being used. Whenever the text consists of words that I recognize and the context is familiar – I have no trouble reading it regardless of the language used.

Therefore, for me, the choice of a language does not affect readability, as long as the content and the context are understandable.

The same applies to programming languages.

When we begin using a new language we have a hard time understanding the source code and need to actively interpret each syntactic construct. However, as we read and write more code using a specific language, we gradually get accustomed to that language’s syntax, and, at some point, stop noticing the syntactic constructs at all.

I myself experienced this effect in handful of languages: Verilog, Bash, Perl, Tcl, Lisp, Java.

Based on the experience with the above languages I can tell you this: if one can get accustomed and stop noticing the parentheses in Lisp code, there is absolutely nothing in Kotlin’s syntax that can have a non-negligible effect on readability as compared to Java, even if it is “better”.

While we are on this subject, let me share with you my own subjective judgement about the factors that affect the readability of the source code.

Having read code written by other developers in many languages (the above list contains just the languages I was proficient with at some point; the list of all languages I used is longer), I made the following observation: developers who write readable and understandable code in one language, usually write readable and understandable code in other languages too.

Therefore, in my empiric subjective judgement, readability of the source code is independent of the choice of the language, and only depends on the skill of the author of the code and the skill of the reader (with the skill of the author being much more important).

If you still think that subjective opinions can be representative, then, at least, read and take into consideration the opinion of Robert “Uncle Bob” Martin expressed in this blog post.

Objective comparison of Kotlin to Java:

Contrary to subjective comparison, objective comparison uses quantitative metrics in order to either measure or estimate the real advantages of Kotlin over Java.

The idea of having a set of criteria that will objectively show whether one programming language is better than the other is very compelling, but there is one problem: as far as I know, there are no universal objective metrics associated with programming languages.

Given the fact that we can’t perform precise direct comparison, can we compare Kotlin and Java objectively at all? Yes! We can still estimate the magnitude of positive and negative effects that will come into play upon switching from Java to Kotlin, and then compare the outcomes and discuss their implications.

In order to estimate the best possible outcome for Kotlin, we will make the following assumptions:

  1. Developers can switch to Kotlin instantly
  2. Developers do not loose skill upon switching to Kotlin (e.g. developers with 2 years of Java experience magically gain 2 years of Kotlin experience)
  3. Kotlin is as stable as Java
  4. Tools for Kotlin are as mature as tools for Java

In practice, none of the above assumptions are justified, but it will be illustrative to have an idealistic figure to start with. Then, we will drop these assumptions and discuss the impact of the effects that occur in real world.

Estimation of the best case scenario for Kotlin:

Following the pattern proposed by Steve McConnell in his Code Complete book, we can see the software construction activity as being split into three sub-activities: detailed design, coding and debugging, developer testing.

Kotlin will have no effect on detailed design sub-activity (which is generally independent of the choice of a specific object-oriented programming language), therefore this part will require the same effort for both Kotlin and Java.

To my best knowledge, Kotlin has nothing revolutionary to propose in developer testing sub-activity either. Therefore, the effort required for developer testing will be the same too.

This leaves us with coding and debugging sub-activity.

How much effort can we spare on coding and debugging if we use Kotlin instead of Java? This is a hard question to answer and the number will vary greatly between developers (with some developers being more productive with Java). However, since we are looking for best case estimate, we can just assume that switching from Java to Kotlin will improve the productivity of developers during coding and debugging by 10% on average.

The improvement in productivity of 10% is astonishingly unrealistic number. It would be unrealistic even if we would type all the code by hand in a text editor. Given the functionality of today’s IDEs, this number becomes astronomically unrealistic. Given the fact that some developers will be more productive with Java, this number is just nonsense.

I don’t mind to use such an unrealistically favorable for Kotlin estimate because I know that whatever unrealistically positive effects we will get as a result of this estimate, these positive effects will be swamped by the negative effects introduced once we drop some of our “idealistic assumptions”.

So, 10% improvement in coding and debugging – how much faster will we deliver new products to our users?

Take a look at this chart from Code Complete that shows the proportion of various activities on software projects:

software_poject_activities_proportion
Figure 27-3 Construction activities dominate small projects. Larger projects require more architecture, integration work, and system testing to succeed. Requirements work is not shown on this diagram because requirements effort is not as directly a function of program size as other activities are (Albrecht 1979; Glass 1982; Boehm, Gray, and Seewaldt 1984; Boddie 1987; Card 1987; McGarry, Waligora, and McDermott 1989; Brooks 1995; Jones 1998; Jones 2000; Boehm et al. 2000).
Code Complete, 2nd edition

According to this chart from Code Complete, for a non-trivial software project (larger than 10k lines of code), coding and debugging takes less than 20% of the total project’s effort.

Therefore, our assumption of 10% increase in productivity during coding and debugging leads to reduction of less than 2% in total effort required in order to complete a non-trivial software project.

For example, on a project that requires 5 man-years to complete (which is relatively large project for Android), 2% of total effort accounts to:

5 man-years * 12 * 4 * 5 * 0.02 = 24 (man-days)

If we could indeed reduce the project’s effort by 24 man-days, then it would be a very good argument in favor of switching from Java to Kotlin. However, we shall remember that the above positive estimate is idealistic and was derived based on unrealistic assumptions.

Let’s see how this idealistic estimate compares to estimates of real-world effects that are inevitable upon switching to another programming language.

Developers ramp-up:

In order to perform the best case estimation we assumed that developers can switch from Java to Koltin instantly.

In practice, despite Kotlin being very similar to Java, developers will need to spend some time learning it, and then some more time in order to make adjustments to development practices and tools. Ramp-up time will be different between developers: some developers will be able to switch in 3-4 days, while others will need 10 days or more.

Let’s take an optimistic figure of 5 days as an average amount of time it takes a developer to switch from Java to Kotlin.

On a project that requires 5 man-years to complete, there will be 3-5 developers (optimal case). Average switching time of 5 days per developer on such a project will sum up to a total switching time of 15-25 man-days.

Looks like the effort reduction that could have been (optimistically) achieved by switching to Kotlin is comparable to the total effort required for performing the switch.

Developers skill loss:

Ability to work efficiently with a specific programming language is a skill.

We have already discussed one aspect of this skill (code readability), but there are many more. When switching from one language to another, some portion of the skill with the old programming language might apply to the new one, while the rest of the skill will be lost.

In order to assess the effect of programming language skill loss on the project’s effort we will be using “Language and Tools Experience” multiplier from Cocomo2 estimation model:

Language and Tool Experience (LTEX)
This is a measure of the level of programming language and software tool experience of the project team developing the software system or subsystem. Software development includes the use of tools that perform requirements and design representation and analysis, configuration management, document extraction, library management, program style and formatting, consistency checking, planning and control, etc. In addition to experience in the project’s programming language, experience on the project’s supporting tool set also affects development effort. A low rating is given for experience of less than 2 months. A very high rating is given for experience of 6 or more years, see Table 31.

language_tools_experience
Cocomo 2 Model Definition Manual

For example, let’s assume that we have a team of Java developers that have 1 year of language experience on average, and we want to migrate to Kotlin.

Since Kotlin is very similar to Java and is compatible with many Java tools, we can optimistically assume that after the initial ramp-up the developers will fall into the bucket of 6 months experience (instead of less than 2 months). Under this assumption, in order to estimate additional effort due to skill loss, the total nominal effort of the project should be multiplied by 1.09.

On a project that requires 5 man-years to complete using Java while staffed with developers that have 1 year of Java experience on average, the estimated total additional effort due to switching to Kotlin will be a whooping 108 man-days.

The additional effort due to skill loss is four times higher than the reduction of effort that could have been achieved by switching to Kotlin.

Language and tools stability and maturity:

There is a widespread claim that Kotlin is production ready language. These claims are probably justified because Kotlin is already being in use in some projects.

However, when compared to Java, Kotlin is unstable and young language.

Some developers think that Kotlin’s instability is an advantage – the language evolves and new features and improvements become available faster. In my opinion, this is a very simplistic view of this matter.

The following is the very first statement in Kotlin 1.1.4 release notes (the latest release as of this writing):

Fixes a major performance regression in the IntelliJ IDEA pluginKotlin 1.1.4 release notes

I don’t know what kind of regression is this and how many projects were affected, but my mind automatically translates the combination of words “major performance regression” into “many hours of wasted developers time”.

In addition, if you read through comments to release notes, you’ll notice that many people have troubles with migrations. One comment on release 1.1.2 even suggested that this “patch” release introduced breaking (non backward-compatible) changes.

In contrast, if you read through release notes of Oracle’s JDK8, you will observe much less drama. Most of the changes are related to security improvements.

So, when compared to Java, Kotlin is unstable and immature language – how this can affect the projects that migrate to Kotlin? In order to answer this question, we will use “Platform Volatility” effort multiplier from Cocomo 2 estimation model:

Platform Volatility (PVOL)
“Platform” is used here to mean the complex of hardware and software (OS, DBMS, etc.) the software product calls on to perform its tasks. If the software to be developed is an operating system then the platform is the computer hardware. If a database management system is to be developed then the platform is the hardware and the operating system. If a network text browser is to be developed then the platform is the network, computer hardware, the operating system, and the distributed information repositories. The platform includes any compilers or assemblers supporting the development of the software system. This rating ranges from low, where there is a major change every 12 months, to very high, where there is a major change every two weeks, see Table 25.

platform_volatility
Cocomo 2 Model Definition Manual

You might’ve noticed that programming languages do not appear explicitly in the description of this effort multiplier, but compilers and assemblers do. In my opinion, programming languages were not included explicitly because all the projects that Cocomo 2 was derived from used stable languages.

Since compilers and assemblers belong to this effort multiplier, we can extrapolate it to the programming language and the associated tools too.

On this scale of platform volatility, Java would score “very low”, while Kotlin is in the “low” range or higher. It is probably higher because it has inter-dependencies with other tools which increase the risk of compatibility issues.

Since the multiplier for “very low” platform volatility rating is not available, we need to estimate it.

Looking at the progression of multipliers from “very high” to “low” ratings, I think we can safely assume that the multiplier for “very low” rating is not higher than 0.82.

If we stick to these assumptions (which are favorable for Kotlin), then, on a project that requires 5 man-years of nominal effort to complete, using Kotlin will result in a total effort of 1044 man-days, whereas using Java will result in a total effort of 984 man-days.

Choosing to implement such a project with Kotlin instead of Java will add 60 man-days to the total effort.

The addition effort due to language and tools instability is more than twice higher than the reduction of effort that could have been achieved by switching to Kotlin.

Summing up all the factors:

The project that I chose to discuss as an example required a nominal effort of 5 man-years to complete.

According to our estimations above, if this project would be implemented in Java by developers who already have 1 year of Java experience on average, the total effort would be:

5 man-years * LTEX(Java) * PVOL(Java) = 984 (man-days)

If the same project would be implemented in Kotlin by developers who have very little or no experience with the language, the total effort would be:

5 man-years * LTEX(Kotlin) * PVOL(Kotlin) * 0.98 + T_ramp_up = 1115 + 5 * N_developers (man-days)

The total estimated additional effort due to choosing Kotlin over Java is 131 + 5 * N_developers (man-days).

A note about estimations:

Following our estimation discussion, we got a convenient single point values for efforts associated with Kotlin and Java.

In practice, however, single point values are not estimates at all – they are just guesses. A real estimate must always have an associated uncertainty. In other words – estimates express ranges of possibilities and not single point values.

We ended up using single point values instead of ranges because I converted all estimates to a single point values by choosing the most favorable value for Kotlin from the estimated range.

For example, when discussing the effect of Kotlin on coding and debugging activity, I chose the enormous 10% productivity increase value from a range of possibilities that I estimated to be [-5%, 10%]. In other case, when we discussed the average time it takes developers to switch to Kotlin, I chose the minimal 5 days value from a range that I estimated to be [5d, 21d].

In addition, we used the effort multipliers specified for Cocomo 2 estimation model. These multipliers are not universal truths and, in the most general case, should probably also have associated uncertainty. I attempted to account for this uncertainty by assigning to Kotlin rating levels that are more favorable than what I actually think it deserves.

Needless to say that the single point values that we got can’t be precisely correct. In order to see a more complete estimation picture we could perform Monte Carlo simulation using the actual estimates. This technique would allow us to observer the distribution of possible outcomes and understand what kind of outcome is the most probable.

Keep in mind that since we collapsed the estimates into single point values that are most favorable for Kotlin, the other possible outcomes will show a greater overhead associated with switching to Kotlin. Therefore, the single point values that were stated in the previous section are probably the most favorable for Kotlin from the entire set of possible outcomes.

Conclusion:

We opened this post by showing how subjective judgements of developers can be misleading in comparison of programming languages.

Then we discussed the difficulties associated with objective comparison of programming languages, and performed a series of estimates in order to understand how Kotlin stacks against Java in context of total effort required for completion of a software project. While performing the estimates, we consistently used the values from an estimated range that are most favorable for Kotlin.

From our analysis it looks like switching from Java to Kotlin will result in increased total effort required for completion of software projects.

More effort means that the companies that switch to Kotlin will need to spend more money in order to get the same functionality, and the users will need to wait longer for the products.

To some developers, this might be a very surprising and not an easy conclusion to accept.

At the end of a day, Google did decide to support Kotlin for Android development. This probably required a considerable investment on Google’s side – is it possible that no one at Google could perform a similar analysis in order to understand the downsides of switching to a new language?

I think that Googlers are very smart people, and I believe that they did perform a very deep analysis before a decision to support Kotlin was made.

In the next post we will discuss why would Google invest in support for Kotlin, while it should be clear from a quick analysis that it will not be beneficial to Android community.

Please leave your comments and questions below, and consider subscribing to our newsletter if you liked this post.

This article has 57 comments

  1. Dragos Reply

    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.

    • Vasiliy 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.

  2. Evgeny Reply

    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.

    • Vasiliy 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.

      • Evgeny 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.

        • Vasiliy 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)

  3. Jarek Reply

    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).

    • Vasiliy 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).

      • Jarek 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.

        • Vasiliy Reply

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

          • Kevin

            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.

          • Vasiliy

            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. Serandel Reply

    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.

    • Vasiliy 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.

      • Serandel 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? 🙂

        • Vasiliy 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.

  5. Martin Reply

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

  6. Janis Reply

    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 🙂

    • Vasiliy 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.

  7. Dmitry Shultz Reply

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

    Are you aware of coroutines support in Kotlin?

    • Vasiliy 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.

  8. MisterJay Reply

    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.

    • Vasiliy 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.

  9. Adam Arold Reply

    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.

    • Vasiliy 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).

      • Adam Arold 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.

        • Vasiliy 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.

          • Adam Arold

            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.

          • Vasiliy

            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. Daniel Reply

    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.

    • Vasiliy 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.

  11. Adam Reply

    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.

    • Vasiliy 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.

  12. Christopher Jenkins Reply

    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.

    • Vasiliy 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?

  13. Leonardo Silva Reply

    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

  14. Josh Swoyer Reply

    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.

    • Josh Swoyer 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.

      • Vasiliy 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.

  15. Jean-Michel Reply

    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.

    • Vasiliy 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? 😉

      • Jean-Michel 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.

  16. Janis Reply

    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.

    • Vasiliy Reply

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

  17. Earl Goodman Reply

    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.

    • Vasiliy 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.

  18. Adam Reply

    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.

  19. Kaloyan Reply

    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.

    • Vasiliy 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.

  20. cobolforever Reply

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

    • Vasiliy 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.

  21. JohnnyBeGood Reply

    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. 😉

  22. sagaxu Reply

    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?

    • Vasiliy 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.

  23. Aleksandar Radulovic Reply

    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.

    • Vasiliy 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.

Leave a Comment

Your email address will not be published. Required fields are marked *