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



    In the year that has passed since the release of Kotlin 1.0, the language has had 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, adding compilation to JavaScript, and it looks like a high-profile application for a new market share. Does this mean that now the time has come for Kotlin really, and it’s 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 soon be performing at JPointwith reports about it), but they look at it from different angles: while Anton is developing in this language, Andrei is working on the language itself. We decided that about the present and future of Kotlin it would be interesting to talk to both of them at once, having got the full picture. Starting with questions about rapid growth, then we managed to discuss a lot more:

    • Interaction with developers and the process of language evolution
    • Compilation in JS, the Kotlin Native project and multiplatform in general
    • Imperfections
    • Kotlin Puzzles
    • Expectations and Ambitions

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

    Andrey abreslav Breslav: Everything is very simple for me, I am heading the whole project: both the whole language design and the whole management.
     
     
     
     
     
     
     
     

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

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

    As an experienced developer, my experience was very positive, and it was hard for a less experienced developer in this project to learn a new language. That is, for me it was more fun, and for the other person it was more an obstacle to doing the work quickly. But it seems to me that we quickly got used to it, and from that time I loved the language more. Before that, I was a little skeptical, because it seemed to me that with the release of Java 8 it already covered many user cases. But it turned out that Kotlin is still much nicer than the eighth Java. Therefore, I am now trying with might and main 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 - but how do you see it?

    Andrew:2016 really was a breakthrough year, at least because the release was released. Naturally, the community began to seriously consider the project, went adoption. We are very pleased with the dynamics that we see: Kotlin is used by large companies in serious projects; there are a lot of training materials from different people; people from the community write books that we ourselves did not sponsor, and they are popular.

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

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

    Andrew:I have seen very few pure Kotlin vacancies, but there are more vacancies "I need a developer in Java and / or Kotlin." It is clear that if people have an actively developed project either on the backend or on Android, and one of the participants adds Kotlin there, then the vacancies there become not only Java, but also Kotlin. If people are used to hiring serious enough specialists who are not hard to master a new cool technology, then this is not a barrier for them, and they calmly do it.

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

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

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

    Anton: When Kotlin 1.0 came out, it was raw - or at least an IDE. IDEA was still very inferior to Java capabilities. For example, there were a lot of bugs in the debugger, we also met in the compiler ... On the first project, we encountered a lot, especially there were a lot of problems with the debugger. And if in the case of Java, IDEA is cool with inspections, then, for example, in Kotlin it did not find the same shortcomings. But gradually it became much better.

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

    JUG.ru: And, for example, is the necessary information easy enough to find? On Stack Overflow, there are a couple of thousand answers for the Kotlin tag, and almost a million for Java - does this 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 you find the answers. Very often, when developing Android or a web application, questions arise about the platform or API, and not the programming language. Therefore, out of a million Java answers, most likely 90% are suitable for Kotlin, I don’t see any problems. An unexpected feature in IDEA also helps: if you copy Java code from somewhere on the Internet to a Kotlin class, it is automatically converted to Kotlin.



    Developer Interaction and Language Evolution


    JUG.ru: Recently Kotlin has got an official podcast , before that the language development process was made more open as KEEP - Andrey, and are these parts of the general plan “more actively contact developers”, or individual initiatives?

    Andrei: I can’t boast that we have some sort of large, well-thought-out plan, the world is changing too quickly to build such plans. But, of course, we have a general direction for maximum communication with users, we invest a lot of resources in this.

    We have a public slack, whose audience is now approaching 6,000 people, engineers from our team appear regularly enough there and answer questions, 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 you can’t find the answer to the question, you can go to Slack and get answers there very quickly, including a fairly detailed consultation of the person who wrote this functionality. There is also a podcast, various publications that we try to do ourselves, and recently opened a support program for user groups so that it is easier for people to organize meetings around Kotlin. This is one direction.

    Another direction, KEEP is not about the organization of the community itself, but about the design of the language, the Kotlin Enhancement & Evolution Process: the way we are going to evolve Kotlin. KEEP is now in a relatively embryonic state, here was the first test - we tried to publish our design solutions in Scope 1.1 so that people from the community could give us some kind of feedback, discuss something with us, tell us about our impressions, suggest that something. This works pretty well, although, of course, the load on the design team is increasing, and now we are reorganizing everything a bit. That is, we will continue to publish everything, just do it a little differently 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 can look at this as early as possible and tell us what they think. Actually, this is in the best traditions of open source projects, and we really like these traditions.

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

    Anton: There isn’t such a thing that helps a lot - I’ll say again that in terms of understanding, everything is good enough without having to personally pull someone. You can always see the source code of the libraries. But it is very nice that easy access to language designers, for example, at conferences. Perhaps, due to the fact that I am not far from St. Petersburg, it’s easy enough to meet someone, to talk - of course, this is not possible with any other language I wrote in, 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 reach out when you are not far from Petersburg” it is curious: does this lead to increased interest in Kotlin in Russia in comparison with other countries?

    Andrew: We really see in Russia a lot of attention to Kotlin. We have fewer actual users in the country than in America or China, but this reflects the number of people. It’s hard for me to compare with other languages, I don’t have good geographical data for other languages, 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 do something, put their souls in, and not just read. And on the other - this is an amazing fact, I don’t know how it is explained, but those very rare people who express their opinion sharply and incorrectly in different channels of information, turn to personalities and are rude in different ways, for now in 100% of cases it turned out to be Russian.

    Anton:I can assume that it’s easy for a Russian person to cheat on 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 need to spend a lot of time to dive into the 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.

    Andrew:Yes, immersing in all the design details of some tricky language feature is a very big load. As a person who, under different 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 the head. But, of course, there are people who can and want to do this, and we are trying to give them such an opportunity.

    The big question for us is how to organize the design process so that it, on the one hand, is open, and on the other, does not slow down about it. 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 instead, we periodically dump the current vision, post it, collect comments and then process 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 that it’s really good that you make more effective communication in your office, because a successful programming language needs some kind of dictatorship. In principle, it is now obvious how slow Java development is due to the fact that many decisions are very afraid to take, these unfortunate lambdas have been procrastinating 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, everything is still okay with this, and it seems to me that this should be continued. Not to wait, maybe there are too many comments about some things.

    Andrew:I totally agree. On the one hand, we try to collect as much input as possible, primarily interested in user cases: how people write code in different contexts. But at the same time, we really do not want to be blocked on any issues.

    For example, we have the following situation with coroutines: we now released them in experimental mode in 1.1. 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 for some finite time. Therefore, we release the existing design in an experimental status, so that a lot of people take advantage, we will get a feedback, and if necessary, we will fix something.

    It seems to me that such a feedback loop with the community is absolutely necessary so as not to break away from reality. At the same time, it is completely optional to do this as super-conservatively 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 in the world.

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

    Andrei: As for the compiled code, I am pretty sure that everything will work as well as any other Java program, because there is a rather 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 ideally do this, 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 did not want to break all the code with it. We made migration tools: this is something that is not very accepted in other communities, when the programming language changes in an incompatible way, but the toolkit provides migration. It was a pretty positive experience, there were no groans and especially much suffering, which is very nice. This is an encouraging signal for us: if it suddenly turns out that it is very important to change something, then we can do this and not lose our 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, some kind of terrible legacy that annoys everyone, and on the other, so that people can use it normally and not be tormented with migration. There are different approaches - Java is super-conservative, Scala breaks binary compatibility in every release, Swift breaks source-compatibility in every release, and they all have some results. We look at them all and think: “How could we do better with this?” For the time being we are very conservative, we break very few things, binary nothing at all, and at the source level very, very neatly.

    Anton:In this sense, automatic migration is a very nice thing, even Java 9 is now beginning to take some steps in this direction, to improve deprecated annotation, but, as I understand it, does it still grow before 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 so far it’s just a mega-success. Indeed, a person can write a deprecated annotation, and the IDE automatically emigrates to him, 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 migrated.

    JUG.ru: Since JetBrains deals with both language and tools, is there a trump card in your hands compared to Java?

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

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



    Compilation in JS, Kotlin Native and multi-platform in general


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

    Anton:I can’t say that attractiveness is increasing sharply. The promise of JS support was a long time ago, I even tested it a little, but so far 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 server is completely different, very little can be reused.

    Therefore, let’s see, we still need to experiment a lot. And what interests me more is Kotlin Native, also a very interesting project or idea, I don’t know what stage it is currently at.

    Andrew:Let’s tell you. First, two words about JS and its fate: we now have a release version of the Kotlin compiler in JS, and a standard library that is common for two platforms. And this is the first step towards the ability to write multi-platform projects, where you can really conveniently reuse the code, compile into different platforms. To do this, over time, special tuning will appear in the IDE and so on.

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

    As for Kotlin Native - we recently just started, in the beginning of autumn, now we are working on the first implementation. This is its full runtime - it does not use any ready-made virtual machine, only LLVM as an infrastructure for compilation. At the moment, quite a large part of the language features is supported there. There is the first implementation of memory management, and we already know how to interope with native calls. For example, we can 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 standard Kotlin library as a wrapper over it. There is still a lot of work, it is absolutely not close to release. And the initial phase of the project is that we do a common work for all possible native platforms, basic things: compilation, memory management, linking with everything you need, and interop with native APIs. And then we will need to choose any one platform, which we will support first very, very real, and we will see that it will be - either iOS, or small embedded-systems, or something else.

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

    Andrei: I don’t notice such trends yet, it’s rather the opposite: they push us to do some features that are difficult to do on the JVM. For example, value-types for native are very necessary, we will have to do at least something of our own for interop with value-types on the JVM. Naturally, it’s not as beautiful as Valhalla will be, in principle, nothing crazy, everything was thought up pretty normally there. So far, the existence of another platform directly blocked some serious feature, we have not yet had.

    Unless there is always the temptation on a particular platform to support something that is specific to that platform. In native, this is most of all: the ability to write to ports and something else. So far, we have been pretty good at pushing all this into the library, and not dragging such crazy things into the language. Here is a 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 support the dynamic type in native and on the JVM is not yet clear; there are still some user cases on the JVM, we haven’t come up with native yet. Well, actually, there are no user cases - there is no need to support anything either.

    That is, we have no formal need to port 100% of the Kotlin code between all platforms. We are trying to approach this issue pragmatically: we have a common vision of the language, in a sense “core language”, and we compile it as close as possible to different platforms. We have a very small shared library, and everything else each platform can do a little differently. There are platform types on the JVM, and all sorts of JVM features are considered there. There is nothing related to threads on JS, and there is, on the contrary, a dynamic type. Native has its own peculiarities associated with value types, and this is normal, because our goal is not to make the language in a vacuum, but to do what we can write real programs for real platforms on. And if you need to write portable code, then those modules that should be portable,

    JUG.ru: The shortcomings of JavaScript have become a byword - but what is it like with JS when you come across it not like a regular developer, but are compiling Kotlin in JavaScript?

    Andrew: It's not so bad there. Of course, there are their own peculiarities, but I would not say that it is somehow catastrophically worse than in Java. The JVM imposes much more restrictions, and there is no such direct mapping on 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 the JVM, a lot of things can not be done in principle, and in JS the restrictions are milder.

    From the point of view of linguistic interope, this is a very leafy story, but ideologically it is the same as in Java. It’s just that in Java there are platform types that nullability in a sense erase, and in JS, since there is one type, we just have such a new dynamic type in Kotlin that behaves just like a JS type: that is, nothing about it it’s known that anything can lie in it, anything can be called on it. And he, in principle, largely covers the needs of such a direct interope, if there is a library on raw JS, then you can interact with it. But, of course, the toolkit will be inconvenient: firstly, it is impossible to check any types, because they simply do not exist, and secondly, there is nowhere to get information for code completion, any such things.

    Therefore, we rely on typed headers written in TypeScript, which is now the de facto typing standard for JS. There is a large repository of such Definitely Typed headers , we give users the ability to convert them to Kotlin. At the conversion level, there are a lot of creative questions about how to map all this on Kotlin, because there is a different type system with its own characteristics: if the Java is just strictly weaker than the Kotlin, then the script script is just different. But, fortunately, this does not really concern compilation, it is rather a question of "how would we describe the type information that is in this TypeScript, in Kotlin terms." In my opinion, we are doing pretty well, but, again, the community will tell us if something is not very good.



    Imperfections


    JUG.ru: Everything sounds so good from all sides that I already want to find a catch somewhere. For example, Anton said last year that the compilation speed became a drawback for him - what’s the problem now?

    Anton: I didn’t measure, but it felt better. The compiler, which starts as a daemon, probably helps, and on those code bases with which I worked, compilation is not a problem now. But I have not tried on a really big codebase, where there can be hundreds of thousands of classes or something like that.

    Andrei: Tell me, please, do you use incremental compilation?

    Anton: Yes, of course. At least in the IDE. I think that just without incremental compilation the problem is.

    Andrew:Well, yes, we put a lot of effort into making incremental compilation work so that it works not only in the IDE, but also in Gradle, and it seems to me that there are very good results. I also have no complaints about compilation time when I program in Kotlin. Nevertheless, we have not completely finished work on the compiler's performance, there are still a lot of things planned. For us, this is also closely related to performance in the IDE, because the compiler in the IDE reuses a lot of code. And we plan in the next release cycle, in 1.2, to devote a lot of time to improving performance.

    JUG.ru: There is still such imperfection. Kotlin, among the main selling points, has null-safety and the convenience of interop with Java. However, these two advantages are mutually exclusive: in an interope with Java you lose null-safety, unexpected null can fly from Java.

    And theoretically, it may turn out that the developer sees the words “Avoid entire classes of errors such as null pointer exceptions” on the site, lights up, but since no one will immediately translate the large project into Kotlin and will have to constantly interact with Java, in the end he will only be disappointed .

    Question: Does this practically scare people away from the language?


    Anton:It is unlikely to scare. I would even say that it was a very wise decision shortly before version 1.0 to make platform types not all nullable. Otherwise, it would be hell to write in the language using standard Java libraries. So it was such a trade-off, and, in my opinion, still good. Of course, you need a little experience to understand that on Kotlin when using some Java classes, you sometimes need to specifically declare the type when you know what should come from there - nullable or not nullable, so that the compiler does not guess later. Otherwise, just like in Java, you will get an exception in runtime. But, in principle, how it is done now is well done.

    Andrew:Indeed, the issue of nullability during an interope with Java ate a lot of time before release 1.0. I think that in total this delayed the release for about a year, because we tried several different interopecs due to nullability, it seems, three or four. And the first n were inconvenient, it was just hard to write the code: either the code just turned out bad, or the configuration was too complicated, something didn’t work all the time. We came to the current version, and I agree with Anton that he has established himself very well.

    I don’t remember such complaints “how could it be that you promised null safety, but I have a Java library here and no null safety with it”. People do not expect a miracle from us, it is obvious that if Java, then I'm sorry ... Although, in fact, there are exceptions even to this rule. This requires additional work from the author of the Java library, but you can annotate it in the code in such a way that Kotlin understands what's with nulls and does everything right. In IDEA, most of our code is annotated, and everything is fine there, because Kotlin just knows where Java is null and where not null, and the Java IDEA also knows and swears in Java. If someone really wants to protect themselves from such problems, even at the junction of Kotlin and Java, then there is an opportunity, but this requires work.

    Anton: Andrey, and you saw an interesting postIs Uncle Bob just about Kotlin and nullability?

    Andrew: I saw, I saw.

    Anton: He walked well on this nullability, I'm interested in your comment.

    Andrei: After a lot of people paid attention to it, I read ... He wrote a total of three posts (at least when I last looked). And the message is something like this: once there were languages ​​without types, then languages ​​with types, then languages ​​without types became popular again, such a pendulum swings back and forth, now the pendulum swung towards types and went beyond the point of balance. We have more types than necessary.

    Firstly, this suggests that Uncle Bob knows where the balance point is. Well, he knows, but I think I also know, and I have a different opinion. At this place, you can simply exchange views.

    Secondly, there are some specific arguments “how, if, for example, I made some type in my program nullable, then now I need to change the rest of the program so that this program compiles”. I don’t understand this moment, because - yes, of course, I need to change something, it’s meaningful. If some type has become nullable, then the code that uses this type must take this fact into account, otherwise it will not work correctly! And, of course, this code needs to be changed. Well, you can run it, get an exception, and change it later, or you can just change it right away. Here in Kotlin it is necessary immediately.

    There are still some arguments, analogies with const in C ++, something else - this analogy is not entirely correct, in my opinion.

    Anton:With all due respect to Uncle Bob, it also seems to me that he just used the opportunity to say once again “you still have to write tests for your code, and the compiler will not save you”. What is it, in principle, correct, but I personally really like this feature with nullability in Kotlin, maybe for me it is even one of the main features for which I want to write in Kotlin. On the other hand, it happens when Kotlin does not allow me to easily describe what I want, the compiler says that I have to put somewhere either? Or !! .. Recently, when I have more experience with the language , I have less to struggle with the compiler, but there are such cases. There is also the lateinit keyword for this, which sometimes helps. So there are pros and cons, but it seems to me that, nevertheless, the bias has gone in the right direction, which is more useful than inconvenience.

    Andrei: Of course, I agree that there are cons, but you have to pay for everything. If we want the compiler to guarantee something, then some work is required on our part. Here is just a question, which is more justified. In my opinion, the experience of ourselves and all other people with Kotlin shows that the introduction of nullable types is justified, it turned out well.

    Anton: And for my part, I see that, as a rule, first I declare all types non-nullable, and changing non-nullable to nullable is almost always very easy. On the contrary, of course, more complicated.

    JUG.ru: Now, when Kotlin takes off, the effect of a silver bullet may occur: many will take it for a panacea that solves all possible problems. Therefore, there is such a question: much has been said about what can be expected from Kotlin, but what should not be expected from it?

    Anton: You should not expect any programming language to correct the design of your own code. Almost all the problems that I see in programming are not related to the language, but to the structure of the program. And in this sense, neither Kotlin nor any other language will help. He can give some tools for this to make it more convenient to do - for example, delegation is very easy in Kotlin. But you need to be able to design your code regardless of language.

    Andrew:I support Anton, I will simply say in other words. We tried to make Kotlin a convenient language, and as a convenient language it removes unnecessary complexity, which, by sense, is not in the head of the programmer. And the complexity that corresponds to the program, the meaning that is embedded in the program, no programming language will not remove. In any case, this complexity has to be structured and organized.

    You should not expect other miracles yet. A Kotlin JVM program will not be ten times faster than a Java program, or even twice as fast. Because we are as fast as Java, and it is very difficult to be faster. There are no such miracles. But this is a handy tool, and you can expect the effects of a handy tool.

    Anton:The most important thing, it seems to me ... Andrey, I don’t know whether you like this definition, but in fact, at the moment Kotlin is “better Java”, and this means that, as a rule, you can write an equivalent amount of code in Kotlin much shorter. And since the code is read at times more often than it is written, this gives a very large increase in productivity, when you need to read less to figure out where the bug or problem is.

    Andrew: Well, I really like the definition of Kotlin as “better Java”. This is one of the language’s user cases, and we really wanted Kotlin to be “the best Java,” among other things.



    Jigsaw puzzles


    JUG.ru: A year ago, Andrei and Dmitry Zhemerov at the JUG.ru meeting , when a question was asked about the Kotlin puzzle pieces (counter-intuitive features), answered "probably, the community will probably find them over time." And now, a year later, Anton is going to make a presentation on “Kotlin Puzzlers” at JPoint - have your expectations been fully met?

    Anton:Yes, Andrei said that if someone finds it, there will be puzzlers, and this, perhaps, motivated me to collect them. Comrades from JetBrains said in reports that many Java puzzlers in Kotlin have been fixed, but there are and will be puzzlers in any language. I began to collect them when I knew the language worse, periodically stumbled upon some nuances that were not obvious at first sight. Gradually the idea arose that it was possible to make a report about it in the usual puzzler format - this is primarily a fan, and perhaps allows you to demonstrate the language.

    Not everyone knows Kotlin, so in the report I first got an introductory set not strictly from puzzlers, but rather for Java developers, to introduce them to some features of the language so that they try to guess how Kotlin will behave in a particular case. And the second half is already real puzzlers, when an experienced Kotlin programmer may encounter unobvious nuances.

    Andrew:Firstly, I fully subscribe to the opinion that puzzlers are in any language, and this is normal. And it was my idea once upon a time to take Java puzzles, try writing them on Kotlin and see how many fall off. But this, of course, was never a real driver of language design and some kind of a serious guideline, just at some point I took and looked at what happened. Due to some design decisions in the language, certain Java jigsaw puzzles are really just not possible. At the same time, naturally, some of their own are possible. I will never undertake to make some kind of informative, production-useful language, in which there will be fewer puzzlers than in Java, or there will be no puzzlers - these are too cool requests. And there will be reports about them, a cool idea, and people with any language are ready to do such things - well, we know a super popular video"WAT" is about JavaScript and other dynamic languages, which is also, in fact, about jigsaw puzzles. So this is such a tradition, and Kotlin here absolutely can not stand aside.

    JUG.ru: And when the puzzler showed up, can this affect the further development of the language?

    Andrew: Maybe, of course. Well, the question is what to call a puzzler. There are bugs when some code, which should not be compiled at all, compiles, works, but in a completely unexpected way. This is just a bug, we go and repair it.

    There are times when we see: many users came up with the same problem, they wrote unintuitive code. This may mean, for example, that something in our library is not very successful with the API, then we can redefine this API and offer it more clearly readable. This may mean that in our language there is some combination of features that leads to this. If we understand that this combination of features is strictly harmful, we can give a warning in the IDE, in the compiler, say "you are doing something here that you hardly want it to." This is not always possible: sometimes the same combinations of features that lead to the puzzle, and lead to some useful things. This is just an inevitable evil, nothing can be done.

    Well, it’s clear that some jigsaw puzzles are being clarified at the design stage. We are working on new features, there is some kind of prototype, we start writing code on it, and if we encounter puzzlers there, we carefully look at them, try to understand whether we can somehow remake them so that these things do not occur. In general, we try to do what we can, but we are aware that we will never escape all the puzzlers.

    Anton: I can still comment that some of the puzzlers that sent me were real bugs in the compiler, and still there are some. I usually register these in the JetBrains tracker, and I hope that this kind of jigsaw puzzles will slowly go away. I don’t even want to use them in the report.

    Andrew:Well, if you report some kind of non-harmful bug with a note that this is a puzzler and you really need it because it entertains the audience, we can not fix it for a while if you want!

    Anton: Well, it’s not a problem if you need to use an older version of Kotlin in the report, so don’t do this!



    Expectations and Ambitions


    JUG.ru: Andrey, since you are preparing the report “The Future of Kotlin: Strategy and Tactics”, in the end I would like to ask about the future. The past year has been a breakthrough for Kotlin - and what kind of forecast can you make for the year ahead?

    Andrei: Well, I immediately say that fortune-telling on coffee grounds is such a thing ... I can say what I hope for, and there is also something I can not talk about, because it is connected with things that have not yet been announced by other participants market. But according to the general trend, I can say two things.

    First, if no global cataclysms occur, adoption will grow, and most likely it will grow like a snowball. And not only by the number of users, but also by the number of large infrastructure projects. If now we are working with large tools, say, Gradle, Spring and Vert.x, then over the next year this number, I think, will increase quite a lot. Well, and accordingly, the number of users will grow in proportion to adoption among popular projects.

    And secondly, we approximately know our plans for the year: if everything goes well, then we will get in some form (most likely, beta preview state) of Kotlin Native, and, accordingly, what will be our expansion into the market of a native platform, I don’t know yet which one: either iOS, or Arduino, or something else. We expect that this year we will be able to at least begin to build a community around full stack scripts on Kotlin. We strongly believe that writing a full stack in a typed language is awesome.

    As our internal users, who are already writing full stack applications on Kotlin, show that there is a huge gain compared to JS precisely because it is typed: tools help, and just some errors are eliminated due to the type system. I have my personal love - this is type-safe web in the sense that web applications really allow you to track some stupid errors during compilation in the spirit of path correspondences, the idea of ​​paths on the client and on the server of all kinds of serialization things, and so on so that all this is out of the programmer’s attention, because the compiler can do such stupid things.

    Well, let’s see how close we are to all this, but we plan, we have a lot of strength and enthusiasm here.

    JUG.ru: The last question is not about the next year, but about the global perspective. Maxim Shafirov in connection with Kotlin said that creating a language was a very ambitious task from the very beginning: they say it’s pointless to do “small”, so if you start this, then immediately swinging to a large market share. Andrey, what is your own ambition? Roughly speaking, do you want to get into the top 5 of the TIOBE index?

    Andrei: There are different things: there are ambitions, but there are expectations.

    I definitely want to make the coolest language in the world. I do all-all-all-all and a little more so that Kotlin is the coolest language in the world, respectively, one of the most popular and so on.

    At the same time, I try not to lose my mind and realize that getting into the top 5 most demanded languages ​​(and, probably, despite the inadequacy of the TIOBE index, the top 5 in it is adequate) is a very long way. On which, in addition to what I can control, there are quite a few factors that I do not control.

    JetBrains is a relatively small company, not a manufacturer of any platform. If Apple told all of its developers “you now write in Swift, which we break every six months,” then these developers write in Swift and repair their code every six months. We have no way to realistically compete with Swift on iOS. And there is no such goal, because it is obvious that this is impossible. There is a vendor, the vendor is not crazy, he made a very good language for his platform - that's all, programmers will do as the vendor said. Point. You can’t change anything.

    And also I always remember one wonderful proposition. A professor in Estonia once told me the following thought: “We can probably say that today we write more web applications in Java than in COBOL. But we cannot say anything more about Java and COBOL. ” Jokes are jokes, and the amount of COBOL in the world is amazing. And on the one hand, of course, it is not in the top in any TIOBE index, but on the other hand, it must be understood that the inertia is absolutely huge. And in this sense, to compete, for example, with C is generally absolutely transcendental activity. Well, with Java in many ways, too. We will see a huge amount of Java in the world for many years to come simply because all the programming humanity has accumulated tremendous inertia in this language, and it will lose it very soon.

    And in this sense, naturally, I want to be in the top 1, and at the same time I understand that if I get not into the top 1, but into the top 20, this is very cool, and I'm very good job.



    Since both server-side Java developers and Android developers are interested in the language, Anton Keks will present Kotlin Puzzlers in April at two JUG.ru Group events:


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


    Also popular now: