“Most likely, it will grow like a snowball” - Andrey Breslav and Anton Keks about Kotlin

During the year that has passed since the release of Kotlin 1.0, the language experienced breakthroughs on many fronts: from support in Gradle and Spring to the release of the book Kotlin in Action. The number of Kotlin lines on GitHub has more than quadrupled, exceeding 10 million. And now version 1.1 has been released, which adds a compilation to JavaScript, and this looks like a loud application for a new market share. Does this mean all that now the time of Kotlin has really come, and it is time for all of us to actively use the language in production?

Andrei Breslav (JetBrains) and Anton Keks (Codeborne) know a lot about Kotlin (and both will speak at the JPoint with reports about him), but look at it from different sides: while Anton is developing in this language, Andrei is working on the language itself . We decided that it was interesting to talk about the present and the future of Kotlin with both of them at once, getting a complete picture. Starting with questions about rapid growth, then we managed to discuss a lot more:
')

• Interaction with developers and the process of language evolution
• JS compilation, Kotlin Native project and multiplatform in general
• Imperfections
• Kotlin puzzle players
• Expectations and ambitions

JUG.ru: First, tell us exactly how you are connected with Kotlin.

Andrei abreslav Breslav: I have everything very simple, I head the whole project: both the whole language design, and the whole management.

Anton Keks: I did one project in production at Kotlin, another very large project I am now going to transfer to it slowly, and I transfer a lot of personal open-source projects from Java to Kotlin in order to get a better feel for the language.

The one that has already been done in production is an IDEA plugin, so it was easier to convince the customer to use Kotlin. I started doing it last year: as soon as I released 1.0, we immediately started writing on it.

As an experienced developer, my experience was very positive, and a less experienced developer in this project was hard to learn a new language. That is, for me it was more fun, but for another person it was more of an obstacle to doing work quickly. But it seems to me that we quickly became comfortable, and since that time I have become more fond of the language. Before that, I was a little skeptical, because it seemed to me that when Java 8 came out, it already covered many of the user cases. But it turned out that Kotlin is still much nicer than the eighth Java. Therefore, I am now trying to promote the language in those projects in which I participate.

JUG.ru: From the outside, it seems that 2016 was a breakthrough year for Kotlin - how do you see it?

Andrey: 2016 really was a breakthrough year, at least, because the release was released. Naturally, the community began to seriously consider the project, adoption began. We are very pleased with the dynamics that we see: Kotlin is used by large companies in serious projects; There are many educational materials from different people; people from the community write books that we ourselves have not sponsored, and they are popular.

It can be seen that, say, the Android developer community or Spring was very attentive to the emergence of Kotlin, people began to use. The next version of Spring will include some extensions on Kotlin, among Android developers it is just a very popular tool. That is, in both markets, on which we mainly counted, we have a very good result: server-side development is very cheerful, and Android development.

JUG.ru: The demand for a language is also determined by things like the number of vacancies - what about Kotlin?

Andrei: I saw quite a bit of Kotlinov vacancies, but there are more vacancies "need a Java developer and / or Kotlin". It is clear that if people have an actively developed project either on the backend or on Android, and some of the participants add Kotlin there, then vacancies become not only Java, but also Kotlin. If people are used to hiring enough serious specialists who can easily master the new cool technology, then for them this is not a barrier, and they calmly do it.

Anton: As an employer, I can still comment that the trend is full stack development, we have all full stack developers in our company, so hiring someone who knows only Kotlin or only Java is a bad idea. It is better to hire people who generally know how to program, understand how object-oriented programming works, how functional works. And then learning Kotlin's syntax is easy enough, especially if you have experience with Java on the JVM. Many people write to us in Ruby, some in Java, and for those who have seen both, it doesn't take long to start writing on Kotlin.

Andrei: I support Anton that it is better to hire good programmers, and for such people the language is not an obstacle in the main.

JUG.ru: Anton, what has changed for you as a developer for the year of your use?

Anton: When Kotlin 1.0 was released, it was raw - or at least IDE. IDEA is still very much inferior to the possibilities in Java. For example, there were a lot of bugs in the debugger, in the compiler we also met ... On the first project, we encountered quite a lot, especially there were many problems with the debagger. And if, in the case of Java, IDEA is cool with inspections, for example, she didn’t find the same flaws in Kotlin. But gradually it became much better.

I think that version 1.0 was a trigger for many, including for us, to start writing real projects, and thanks to this, we managed to sharpen things at a much faster pace. At the moment, there are almost no opportunities, which the IDE lacks in comparison with Java. In my opinion, support has become a very good level.

