When someone looks at the code Corda , it immediately draws attention to the fact that it is written in Kotlin - a new programming language from JetBrains that can be compiled under JVM and in jаvascript. It was an unusual choice, and in this article I want to share some of the reasons for this decision and the experience of our "year with Kotlin in production."
it is quite possible , the search for a person with serious experience in banking and lazy pure (pure) functional languages casually residing in London seemed risky. In addition, the very nature of the product implied that our "users" are actually developers of plug-ins and applications that use the platform, and there is no sense in requiring them to study completely new paradigms and tools. Our choice of language should not restrict users too much.
As a result, these requirements left us with Kotlin, Scala and Ceylon. These languages are quite similar and quite interesting. We chose Kotlin for the following reasons:
integration with Java
In particular, programs on Kotlin use an improved (compiler-enhanced) version of standard JDK collections, which, thus, provides no integration problems due to the use of other collections libraries. We distribute it everywhere and get collections
Java-libraries, so it's important that it does not cause problems.
From the Kotlin classes, the usual Java API looks like with the
methods. get /
is in accordance with the types. Special annotations or other actions are not required for this. Due to the fact that Corda provides a API intended for transparent use by Java developers, the API is a great advantage: from the usual code, an API is obtained which can not be distinguished from the Java API with only a few caveats (for example, the ability to intercept verifiable exceptions from Java requires explicit annotation of methods)
Inlining of small functions like
groupBy (instead of hoping that the JVM will do it itself) is executed by the compiler. Unfortunately, JIT's JIT compiler, although excellent overall, does not in all cases eliminate the overhead of the abundant use of higher-order functions. Using Kotlin this compensates, in addition, allowing you to control the execution of the program from within lambda functions (note: for example, Non-local Return). This is one of the little-known, but, at the same time, useful opportunities. Because we everywhere write code in such a functional style, then, if it was badly translated into machine code, we could create performance problems for ourselves.
Due to the fact that the code on Kotlin is translated into a fairly similar Java-code, almost all existing Java-oriented tools work from the box . This is not always true in the case of other languages. For example, Quasar hardly makes any code for Scala because it needs method annotations, and Scala translates lambdas into methods that can not be annotated. Kotlin lambdas are usually built in (see above), or can be annotated otherwise.
Excellent documentation and a tiny standard library make it very fast. We did not indicate in our vacancies the need for experience on Kotlin, and hired people without his knowledge giving on swinging 1-3 days after which a new member of the team was able to write an idiomatic code.
Based on the selection of candidates interviewed by us, IntelliJ is the most popular IDE (they had a free choice of tools). Among the post-Java languages, IntelliJ supports Kotlin the best.
I already had a satisfactory experience with him, and, therefore, I was sure that he would like the new colleagues as well.
If there was not Kotlin, we probably chose Scala: Kotlin is largely inspired by him and both are good languages.
Our year with Kotlin
What is it like - a year to work with a new language in the context of an enterprise application?
The most important was, no doubt, to hear from colleagues that they really like working with him. The programming language is a personal matter for everyone, and people usually have a certain opinion on this matter. If you, as the first task in your new job, ask someone to learn a new language and do not even warn about it in advance, there is always a risk that a colleague will just hate it and rather find it annoying, rather than increasing its productivity. But this is not the case.
Below are some of the problems that often pop up in the post-Java /C # environment of enterprise development, and that we ourselves have encountered:
- The code looks different depending on who wrote it. In general, not such a big problem. Unlike Go, which requires a certain style of decoration, Kotlin-code of different authors can look different. But IntelliJ has a formatting tool that provides unification of the code base style. It is more limited than for Java, but that's enough. A more subtle problem, especially with the code on Scala, is the confrontation between Java-OOP and Haskell-FP encoding style. Scala-code, which uses such libraries as scalaz, can be difficult to read for developers who expected to see improved Java. In this dispute, Kotlin rather firmly stands on the side of improved Java. And, although, functional programming, in a certain form, possibly and on Kotlin, the community (at least for now) has not split into camps. We had cases when the code was written as if it was Haskell, but it was worked on codereview.
- Libraries. In Corda, we use more than 50 open source libraries and there were no problems with one. We never wrote envelopes or layers of adapters. As assembly systems in projects on Kotlin, Maven or Gradle is usually used - there is not any official Kotlin specific replacement for these tools (although Gradle introduced Kotlin support as a new scripting language!).
- DSL and SQL. C # has LINQ, Java has JOOQ, and Kotlin has Exposed . This is one of the areas where Kotlin is somewhat weaker than its competitors - Exposed is an excellent example of using Kotlin's capabilities to build a DSL, but the library itself has an unstable API and is a secondary project. JOOQ, of course, can be used with Kotlin, and, looking back, it seems more preferable option.
- IDE /toolkit. Kotlin-plugin for IntelliJ, of course, is written by JetBrains and, on the whole, is magnificent. However, it is less sophisticated in comparison with Java support. New features of the editor, such as tooltip , should be manually ported to Kotlin, and support itself, as such, usually lags behind for much older Java plug-ins. We also noticed that the IDE plug-in often notifies about internal errors, although the frequency of IDE exceptions during the year has significantly decreased (and, it seems, they do not affect anything). The use of other tools also does not cause problems, because what is written for Java, usually, works from the box . An exception are the tools that work with the source code instead of bytecode, and which, obviously, can not be reused. With all this, the Kotlin compiler and the IDE plugin are not as debugged as in the case of Java even a year after the release of 1.0. Most likely you will never run into internal errors in
javac, but, although very rarely, we still meet them in Kotlin.
Recognition by users.
Users of Corda are, more often than not, large and conservative financial structures. Such companies prefer to use common, established languages. Kotlin, being neither the one nor the other, clearly caused some surprise at the time when we started. "Why Kotlin?" This is a question that, during the past year, has practically disappeared, because people looked closer and realized that this is not as risky as is usually the case with new programming languages. We also tried to facilitate the adoption by providing code samples demonstrating that building applications using the platform does not require knowledge of Kotlin. The results of this were not so successful - many developers, the first time working with Corda, still begin by getting to know Kotlin. It's not very clear whether this is the result of the fact that we have provided not enough Java-oriented examples of usage and documentation, or it's just a good excuse for learning a new classy tool. We, too, were helped by the increasing acceptance of Kotlin within large investment banks. Over the past year, we heard from several members of the consortium that their internal development teams began to seriously look at Kotlin for their own products: often stimulated by the availability of tools that convert Java to Kotlin, which provide significantly less painful integration into the existing code base.
The risk of using little-known languages is that they can stop developing, or have goals that are not consistent with the needs created around the product, the user community (for example, in the case of research languages, the main goal of developers is to create scientific articles). The main reason why we feel confident with Kotlin is that JetBrains is a stable, profitable company that has been on the market for more than 15 years. JetBrains quickly became
own tool introducing Kotlin into the code of the main products. Thus, the risk of termination of support is rather small. In addition, JetBrains is already a middle-aged company, and its target market (IDE and tools for developers) has ceased to be new or especially fashionable, which reduces the risk of a possible takeover of the company, which can lead to unpredictable strategic changes. And, despite the lack of a package of commercial support for Kotlin, in practice the team quickly fixes known problems. At the moment, JetBrains intend to release the next language update after a year from release 1.0. Such a release cycle is quite similar to the development cycle in a corporate environment.
We do not regret: the choice of a young language at the start of this project was at least a risk, but weighed. He did a good job for us and we would not change our choice.
It may be interesting
Situs QQ Online
Situs QQ Online