Andrey Breslav, the lead language designer for Kotlin, began his career at Borland, where he worked on language implementations for MDA support. After spending a few years as a college teacher, he joined JetBrains in 2010 to develop the Kotlin programming language. His goal is to make Kotlin a really good tool for industrial programmers.
Pramod: Hello everyone, welcome to mapping the journey. Java is the default language for Android development, but there’s a very new programming language called Kotlin, which is slowly becoming the popular choice among Android developers. For listeners, it’s a statically typed programming language for modern platform applications. So, why Kotlin you know, what problems are the language trying to solve? Well, today I have a special guest joining me from St. Petersburg, Russia. He’s the lead language designer of Kotlin and his goal is to make Kotlin an excellent tool for industrial programmers. His specialties include language engineering, generative programming and also teaching. We will be speaking about his interest; his journey with Kotlin and also get our questions answered. And I’m very excited and honored to have you on the show. Welcome, Mr. Andrey Breslav.
Andrey: Hello, thanks for having me here.
Pramod: We all know you as a lead designer of Kotlin, tell us more about yourself?
Andrey: Well, regarding my background, I guess I started, got interested in programming in like ninth grade, like programmed first command-line, then basic like crazy. I think I would be embarrassed to look at my programs now. Yeah, but then I went to school here in St. Petersburg and hugely got interested in first generative programming, UML, and all those modeling related stuff. And then slowly I got into domain-specific languages and even started a Ph.D. in that topic which I never finished and sometime over that line, I got to know people from JetBrains, and we had a fascinating conversation that in the end resulted in creating Kotlin.
Pramod: Okay, awesome…! So, why programming languages, what kind of problems you like to solve here?
Andrey: I guess it will be hard for me to trace like my original interests in languages. What I was specifically a big fan of, when I got introduced to Pascal was the static typing. So it fascinated me as a kid like a high school kid, I was then, so it was very interesting for me to like design whatever code I was writing, so that it would be hard to do things wrong.
So I guess this is my like natural, you know, natural liking for order and safety. So that would be one thing, and then I think in general as an engineer I like to make things work smoothly, especially when it’s hard, as a significant example of that would be Kotlin’s Java Interop. Which is of course not as smooth as I would ideally like because these are like too super hard, super different difficult systems, very complex, interacting on the boundary, but still it’s pretty smooth and it’s been a very tough task to make it work, but we managed.
Pramod: Okay awesome…! How was your introduction to Kotlin?
Andrey: I guess I wasn’t exactly introduced to it but the way the way it started was a former colleague from another place I worked in, invited me over to JetBrains to just a chat. I was doing domain-specific languages, and JetBrains had some exciting projects, research projects in domain specific languages, but then I heard they were thinking of maybe doing a general-purpose programming language.
I was very skeptical, but they invited me to talk, so I just visited the office. And the first two hours of that conversation were like, I was skeptical and saying, no you don’t need that there are enough languages you can just improve them, it’s all right. But then there were reasonably valid arguments that persuaded me that we should do a new language and that JetBrains as a company can make it appealing enough for the users to use it.
So one thing is to invent a language, and another thing is to make it famous. So here my now-colleagues persuaded me that it was possible to get the language out to the market and get people’s attention, get users interested and that’s what happened, so, they were right.
Pramod: Okay, when was it, is it late 2009, 2010 or…?
Andrey: It was 2010. I guess it was spring April 2010. Yeah so, and that same evening we already threw in a couple of basic features for Kotlin, which in the end made it to the final language design, so it was when it started. I guess somewhere in the email I have the exact date, so at some point just write it down for everybody to know.
Pramod: What was the thought process or like rationale that went through in designing the language. What were your ideas?
Andrey: Well, there were particular requirements, rather high level but still rather specific, so we looked at existing languages, so we, JetBrains had already been a big java code base, so we had experience with java here. We always had experience with languages because we were making IDEs for them.
So there was quite a bit of expertise accumulate on languages, and there are strong sides and their weak sides, and so we analyzed the situation on the JVM, and at that time there was Java 6 and there was Groovy, quite popular at that time, there was Scala, rising in popularity.
So we evaluated those languages and we actually in the initial thought was just to try them for ourselves, to improve our own development experience and so, in the end, we came up with a set of requirements that would make it work for us. First thing was tooling support, so we were tooling company, so our engineering process relies on IDEs and other tooling, so the language has to be tool able.
Then, of course, we wanted interoperability not to throw away our existing code bases, so it should have been transparently interoperable with existing code. We wanted it type-safe. It also imparts an implication of the tooling part because tooling for types of languages is a lot smarter than for dynamic languages and also we wanted it to be like, what we now call democratic or pragmatic.
So we want the language to be usable by everyone on the team, not to make like elite sub-teams that are only allowed to use like, those advanced features and all the other mere mortals are not allowed to use them. So these were like more or less essential ideas behind all that and yeah, and I guess it’s still our same core creed, all those four things.
Pramod: Okay, so, it was really for your internal use, you guys started developing and then it kind of evolved into a more full-fledged programming language.
Andrey: Not quite so. The initial idea, I think was from the very start to make it like a language for everybody, but we’re used to making technology inside JetBrains that works for ourselves and just extrapolate on others. So this is how we make IDEs, for example, we use them ourselves, dog food, everything we use and since we are programmers and you’re programmers, it’s all works, it all works for everybody. So that was the initial plan.
Pramod: Okay, so that’s a strong thing you know like “Java is Java”. It’s been very popular and been around since 1995, so when you guys decided, how confident were you and the team, that you can create something better than Java?
Andrey: Well, we were quite confident that we could make the language more pleasant to write in, then Java. Java is a great success regarding programming languages, but it’s quite obviously not a very modern language. Although recently it’s been making some progress, still something designed in the early 90s is tough to evolve.
So a big thing about language is that it’s not easy to evolve them in a compatible manner and Java has achieved miracles there, like introducing generics was a huge step, was very difficult but still evolving an old language is a challenge. So it’s very easy to be ahead of Java regarding usability, regarding how concise, how pleasant it is to program the language. So there we were quite confident.
Then like how easy it would be to make it as usable in all aspects like integrate with all the tooling, including non-JetBrains tooling. Make people believe that it will change things for them so and so forth, that was not that’s sure but we tried and we quite succeeded, I guess.
Pramod: Of course you guys had the confidence, I’m more interested to see what was the people’s idea when you introduced and were you confident that people will accept Kotlin?
Andrey: Well, we were quite sure that some people would like Kotlin, so that was more or less, you know intuitive at least for us. Then but then there were so many forces at play here and so many of them we don’t control like new language is appearing and it was quite a few languages that started roughly at the same time as us.
There is like platforms coming and going, say new virtual machines, new ways of programming, many things are changing that we cannot predict or control, so there were very many risks there, and we had no idea what could happen, and many very many unexpected things happened.
Pramod: Ok. So we all know JetBrains as a company that produces world-class Id’s, and we have been using it for many years. For Android, there is the studio, also IDEs for programming in Java
So, the question is why and when did JetBrains decide to invest in creating a new programming language?
Andrey: So, as far as I know, the principal decision was made not very long before that first conversation we had in April 2010. And the rationale behind this was that before that time, JetBrains was like a trend follower, so we saw what people used in industry, what technologies are big so where we can provide tooling for those technologies.
So we were more or less following trends around, but wanted to set some trends too and like advancing the state-of-the-art in industrial languages was a way to promote our name to build excellent technology, to improve our own programming experience and set off a trend in the industry.
Pramod: Okay, that’s cool. JetBrains Unveil project Kotlin, back in 2011 July and first official release was in Feb 2016.
I was curious to know why did it take more than five years to have the first version released?
Andrey: I guess there are many reasons to this. A couple of technical ones, so a big thing about Kotlin was that we wanted, from day one we wanted our first release to be guaranteed, to be backward compatible. So we are trying different designs then dogfooding them, finding issues and changing the design so and this process took a long time.
As I mentioned before java interoperability part was a real challenge. We I guess, tried maybe three or four different approaches there and to make it clear like trying a different approach is like re-working a significant part of the compiler, so it was not easy at all and that took time.
Also, I guess we could maybe do things more, like more aggressively and then move faster but I was not as experienced a manager at that time as I’m now, so I guess there were some organizational things that could have speed us up, but I just didn’t know.
Pramod: Okay, so how big is the team Kotlin?
Andrey: Currently we’re a little over 40 people, Yeah.
Pramod: Okay, so as you said you know Kotlin wasn’t built in a day, can you share some of the hurdles you had to face when creating the language?
Andrey: Yeah, there were many from different parts, I guess our first encounter of Android was quite interesting, we got just a bug report from a user, it was before the first release. Some enthusiasts tried Kotlin on Android for the first time and so all that happens there, the build process fails with the segmentation fault error. So it’s not just the common program doesn’t draw on an Android, it’s just the toolchain breaks down. It was quite interesting because we had, of course, no idea, we were not familiar with Android at all at that time.
So it was quite an interesting investigation, it turned out we were messing up some metadata in the class files, that hotspot VM doesn’t care about, but Android VM is a lot more picky about the specification. So they were detecting the problem, but something went wrong and just segfaulted on us, so it’s only one example.
Pramod: That’s cool, so, I did mention that I’ll be speaking to Andrey in Reddit. There’s a very niche Reddit group following there, and they were interested to ask some interesting questions.
And one of that was, what was the hardest trade-off you had to make when designing this language?
Andrey: I guess it might not be easy to pick the hardest, I think, language design is full of tradeoffs. I even give this talk language design trade-offs at some conferences. Yeah, it’s quite a few. I think I guess, for a language like Kotlin, the most significant trade-off is always, making something safe versus making it convenient or more generally making something beautiful versus pragmatic.
Yeah, and so I guess we have very many concessions like that made in the language. Our entire Interop story is about trying to make things safe on the boundary between the two languages and failing in different ways. And in the end, we have settled for pretty good balance, but we added a new kind of types to the language, to handle the interoperability scenario. And that was a tough decision because it complicates the language quite a bit but the cause is worth it, so we finally settled on it.
I guess it’s possible to find numerous tradeoffs of this sort. Like, when we that when the mathematical beauty would be this way but the reality is not as mathematical, so you have to settle for something much bulkier and not as elegant, but the outcome is worth it. It’s all for the users’ convenience in the end so.
Pramod: Yes, definitely. Simpler the language, more the developers follow and better for the language.
So, another question was, what language feature would you have liked to implement in Kotlin but you were not able to do it?
Andrey Yeah, well, there was quite a few. My ideal language would be quite different from Kotlin, but I guess it’s not that easy to make such a language interoperable with existing ones. So, I think for me it’s largely in the realm of type systems.
Like how, how we represent, how we describe shapes of our data, how we define contracts of our classes, our API’s, so henceforth. There I’m a big fan of structural typing, and I guess for mainstream languages or languages around mainstream, GoLang would be a good example of how people do something like a structural type system. If you’re a traditional language, so having ad-hoc interfaces or whatever you call them, protocols would be a great thing to do, and we are we have still not given up hope to maybe have it in Kotlin one day, but it’s not easy.
Pramod: Okay, that is a very good response. And they were also curious to know, what future language feature will have the biggest impact?
Andrey: So, one thing that that happens very often when you make something like a language is people want you to predict the future. I guess, I’m not too confident predicting the future, but I think there are things you know that are more or less a safe guess here.
I think we are in the asynchronous age, where all the communication between so many systems is asynchronous, and this is why we have coroutines in Kotlin, and well perhaps coroutines are like the first step, the basis for more mechanisms that would make asynchronous programming easy and tractable at large-scale.
I won’t be able to predict what other features we need there, but it’s one big thing, and then I guess with the spread of Kotlin native that we’re working on now, we’ll need value types for compact storage. And you might also know that the Java people are also working on value types, so that’s going to be huge regarding performance at least and also many other things very likely. So that’s going to be a big tool.
What else, well I guess there is a very interesting direction of having truly mutable data in the language, like tracking what can and cannot be mutated on the deep level, like not I’ll look like a single unchangeable variable but deeply immutable structures, that would be great. Huge difficulty tool but a very interesting thing, we’ll be looking into that and some near future.
Pramod: Awesome…! Kotlin community will be very happy to hear about that, they did ask about immutable and value structures as well.
So what would you do differently if you could start Kotlin today? Like, going back in time like 2009-2011, what would you have done differently?
Andrey: Yeah, knowing all I know today, I would probably be a lot more aggressive regarding growing the team. So I would probably start by hiring some experienced compiler engineers because back then we started with like a very small team. And It was all moving very slowly so that that would be one thing.
Then I guess I would push for an early release, even giving out backward compatibility is sort of like what Swift did, I think it was a very interesting decision for them to not guarantee backward compatibility in release one and just get the language out for people to use.
Regarding language design, there are some things I would have done differently. I guess inheritance by delegation is currently a problematic thing, that’s like very appealing on the surface but has very unpleasant interactions with other things I would have done it differently if I knew. Also, the way companion objects that are the replacement for static methods are done in Kotlin is not straightforward regarding again interactions with other things, so I guess that I would redo in some other way, yeah.
Pramod: Okay, that’s cool. So Kotlin is hugely successful, so to what do you attribute the success today?
Andrey: Well, it’s, I guess it’s many factors. So one thing I have to be fair you know, it’s a lot of work that has been put into Kotlin, and very many good people worked on It, so there is a massive contribution by everyone.
Then there is a little bit of luck of course. I’m sure; we got lucky many times, most of them we would just don’t know about. Then I guess we were initially like the in the very beginning we were very much encouraged by our users of Jetbrain products that believed in us and other people who believed in us.
But regarding features of the language or other properties of the project, I think we, we just sensed in the very beginning what was missing on the market. Language that would be pragmatic that would be tool able, and that’s what we made, and that’s why people like it because we made it so that it’s likable you know. It was the original idea.
I’m not saying we invented all that, not at all. Like we learned so much from other languages and I guess it’s a very important thing when you’re building something complex, to stand on the shoulders of giants. And I’m so grateful to all other people who did languages before me, whom I was learning from, like Java, of course, C++, C sharp, Scala Groovy, and many others. I’m not going to name them all, but it’s been you know a huge contribution by people never who never heard of Kotlin before.
Pramod: Definitely, it’s a huge effort as you said, like building applications for JVM, Android and even browser and native applications. I’m sure it’s been a lot of people’s effort and thank you and I thank everyone who made this possible.
And according to you, how huge was the Google decision to support Kotlin as the first-class citizen for Android?
Andrey: I guess, it’s a really important step for us so and we didn’t know when to expect it like I mean there was like something in the air that it might happen maybe but there was nothing definite at all. We didn’t know it for a very long time but apparently, Android programmers wanted it to happen so much that the team at Google listened to them and decided.
So for us, it meant, in the first place a lot of recognition, so many people heard about Kotlin for the first time because of that announcement and it’s important. Of course, it’s again growing the user base like a lot more people are now using Kotlin than a year ago or even half a year ago.
Pramod: Yeah, and I was watching that video, the excitement in the video and the people and it was very good. I think it’s a big step with respect to the Kotlin community and also the language.
And the last question, there are many articles I read and blogs and tutorials that provide the reason to move to Kotlin. We know about interoperability, you have mentioned that tooling support, as you said and also it’s very concise. For any new programmer starting today, like provide us, like three or four most important reasons to learn Kotlin than any other programming language today?
Andrey: I guess it would be productivity, productivity, and productivity. [Okay…okay] To be more precise here, I think people should choose Kotlin if they care about code readability, if they care about type safety in their programs, if they care about the expressive power of the language and the like the overall productivity that depends on those things.
Tooling, of course, Java interoperability of course, but it’s in the NSL code. So you want your code to be readable, you want your code to be pleasant to write, and you want to feel satisfied. Because you are so productive today, so that’s why I guess I and some other people choose Kotlin.
Pramod: Awesome…! I’m very eager to write the enterprise-grade application in Kotlin. I never got a chance till now. I’m really looking forward to building one.
It was wonderful talking to you, Andrey and I had real fun speaking with you and it’s a lot of takeaways for the people and the Kotlin community.
Andrew: Thank you very much. I like the questions a lot and happy to be here. Thanks a lot.
Pramod: There you go listeners “Kotlin is for Productivity”. That was a nice and quick chat with Andrey Breslav, he has convinced me to program or at least try Kotlin. If you are an Android or any other language developer give it shot. Thank you for listening and don’t forget to tune in for next episode with Damian Conway, Perl expert, fantastic speaker and he worked with Larry Wall for more than a decade in developing Perl-6. Must be an amazing conversation, He is joining me from Melbourne, Australia. You all have a good day, Until then “Joy Geen”…
November 9, 2017
October 26, 2017
October 12, 2017
September 28, 2017
September 15, 2017