JUG.ru: And, for example, is the information you need easy enough to find? On the Stack Overflow responses for the tag "Kotlin" a couple of thousand, and for "Java" almost a million - it does not interfere?

Anton: I would say that this is not a problem. In fact, there are few specific problems with Kotlin, and usually its documentation helps to find answers. Very often, when developing an Android or a web application, questions arise about the platform or API, and not the programming language. Therefore, out of a million answers on Java, most likely, 90% are suitable for Kotlin, I see no problems. An unexpected feature in IDEA also helps: if you copy a Java code from the Internet to a class on Kotlin, it is automatically converted to Kotlin.

Interaction with developers and language evolution

JUG.ru: Kotlin recently had an official podcast , before that the language development process was made more open like KEEP - Andrei, and these are parts of the general plan “to address developers more actively”, or individual initiatives?

Andrei: I can not boast that we have some kind of large detailed plan, the world is changing too quickly to make such plans. But, of course, we have a general direction for maximum communication with users, we invest a lot of resources into it.

We have a public Slack , the audience of which is now approaching 6000 people, engineers from our team regularly appear and answer questions there, and the community is very actively communicating with each other. To the question about Stack Overflow: if it suddenly turns out that somewhere in public sources there is no answer to the question, then you can go to Slack and get answers there very quickly, including a rather detailed consultation of the person who wrote this functionality. There is also a podcast, various publications that we are trying to do ourselves, and recently opened a support program for user groups to make it easier for people to organize meetings around Kotlin. This is one direction.

Another direction, KEEP, is no longer about the actual organization of the community, but about the design of the language, the Kotlin Enhancement & Evolution Process: how we are going to evolve the Kotlin. KEEP is now in a relatively rudimentary state, here was the first test - we, at 1.1, tried to publish our design solutions so that people from the community could give us some feedback, discuss something with us, tell us about our impressions, suggest that something. This works quite well, although, of course, the load on the design team is increasing, and now we are all reorganizing a little. That is, we will continue to publish everything, just a little differently we will do this so that the load is less. But the point is that we try to work as openly as possible on the design of the language so that as many people as possible look at it as early as possible and tell us what they think. Actually, it is in the best traditions of open-source projects, and we really like these traditions.

JUG.ru: Anton, does this openness of the company help you in your work?

Anton: There is no such thing to help, no - I’ll say once again that in terms of understanding, everything is good enough and without someone personally pulling. You can always see the source code of libraries. But it is very pleasant that access to language designers, for example, at conferences, is easy. Perhaps, due to the fact that I am not far from St. Petersburg, it is quite easy to cross someone, to talk - there is, of course, no other language in which I wrote, it is usually more difficult to reach the authors of the language. And it seems to me that this is a big plus.

JUG.ru: In connection with “it is easy to get through when you are close to St. Petersburg” it is curious: does this lead to an increased interest in Kotlin in Russia compared to other countries?

Andrei: We really see a lot of attention to Kotlin in Russia. We have fewer actual users in the country than in America or China, but this reflects the number of people. I find it difficult to compare with other languages, I do not have good geographical data for others, but I can say for sure that we feel a lot of attention from the Russian community. On the one hand, there are a lot of people who are doing something, investing their soul, and not just reading. On the other hand, it’s an amazing fact, I don’t know how it is explained, but those very rare people who express their opinions sharply and incorrectly in different channels of information, pass on to their personalities and are rude in many ways, so far 100% of the cases were Russian.

Anton: I can assume that it is easy for a Russian person to get rude to another Russian person. It is unlikely that a Russian person will be rude to an Englishman or an American.

Andrew: An interesting version, I did not think about it. Maybe.

JUG.ru: Returning to KEEP: Anton, do you participate in it or not?

Anton: So far, KEEPs are mostly just reading. There you have to spend a lot of time to get into context. It is a pity that I did not actively participate in the development of features 1.1, corutin and so on, but maybe at some point I will find more time to do this.

Andrei: Yes, to plunge into all the details of the design of some clever features of the language is a very large load. As a person who, under various circumstances, immersed in the design of other languages ​​(in particular, Java) and participated in the process, I understand that a lot of specific context needs to be loaded into my head. But, of course, there are people who can and want to do this, and we are trying to give them that opportunity.

The big question for us is how to organize the design process so that, on the one hand, it is open, and on the other, it does not slow down. We have a lot of verbal communication, because we are in the same office or we can phone, and if we translate all design communications into correspondence, they will simply slow down at times. We don’t want to slow things down so much, so instead we periodically dump the current vision, post it, collect comments and then recycle it. This has not worked as efficiently as we would like, but we will improve the process and make it so that external people can really get involved.

Anton: I would say it’s really good that you make more effective communication in your office, because a successful programming language needs dictatorship to some extent. In principle, it is clear now how slow the development of Java is due to the fact that many decisions are very afraid to make, these unfortunate lambdas have been in pain for so many years ... It seems to me that sometimes, if there are two alternatives, you just need to choose one and implement it.

In Kotlin, this is still ok with this, and it seems to me that this is how it should be continued. Do not wait, maybe about some things too many comments.

Andrew: Absolutely agree. On the one hand, we try to collect as much input as possible, first of all we are interested in user cases: how people write code in different contexts. But at the same time, we really do not want to block ourselves on any issues.

For example, with korutinami we have this situation: we are now in 1.1 released them in an experimental mode. We have an absolutely working implementation, there are libraries from us and from other people - but we understand that the feature is too big to cover it completely in some finite time. Therefore, we release the existing design in experimental status, so that many people use it, we will receive feedback, and if necessary, we will fix something.

Such a feedback loop with the community, it seems to me, is absolutely necessary in order not to break away from reality. At the same time, it is not necessary to do this as super-conservative, as is customary in the Java team. They have their own reasons for doing this, but, fortunately, we don’t have such a need, and we try to move, not to slow down, not to be paralyzed by “analysis paralysis” and the need to satisfy everyone.

Anton: At the same time, Kotlin may not have lived long enough to stumble upon some problems that make the Java community so slow and conservative. We still don’t know how the code on Kotlin will withstand the test of time, whether the code compiled from 1.0 will work well in five years, whether today's source code will be compiled in five years.

Andrei: As for the compiled code, I’m pretty much sure that everything will work as well as any other Java program, because there is quite a limited influence of Kotlin himself. But as for how the source code will be compiled - it depends on us, and we have many questions about how to do it perfectly, we will try different strategies.

We had a very good experiment before release 1.0, when we changed the language, but we already had some hundreds of users, and we didn’t want to break all the code. We did the migration tools: this is something that is not very common in other communities, when the programming language changes in incompatible ways, but the tools provide migration. It was a rather positive experience, there were no moans and especially great suffering, which is very nice. This is a reassuring signal for us: if it suddenly turns out that it is very important to change something, then we can do it and not lose the audience, not turn into Python 3.

But this is a very difficult question of balance - how to evolve the language so that, on the one hand, there is no stagnation, of some terrible legacy that suffers everyone, and on the other, so that people can use it normally and they don’t suffer from migration. There are different approaches - Java is super-conservative, Scala in each release breaks binary compatibility, Swift in each release breaks source compatibility, and they all have some results. We look at them all and think: “How can we do better with this?” So far, we have been very conservative, break very little, do nothing binary, but at the source-level very, very carefully.

Anton: In this sense, automatic migration is a very pleasant thing, even Java 9 is now beginning to take some steps in this direction, improve the deprecated-annotation, but, as I understand it, they still need to grow to Kotlin?

Andrei: Yes, we have developed a serious universal mechanism that can be used not only by us, but also by the authors of libraries, and for the time being this is simply mega-success. Indeed, a person can write a deprecated annotation, and the IDE automatically emigrates everything, and everything is cool. Well, for a wide class of cases. Some things, of course, will not work, but a lot of things can be immigrated.

JUG.ru: Since JetBrains is engaged in both language and toolkit, do you have a trump card compared to Java?

Andrew: Well, in principle, absolutely nothing prevents Oracle from contacting us and saying, “Guys, we are doing this kind of thing, can you make support in IDE,” and we, of course, will, there is no problem with that. Another thing - what the authors of the language of mindset, the approach to this. There is just another mode of language evolution. It is currently evolving 100% compatible. As for the deprecation of various APIs, they are now simply forced to take painful steps for them. They hesitated with Java 9 for a very long time, and now they are doing something to make it more or less convenient. And, of course, all the tuling, which is possible, will rush to help them, because there are millions of Java programmers, they need to make it convenient, and here there are no options at all.

But it is easier for us in the sense that the cycle of interaction between tulling and language is shorter. We can make a decision very quickly, import very quickly, see how it works - it takes not months, but days. In this sense, of course, we have an advantage.

Compilation in JS, Kotlin Native and multiplatform in general

JUG.ru: In the “No Slides” release of CEO JetBrains, Maxim Shafirov called Node.js an important advantage to use the same code on the server and on the client. And the appearance in Kotlin 1.1 compilation in JavaScript is intended to give him the same advantage. Anton, tell us: does it really matter for you as a developer? Since your company has a full stack, does Kotlin become much more attractive for you thanks to JS compilation?

Anton: I can not say that attractiveness rises sharply. The promise of JS-support was a long time ago, I even tested it a little, but for the time being I’m not quite sure that using the same code on the client and server is so useful. When Node.js appeared, they said “everything, it solves all problems, full stack in one language”, but in fact it did not solve any problems, because the code for the client and the server is completely different, there is very little that can be reused.

So let's see, you need to experiment very much. What interests me more is Kotlin Native, a very interesting project or idea, I don’t know at what stage it is now.

Andrei: Let me tell you. First, two words about JS and its fate: we have now released a release version of Kotlin's compiler in JS, and a standard library, common for two platforms. And this is the first step towards the possibility of writing multi-platform projects, where you can really conveniently reuse the code, compile it into different platforms. To do this, over time, there will be a special tuling in the IDE and so on.

And this is quite a broad story, because if we include native in the same line, we get three classes of platforms: Java virtual machines, JS virtual machines and all native platforms on which Kotlin Native can run (in fact, everything that LLVM supports ). And for us it is an opportunity, conditionally, to cover all more or less imaginable user cases. And our ultimate goal is to make such a tuling in which you can write code on Kotlin and compile it into all three platforms without changing it. And, accordingly, add to it some kind of platform modules, making applications that re-use on different platforms some part of the code.

As for Kotlin Native, we recently started completely, at the beginning of autumn, now we are working on the first implementation. This is your full runtime - it does not use any finished virtual machine, only LLVM as an infrastructure for compilation. At the moment, there is supported quite a large part of the language features. There is the first implementation of memory management, and we already know how to interop with native calls. We are able, for example, to write some echo server on Unix sockets or something else, that is, you can already write some meaningful code that uses the standard C library and the Kotlin standard library as a wrapper over it. There's still a lot of work, it's not at all close to release. And the initial phase of the project is that we do general work for all possible native platforms, basic things: compilation, memory management, linking with everything that is needed, and interop with native APIs. And then we will have to choose some one platform, which we’ll be the first to support, really, really, and we’ll see if it’s going to be either iOS, or small embedded systems, or something else.

Anton: And this support of JS and Native, probably, will greatly influence new features in the language? For example, some feature that is easier to make on JVM than on JS, you decide not to do at all in Kotlin?

Andrew: I still do not notice such trends, rather the opposite: they are pushing us to do some features that are difficult to do at JVM. For example, value-types for native are very necessary, we have to do at least something of our own for interop with value-types on the JVM. Naturally, not so beautiful, as will be in Valhalla, in principle, nothing crazy, everything is pretty normal invented. So far, the existence of another platform directly blocked some serious feature, we have not yet.

Is that there is always a temptation on a specific platform to support something such, specific to this platform. In the native of this most: the ability to write to the ports and something else. So far we have done quite well to push all this into the library, and in the language of such crazy things can not be dragged. Here is the dynamic type - an example when we support some feature only on JS, because this is just a specific feature of the platform. Whether we will ever be in the native and on the JVM to support the dynamic type - it’s not clear yet, there are still some usage cases on the JVM, we haven’t yet come up with the native in the JVM. Well, in fact, there are no user cases - there is no need to support anything.

That is, we have no formal need to port 100% of the Kotlin code between all platforms. We try to approach this issue pragmatically: we have a common vision of the language, in a sense, the core language, and we compile it as closely as possible onto different platforms. We have a very small shared library, and each platform can do a little differently in its own way. There are platform types on the JVM, and all the features of the JVM are taken into account. On JS there is nothing associated with threads, and there is, on the contrary, a dynamic type. The native has its own characteristics associated with value-types, and this is normal, because we have a goal not to make a language in a vacuum, but to do something on which to write real programs for real platforms. And if you need to write portable code, then those modules that should be portable will impose some restrictions that may not be in a particular platform.

JUG.ru: The disadvantages of JavaScript have become the talk of the town - and what about JS, when you come across it not as an ordinary developer, but do you compile Kotlin in JavaScript?

Andrei: It's not so awful. Of course, there are its own features, but I would not say that it is somehow catastrophically worse than in Java. JVM imposes much more restrictions, but there is no such direct mapping to JS, some Kotlin constructs in JS simply do not exist - for example, there are simply no interfaces in any sense. On the other hand, in JVM a lot of things cannot be done in principle, and in JS the restrictions are softer.

From the point of view of language interop, this is a very detailed history, but ideologically it is the same as in Java. It's just that Java has platform types, which nullability is, in a sense, erased, and in JS, because there is one type, then we just have a new dynamic type in Kotlin that behaves just like a JS type: that is, nothing about it you know, anything can lie in it, you can call anything on it. , , , JS, . , , : -, , , -, code completion, - .

, TypeScript, - JS. Definitely Typed , Kotlin. , Kotlin, : , , . , , , « , TypeScript , ». -, , , , , - .

JUG.ru: , - . , , , — ?

: , . , , , , , . codebase, - .

: , , ?

: , . , IDE. , .

: , , , IDE, Gradle, , . , Kotlin. , , . IDE, IDE . , 1.2, .

JUG.ru: . Kotlin selling points null-safety Java. : Java null-safety, Java null.

, «Avoid entire classes of errors such as null pointer exceptions», , Kotlin Java, .

: ?

: . , 1.0 , nullable. , Java-. -, , , - . , , , Kotlin - , , — nullable nullable, . , Java, . , , , — .

: , nullability Java 1.0. , , nullability, , . n , : , , - . , , .

« , null safety, null safety ». , , Java, … , , . Java-, , Kotlin , null', . IDEA , , Kotlin , Java null, null, IDEA , Java. - Kotlin Java, , .

: , Uncle Bob Kotlin nullability?

: , .

: nullability, .

: , , … ( , ). : - , , , -, . , .

-, , Uncle Bob , . , , , , . .

-, « , , , - nullable, , ». , — , , - , . - nullable, , , , , ! , , . , , , , . Kotlin .

- , const C++, - — , -.

: Uncle Bob, , « , ». , , , Kotlin nullability, , , . , , Kotlin , , , - ?, !!.. , , , . lateinit, . , , , - , , .

: , , , . , - , - . , . -, Kotlin , nullable- , .

: , , , -nullable, -nullable nullable . , , .

JUG.ru: , Kotlin , : , . : , Kotlin, , ?

: , . , , , . Kotlin, . - , — , Kotlin . .

: , . Kotlin , , . , , , , . .

. JVM Kotlin , Java, . , Java, . . , .

: , … , , , , Kotlin — « Java», , Kotlin, , . , , , , , .

: , Kotlin « Java». , , Kotlin « Java» .

JUG.ru: JUG.ru , ( ) Kotlin, «, ». , , JPoint «Kotlin Puzzlers» — ?

: , , - , , , , . JetBrains , Java- Kotlin , . , , - , . , — , , , .

Kotlin, , Java- — , , Kotlin . — , Kotlin- .

: -, , , . - Java-, Kotlin , . , , - , - , . - Java- . , , - . - , - , , Java, — . , , — , ”WAT” JavaScript , , , . , Kotlin .

JUG.ru: , ?

: , . , , . , - , , , , . , .

, : , . , , - API, API . , - , . , , warning IDE, , « - , ». : , , - . , .

, - . , - , , , , , - , . , , , .

: , , , , . JetBrains, , . .

: , - , , , , !

: , , !

JUG.ru: , « Kotlin: », . Kotlin — ?

: , , — … , , , , , . .

-, , adoption , , , . , . , , Gradle, Spring Vert.x, , , . , , adoption .

-, : , - ( , --) Kotlin Native, , , - , , : iOS, Arduino, - . , , , full stack- Kotlin. , full stack — .

, full stack- Kotlin, JS - , : , - . — type-safe web , - - , , , .

, , , , .

JUG.ru: — , . Kotlin , : , «», , . , ? , -5 TIOBE?

: : , .

, , . -- , Kotlin , , .

, -5 (, , TIOBE- -5 ) — . , , , , .

JetBrains — , . Apple « Swift, », Swift . Swift iOS. , , . , , — , , . Point. .

. - : «, , , Java -, COBOL. Java COBOL ». , COBOL . , , TIOBE- , — , . , , C — . Java . Java - , , .

, , -1, , -1, -20, , .



« », Android-, «Kotlin Puzzlers» JUG.ru Group:

• Java- JPoint (, 7-8 , )
• Mobius (, 21-22 , — , Kotlin -)

And Andrei Breslav limited JPoint . There he will make a presentation on “how we imagine the future of Kotlin as a language and ecosystem. We will talk about the strategy: what, in our opinion, the industry needs, and how Kotlin will help here. About tactics: how we cope with problems of compatibility and legacy, and whether there will ever be Kotlin 2.0. About momentary: how about continuous delivery for language features? Or, more generally: to what extent can an agile approach be used to develop a programming language? ”