主持人: Why would anyone create a new programming language today if AI can already write most of your code? Andre Brela has an an interesting answer. Andre is the creator of Cotlin, a language that runs on billions of Android devices and is one of the fastest growing languages in the world. Today we cover how Andre designed Cotlin by deliberately borrowing ideas from Scala, C and Groovy, and why he considers leaving out the turnary operator one of his biggest regrets. Why making Cotlin interoperate seamlessly with Java was a gigantic undertaking and what it took to get it done. How Cotlin adoption went through the roof after Google announced it making it the official language for Android in a move that even took Andre and the Cotlin team by surprise. Andre's new project Codespeak, a new programming language built on English designed for an era where AI writes most of the code. If you're interested in the future of programming languages from someone who built one of the most loved languages of today, then this episode is for you. This episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsors, Sonar and Work OS. Andre, welcome to the podcast.

Andre: Hello. Uh, thank you for having me.

主持人: It is not often that I meet someone who designed such an influential language across mobile across back end. So, let's start with how did it all started? Okay,

Andre: so that was a little messy because I went to school uh back in St. Petersburg uh started studied computer science and I didn't really know exactly what kind of programmer I wanted to become. I knew I wanted to be a programmer and then at some point while I was still in the university I started teaching uh programming in school and uh it was a big passion hobby of mine and then at some point I got a job with Borland and worked in some developer tools you know that was awesome like Borland was a very big name and you know they they went under pretty soon after I joined and I hope it's not because of me. Yeah, but but I worked on the it was at the tail end of the UML era. So, we were doing some developer tools in the UML space. That was very interesting. I learned a lot. But then Borland went under and I went back to teaching full-time and then I started PhD school and you know all that was kind of not really planned out and uh in my PhD I was working on domain specific languages and generally I was interested in languages. was something I was curious about and specifically typed languages were interesting. I was always curious about how these things worked but never really serious. When I started looking into DSLs, it was uh slightly more serious, although my PhD was a mess and I never defended because of that. Uh but at some point um you know some someone reached out. It was actually a person who was in charge of the Orland St. Petersburg and by that time he was already at JetBrains and he reached out uh to me while I was in Tarto in Estonia. I was there for a year on as a visiting PhD student. It was a lovely time. Um so he he reached out and invited me to when when I next visited St. Petersburg to visit the JetBrains office there and talk about something about languages. What I thought was that there was about the this project called MPS Metarogramming System that JetBrains had. I knew about it. It's about DSLs. I worked on DSLs. You know, it was generally something like plausible that they would be interested in talking about stuff like that. But it turned out I was completely wrong. And what they wanted was to start a new programming link.

Andre: And I was completely unprepared for that.

Andre: like I you know I've never thought about doing something like this and my first reaction was you don't do a new language like you don't need it and the the the basic pitch was uh that the Java ecosystem needs a new language Java is outdated so on so forth we can talk a little more about this it was 2010 I think yeah 2010 um yeah and uh I was like but there there are other languages like everybody's doing fine why do you need to do that and And this conversation was actually a very insightful one because uh the guys at J brains they uh simply explained to me how the things actually were and you know it was it was a big problem by that time. So Java didn't really evolve uh and hadn't been for for a long time.

主持人: What was the reason behind it? Can you take us back for those of us who are not in the ins and outs? Yeah. So, uh the

Andre: last major version of Java uh by 2010 was Java 5 that was released in 2004.

主持人: Oo. Six year old language.

Andre: Yeah. And since then there there were updates. There was Java 6 that made no changes to the language as at all. And then there was Java 7 that made minor changes. In parallel there there were things that that were happening in other languages, especially C was progressing very well. And by 2010, C# had all the nice things. There already were lambdas like horror functions and and all that nice stuff. There were getters and setters and and many other things that made the language much nicer. And Java was felt like it was standing still. And there was a project uh to to work on lambdas for Java, but that what was in the works and had been in the works for a long time and only came out in 2014. So that was the situation and uh the the ecosystem didn't stand still in the sense that other people were building languages and there was Scala there was Groovy and of course people at J brains knew both Scala and Groovy they built tools for them. It's traditional to build your tools in the language you're building uh the tools for. So the Scala plug-in was built in Scala and there was a lot of Groovy used JetBrains as well. So they knew what the issues were with the language and both languages are very interesting and very good in their own ways but they saw an opportunity in the market because Groovy was too dynamic and too far from hardcore mainstream large scale production because dynamic languages are not for that.

主持人: What are dynamic languages for what are their strengths and like best use cases?

Andre: So the trade-off I guess if you look at a like a statically typeyped language like Java and Cotlin and Scala for example versus dynamic languages like Python and Ruby and JavaScript and uh Groovy. Uh in dynamic languages it's very easy to start and build something working very quickly because basically the language is not in your way as much. There's this saying that nothing limits the imagination of a programmer like a compiler.

Andre: And you know this may be changing nowadays a little bit and this is in part what I'm working on now but um back in the day was completely true. You know the the the whole art of uh making a good language was to restrict the user in a good way. Uh yeah, but in any case, the the situation with dynamic languages is that they are much more user friendly in the beginning, but then when the project scales, you have trouble making large refactorings. You have trouble making sure that everything works together. where you need to do a lot more testing and rely on other things like that as opposed to static languages where you have uh you know precise refactoring tools and and other things that can make sure that at least a certain class of problems just doesn't happen. And you know this is why in at least in our mind back then it was absolutely clear that if we're building a language for uh large projects, big teams so on so forth it has to be a static lang

主持人: static one. Yes.

Andre: Uh yeah. So with Groovy that was a big issue performance as well because Groovy was building a dynamic language on top of a very static runtime. So there was quite a bit of tension there. Uh so that was in the Groovy side and the Scala side. Scala is a wonderful static language and incredibly powerful and with tons and tons of good ideas but it had its own problems. It relied very heavily on implicit for example and I have a history of debugging one line of Scala for an hour to try and figure out what it does just because you know it was pretty complicated and also the compiler was very slow and there were issues of stability and many many things were just not accessible enough for for a lot of engineers. So from the experience of using scala jet brains my colleagues basically understood that it's not what's going to change the industry although scala got a lot of adoption and again like Martin and Derki is a great language designer you know and and uh

主持人: I think one of the biggest use cases was old Twitter a lot of it was built on scala and they scaled to however you know massive scale etc

Andre: and I think LinkedIn as well. Yeah, so in any case uh these were you uh it's always very nice when other languages uh kind of pioneer things and then you can build on top of uh their successes and failure and we were in that position basically. So the the argument that people at JetBrains were making uh was basically that uh there is a window of opportunity. People need this language. We JetBrains are the company who can actually put out a language and make it successful because we have access to the users. We have their trust. We can make good tools. And it was another issue with Scala. For example, it was very difficult to build tools for Scala back then. Now Scala 3 is more tooling friendly. But back then it was a nightmare. Like I said that you know if if you have a static language you can't have precise refactorings if the language is not too complex and you know some languages are particularly challenging. So Scala back then and C++ were incredibly challenging to make precise tools for. So, and that was that was the basic pitch and I quickly understood that yeah, they were right and this was something that was worth a shot in the sense that it was not completely hopeless, not completely dead in the water. I had no idea if we could pull it off. It's it was then when we actually sketched like some initial features on the whiteboard

主持人: just because JetBrains is generally run by engineers. Hold that thought from Android on how JetBrains is genuinely run by engineers. This is because I happen to know another company also run by engineers. Sonar, our season sponsor. If there's a time when we need true engineers, it's now. As AI coding assistants change how we build software, code is generated faster than before. But engineuring basics remain important. We still need to verify all this new AI generated code for quality, security, reliability, and maintainability. A question that is tricky to answer. How do we get the speed of AI without inheriting a mountain of risk? Sonar, the makers of SonarCube, has a really clear way of framing this. Vibe then verify. The Vibe part is about giving your teams the freedom to use these AI tools to innovate and build quickly. The verify part is the essential automated guardrail. is the independent verification that checks all code human and AI generated against your quality and security standards. Helping developers and organizational leaders get the most out of AI while still keeping quality, security, and maintainably high is one of the main themes of the upcoming Sonar Summit. It's not just a user conference. It's where devs, platform engineers, and engineering leaders are coming together to share practical strategies for this new era. I'm excited to share that I'll be speaking there as well. If you're trying to figure out how to adopt AI without sacrificing cold quality, join us at the Sonar Summit to see the agenda and register for the event on March the 3rd, head to sonarsource.com/pragmatic/onarsummit.

Andre: So, everybody I talked with uh were deeply in the in the weeds with with IDs and everything and new programming languages very well and you know, we had a very technical discussion. So I don't remember exactly all of the features we're talking about but the current syntax for extensions in Cotlin was already there. Uh and I don't remember why exactly we focused on extensions but it was there. So you know from day one we were basically building on top of ideas from other languages like extensions obviously came from C. Yeah. So it was it was a very exciting conversation

Andre: but I didn't make a decision then uh because I I was in Tarto and I needed to finish there and it took me a few months to finish and then I came to St. Petersburg for one month because after that I had a an internship scheduled with Microsoft Research in Redmond. So I was going to Seattle to stay there for like three and a half months and I was like okay guys so I have this month I can work in the office and we can try to sketch things but then I'll go into Microsoft and then I will decide whether I commit or not which in hindsight I mean um well I made the right decision in the end. I had a great time uh for for this month or so um I worked uh with the guys in the office. It was mostly Max Trafimuk we were working with and it was incredible like we had such great discussions and I I actually saw Max this morning and uh it was like it was great time. So then I went to Seattle did something completely different there. Microsoft Research saw really great researchers. Uh working there actually was exposed to like the top-notch level of academia for the first time was very insightful. But after that I kind of realized what the question was whether I want to sort of try to pursue an academic career which you know I didn't feel like I was really built for that and was not sure whether I can be like a good researcher on my own or I'll I'll have to follow in somebody else's footsteps uh versus like do a crazy thing and build my own language here. I'm like okay I'm doing the crazy thing.

主持人: So for those of us engineers which will be the majority who have not built a language from scratch, how do you start with it? Like you know we we know speaking for myself I know how to write code. I know how to open the editor. I know how to write hello world and a more complex app and even more complex one. How does a language start?

Andre: In our case we basically talked a lot for a few months. So it's I think not everyone is like that but I think the best when I'm talking to people and this was the ideal environment because we were basically discussing things with the Max constantly for many months and there were a few presentations internal that I made at J brains and some of the slides survived so I can see including my spelling mistakes in those slides my English wasn't as good then and you can you can see some some of the evolution through those slides and I think there's a recording of one of those presentations. So we were basically doing whiteboard design for some time and the great thing about doing this at JetBrains was that there were a lot of people with opinions about not so much how to make a language but what problems do programmers face and what they like and don't like in other languages. So I had a tons of tons of input from other people and very good people. So that helped. And I really I don't think I realized how special that environment was back then. Like I was 26 to be clear. And I had no idea how things were done in general.

Andre: But somehow these people just trusted me. I I'm not sure it was very rational on their part. worked out, but I'm not sure I would recommend anyone to do this.

主持人: And so in the first few months, do I understand that you kind of whiteboarded and you kind of wrote down how you want this language to evolve? You kind of, you know, like wrote out like we're going to have these features or how can we imagine?

Andre: I guess the easiest way to explain this would be like this. So we basically went off what the pains were with Java and there were quite a few and and there was a lot of experience of using Java uh across the community and inside JetBrains and we kept making lists of things we wanted to fix and I came up with some ideas and some other people suggested other ideas about how things can be fixed and what is an actual problem and what we don't care about and so on so forth. uh and for some time I was just you know pieces of the puzzle basically laid out in a table without fitting together and then at some point we started fitting them together and I was just doing a lot of that in my head which is not the best way but this is how I knew how to do it. There were also some crazy ideas uh that we thought were important back then for example I wanted to implement multiple inheritance fully fledged multiple inheritance.

主持人: Mhm. which was a dumb idea.

主持人: Multiple inherits meaning that a class can inherit from like several classes. Yeah. And and you you have to take care of like conflict resolution and all sorts of edge cases,

Andre: right? Yeah. So, so the the actual challenge is not so much conflict resolution in terms of methods, but initialization of state constructors are really hard. It was actually someone outside of JBR who explained to me that was a very bad idea and I'm very grateful to them. Yeah. So you know there were crazy ideas uh as well and some of them just fall off over time as we were discussing or prototyping and we I think I started writing code maybe 6 months in or something like that maybe maybe a little earlier than that and I started with a parser and it was actually it was a very also a very unique way to start a language because the idea was to start not with a compiler but with an ID plugin. I have it in the editor first which is you know an ID plug-in shares a lot with the front end of the compiler so it's not absolutely crazy but I was just relying a lot on the infrastructure that was available in IntelliJ IDEA so all the parsing infrastructure and it it was awesome like parsing infrastructure IntelliJ IDEA is better than anything else in the world because it's it's the heart of the ID it has to be incredibly fast and very robust and so but then later someone who knew the infrastructure a lot better than I do. Uh had to factor that bit out to make the column compiler autonomous. And it was the Dmitry Jemerov who did that. And he's a awesome engineer. Like he's probably one of the best people to refactor a large code base and then like take this one bit out of something that that was already 10 plus years old back then. So we started with this ID plugin. I think Max wrote the scaffold and I actually plugged in the parser and everything. And that was that was an interesting story because it was very interactive. So I could show off the language as if it existed because it has had some tooling but I couldn't compile anything in the very beginning and that was was actually a very good way to experiment with the syntax but then soon after I started working on a full-fledged front end and on some translation and Dmitry and Alex Katchman were working on the back end. Everybody was part-time.

主持人: uh when you say you work on front end they work on back end in a language context what does that mean

Andre: it's slightly different in different languages but basically the front end is what deals with the syntax and with the checking and understanding what the program means and the back end is what translates to the executable code in our case u the front end is like reading the text and parsing and doing types and and all that and the back end generates Java bite code and cotlin has multiple backends for different target languages is like we have Java back end, we have a native back end for our uh like iOS and and other native platforms and JavaScript back end wasn't back. At that time, nobody was full-time working on this project. Even I was part-time a PhD student and part-time cotton developer. And it was like the very early days. And then at some point, I gave up my PhD and focused 100%. Which was also like it's a isn't it a a weird decision to start a new language part-time?

主持人: Yeah. Looking back, I was young and stupid.

Andre: Yeah. There's a saying that we didn't do it because it was easy. We did it because we thought it was easy.

Andre: Absolutely. that I didn't realize how hard the problem was. I was I also had an unreasonable amount of hubris. I just thought I I knew how to do everything. I didn't. But it worked out in the end.

主持人: So when the language started, what did you call it internally? There's always internal code names, right?

Andre: Right. Yeah. So u I don't think there was a discussion of this first name at all. It was just generally understood that the language will be named Jet and it was logical. So we had all the code base was uh using the name jet or we had a jet parser and you know jet editor or whatever jet highlighter something like that and then someone realized that the that the name was trademarked by someone else and it was actually people we we know there in Novaskin Russia doing something it's not a language it's a comp but it is a compiler um and we couldn't use it and this is When we started looking for another name, it was very painful.

Andre: Like looking for names, guys, this is so bad. It's one one of the worst things because you never know what name will work unless you want to do like an extensive study and then all the good names are taken of course and then some of the names that are not taken are not taken because they're not really googleable and you know some people are just very brave people who named their language go. This is why people now call it Golang because otherwise you can't identify it. It's it's it's a verb in English and very common one. Uh yeah, so we had weird options and I in one of my old old presentations I found a list of early names and we had robusta there as a flavor of co coffee and we had up for example or G or something else like that and those weren't great by that time. other languages were popping up and one of the alternative languages was was called son and the logic was that Java was the island of coffee and salon was an island of tea and uh Dmitry Jemerov basically looked out of the window and said okay we have an island here in St. Petersburg in the Gulf of Finland there's a big island called Scotland and it's a good name in the sense that it's very googable. Nobody uses it for anything. It's very recognizable. It's not super smooth for many languages, but it's kind of okay. Nobody was in love with that name.

Andre: And we were kind of hesitant and you know cot means a bad thing in German. And also there was like some some negative connotation in Mandarin I was told or something like that. you know it's always some language has some nasty association with any word and we basically were super hesitant so when we announced and we we had this deadline so we were basically putting this off when we announced we were still not sure so we called it we decided would be a code name we called it project cotlin uh to have a wiggle room to later replace the name but it stuck the first thing we we did we put out a uh basically a confluence page with a description of a language. It was just a bunch of wiki pages and there was no compiler available, no nothing. And there uh you know the the word cotlin appeared many many times. I was like my god this thing doesn't like I can't do search and replace and then change the name everywhere. So the workaround that I came up with was create an empty page called cotlin and it so it has a name and then everywhere else you mention it as a page and when you rename a page it gets renamed everywhere. So this is why there was an empty page called cotlin in that documentation. Uh but yeah the name stuck and it turns out to be not a bad name.

主持人: So when it started what were the main differences with cotlin compared to java because java was what was the big one? How how did you explain to developers uh you know who initially start on board or wanted to give it a go?

Andre: Yeah, I guess there were a few major selling points and then there were other things on top of that. When we started like in the very beginning, we didn't have uh null safety in mind. Null safety came a little later after one of the internal presentations. It was Maxurov who invited Roman Elizarov who later was the project lead for Cotlin. and Roman came and and listened to the presentation, gave some feedback and said like guys, if you want to do something really big for enterprise developers, figure out null safety and we did and it took a while. So, uh in the very beginning it was the general idea of like what makes Java feel so outdated and there there were a bunch of things. Lambdas were very big. The general like the general uh feeling from Java back then was it was very verbose. It was called the ceremony language. You know a lot of people were grumpy about too many keywords like public static void main is something everybody was really grumpy about. But also you know there were getters and setters for every property. There were you know constructors and overloads and all that stuff that looks like boiler plate because it is.

主持人: Yeah.

Andre: And you know

主持人: is super annoying to type out.

Andre: Yeah. and and you know the the problem with boilerplate is on the one hand it's annoying to type out but tools can generate it for you and fold it and so on so forth. Uh but the bigger problem is always readability. So reading is more important reading code is more important than writing code. We do a lot more of that and with boilerplate it's terrible because if some tiny thing is different in the middle of completely standard boilerplate code you'll miss it. you become blind to it and you you can debug for days not seeing them. So, you know, that that was the point of um sort of modernizing Java, making Java programs be more about what they do and less about the ceremony of making the compiler happy basically. And you know type inference was also a big thing because Java was repeating types a lot and many other things like that where like semicolons you know but the modern languages of the time already got rid of semicolons

主持人: and and so in cotlin you also got rid of it.

Andre: Yeah. Yeah. So we we got rid basically in terms of syntax we got rid of uh semicolons and duplicated types and that was a lot of noise of code.

主持人: What does it mean that Java had duplicated types?

Andre: Yeah. So in um that version of Java when you declare say a local variable you you say it's a list of string called strings equals new array list of string.

主持人: Oh yes I remember this one. Yes. Yes. You need to type it out twice and if you get one of them wrong compile error etc.

Andre: Right. So and at best uh you could omit the second mention of string by using a diamond operator but that only came later. you know, basically was very robust, especially if your types are long. Like if it's if it's just a list of string, it's sort of not so bad, but if it's a map from something to some to a list of string, for example, that's already really long and you don't want to read that. So, and a bunch of things like that were really annoying to a lot of people, especially compared to C# or Scala. So we we did all of that and then uh you know on top of that were there were other value add features and null safety was a big thing that we spend multiple years actually on implementing and I think it's one of the main differentiating factors now for cotlin alongside of with extensions and other things uh but null safety is one of the core features

主持人: and can can we just spell out why null safety is so big I mean I just today I came across a bug on the I I couldn't send a package because in JavaScript in the Dutch post website there's a null issue happening in production. Uh but you know like before cotlin and in a lot of languages why is it such a big problem? It is.

Andre: Yeah. So, u dealing with null references uh is a big hassle in most languages and I think it was uh Tony Hoare who um called called it the billiond dollar mistake at some point because like introducing I think it was about introducing uh null pointers to C or something. Uh so basically when we look at all the runtime errors that we have in Java code I think null pointer exceptions will be at the top. You know the type system of the of the language is supposed to protect you from those unexpected errors. So there are errors you're designed for and maybe errors that are not even your fault like you know file system error or something like that. But there are also um errors that should be prevented by the compiler. So for example, class cast class exception or missing method error for example are things that the compiler is trying to protect you for. It's trying to make sure that this never happens in your program if unless you you know switch off the check by making an enforced cast or something. Yeah.

主持人: And with nulls it's not a thing in Java like anything can be null and if it's null it will just fail.

Andre: Yeah. It throws an exception and dies.

主持人: It's a very common thing. So a lot of people are kind of used to it and there there are like different ways of being disciplined about it and so on so forth but basically this is a plague across any code base you know there there are different approaches to this and in cotlin we took the approach of a enforcing enforcing in the type system but also making it free at runtime.

主持人: What what does that mean that you made it free?

Andre: So one very common way of dealing with nulls is to use something like an option type where you have a box which might be empty or might have an object in it.

主持人: Yeah.

Andre: And that box is not free like you have to allocate it, you have to carry it around everywhere and you know this this easily creates a lot of objects in the old generation for the garbage collector. uh can be challenging and what we did was uh just have a direct reference at runtime. Our nullable or not null reference is the same as Java's reference. All we do is compile time checking and some runtime checking when we cross the boundary. But that's a lot cheaper than allocating objects. Although you know the runtime is getting better and they kind of can optimize some some of those objects away, but still like it's it's an overhead.

主持人: What what are features that you took in from Cotlin that were inspired by other languages that you admired?

Andre: A lot of them. I have an entire talk about this. It's called Shoulders of Giants and we uh really learned from lots and lots of languages and it was always the point.

主持人: Andre just mentioned how Cotlin was built on top of the shoulders of giants taking good ideas that existed not reinventing them. This was one of the reasons Cotlin succeeded as much as it did. But jumping forward from 2010 to 2026, one thing that is totally different today is the speed of things. AI is allowing nimble teams to build faster than ever before. Companies that used to take years to move into the enterprise are doing it in months. This speed creates a new problem. Enterprise requirements, authentication, security, access controls show up almost immediately. This is where Work OS, our season sponsor, comes in. Work OS is the infrastructure layer that helps AI companies handle that complexity without slowing down. SSO for enterprise buyers, MCP offer agendic workflows, even protection against free trial abuse with Radar. Teams like OpenAI, Cursor, Perplexity, and Vercel rely on Work OS to power identity and security as they scale. If you're building AI software and want to move fast and meet enterprise expectations, check out worker.com. With this, let's get back to Andre and how Cotlin was standing on the shoulders of giants.

Andre: So the slogan for Cotlin was pragmatic language for industry and the pragmatic bit which I mean is a nice uh sort of nice rhyme with with your podcast. Uh the pragmatic bit was kind of coming from the experience with Scala being called an academic language and a lot of people having trouble getting their heads around a lot of the very smart tricks in the design. And so so our idea was like we're not doing academic research here. We're not trying to invent anything. like if we don't get to invent anything it's a good thing not a bad thing and I think from the engineering perspective it's generally a good idea to to do this usually you end up making something new but the most of what you're doing shouldn't be very new because you want familiarity you want people to easily grasp what you're doing and this has to be familiar from other languages and also if you're taking you know building on top of the ideas of other languages you have the benefit of them having tried it and you can look at their designs and their community's reactions and and all that and the implications all over the place and that gives you a huge benefit. So we did a lot of that and I think the language that influenced cotlin the most is of course Java because you know we the entire runtime of cotlin is the JVM and we depend on that but apart from that Scala had a huge influence and and we used so many ideas from Scala from you know primary constructors and data classes and uh valves and varss and and all these things and to some interesting tricks about how generics work for example you know var Ians declarations is a great idea of Martians and it's a huge pity that it didn't uh make it into Java design. It was flipped at the very end of the design process to what Java has now and it's definitely the the Mart's idea was much better. We had to sort of on the boundary model Java boundary we had to fix the problem of Java having it different and figure that out. There were like many many ideas we took from Scala and that was very helpful and we usually we transformed those ideas a little bit to adapt to to our setting and to build on the knowledge of how it actually works in practice and we left some things out. We simplified some things. For example, Scala had traits and traits are a very powerful construct where it's it's it's like an interface and you can have method implementations uh in traits but also in Scala traits you could have fields as well properties that what what you couldn't have was um constructor arguments like you have always have a default constructor and can initialize all your fields and it's not as bad as multiple inheritance in C++ uh but it's still a little complicated when it comes to in what order you're calling the constructors that we decided we we don't want to deal with that it's a complex algorithm it's hard to explain let's just get rid of the state and interfaces and only have method bodies and I think it was a good compromise especially given that Java ended up in the same place it was easier to integrate yeah so Scala was a big influence uh C was a very big influence uh extensions of course and we learned quite a lot from how C# compilers do things. Uh there there was also one particular trick that makes uh Cotlin syntax a lot nicer, nicer than Javas and nicer than Scalas that we learned from C#. It was actually my colleague uh who worked on the C# ID who told me about this which is basically a super programmatic thing they do in C#. There is like when you call generic functions, you use uh angle brackets.

主持人: Yeah.

Andre: Uh inside an expression, but the thing is that there is no such thing as angle brackets. There is less and greater.

主持人: Mhm. Yeah.

Andre: Right. And and the parser can easily get conf confused and think that this expression since we're not in a type context, it's an expression context. This expression is a comparison. It's not uh an inequality, right? It's it's not a call. And this is mathematically unresolvable. It's it's an ambiguous grammar. Yeah, look, you can't do anything about it. And uh the way other languages handle this is Java, for example, when you're passing uh type arguments to a call, it has to be after a dot. So you say collections dot angle brackets. Yeah. The

主持人: function name.

Andre: Really awkward.

主持人: Kind of weird.

Andre: Yeah.

Andre: Uh and the way Scala deals with that, they use square brackets for types. And then arrays can't use square brackets, so they use round brackets, which is unfamiliar. Like it's not the end of the world. Scala is doing fine, but still like and C uses angle brackets because there's a hack in the parser that basically disambiguates ad hoc and we did the same or something very similar and it just works and the syntax is very familiar and very intuitive and we're very happy about when you read it. I as a as a person I never get confused like this is not a smaller sign like I know it's a yeah so most of the time it's not a practical problem um yeah and it's then there is a way to dismbiguate if if you like so C# was a big influence groovy was a big influence as well jet brains used um groovy for uh build scripts and there were incredibly useful patterns in in the groovy syntax that they call builders which is not about building programs but you know building objects and Uh this is what inspired something fairly novel that we did in Cotlin which was types builders where we had the same syntactic flexibility or almost the same syntactic flexibility as Groovy but it was all typed and we could make sure that all the arguments matched and so on so forth. So all that side basically was inspired by how groovy people did this and reworked into a typed setting. And this is why we have for example extension function types and this is why we have um dangling lambdas and other things that are actually very nice syntactic constructs. So yeah many many things uh came from different languages. A less known language called gou I think uh it was what inspired us to do smartcasts.

主持人: What are smart casts?

Andre: Oh yeah. So

Andre: I I think smart costs are one of the nicest things a compiler can do to a developer because it's a very common situation when you say if x is string so you do an instance of check basically then do something with x. The annoying thing is that in a lot of languages you have to cast x to string again like you've after you've done the the if you you know it's a string but then

主持人: you need to write it out again.

Andre: Yeah. So you've just done the check but you have to say string again

主持人: to make the compiler happy. So smart cast basically get rid of that. So that cast gets figured out automatically.

主持人: So if string and then inside the bracket you can now use it because it's a string. Yeah, you can use it as a string. And isn't it an easy thing, right?

Andre: So nice.

Andre: Yeah, it's it's a very nice thing. Yeah, it's a pretty complicated algorithm because you know variables can change values and the check that you've just made can go stale and you know there's a bunch of u algorithmic trickery around this and you can't do a smart guess on any expression has to be a certain type of expression that can be stable enough and so on so forth. But you know it's a very nice thing and you can get rid of so much noise in the code because like all the code in the world is riddled with this instance of cast instance of cast. So we wanted to get rid of that and it worked and it was fun to implement.

主持人: What were things that you looked at other languages you considered maybe we should bring it in but you after debate you're like no let's just let's just leave this out like not all of them obviously but some of the big ones that kind of came close.

Andre: We had a design for pattern match in Cotlin uh that was inspired by functional languages like like Scal and Haskell and and others. Uh but at some point it was early on when I was still working on the parser I just realized that this is a huge feature. So when when I was sketching it out on on a piece of paper it looked like a very useful thing you know and just another feature in the language. But then when I started working on the parts I realized it's an entire language in size like you have to create a parallel universe in syntax for pattern matching I was like okay this will be a lot of work let's postpone it and then later on uh when we were doing review for 1.0 Oh, or maybe a little earlier than that. I just realized that smart casts plus we have something called the structuring together they give us like 80% of all the good things pattern matching can do to normal developers. And then there is another group of developers that can be very vocal which are mostly compiler developers and people super into functional programming. uh and they have a point but that point is only relevant to them when there are not very many that we decided to not have pattern matching back then and you know maybe there comes a day that pattern matching gets added to cotlin

主持人: and pattern matching is is it in in the case

Andre: yeah it's

主持人: statement so you can have like a lot nicer case statements a lot more expressive ones right

Andre: yeah so generally uh so con has this compromise where you have our version of switch case which is called when and you can have smart costs there. So you can say like when my expression is a string and then use it as a string or it is a pair and then you can use it as a pair. So that kind of gives you a lot of the nicities of pattern matching but some things you can't express like and you know that was I think it was a good compromise because it's a really big feature. It's hard to design well that will would be a lot of work on the tooling side. So, you know, but maybe it gets in the road map one day. I'm not sure. Java is trying to get towards pattern matching. So, we'll see. Maybe they kind of make it more mainstream.

主持人: Why did you omit the infamous turnary operator which is when you write out something a question mark and a dot and it confuses new developers every single time if you've not seen it before.

Andre: Yeah.

主持人: Was it for readable reasons?

Andre: This is the saddest story I think the design of Cotlin. I didn't realize how much people liked it and yeah so so the reason was uh so cotlin used this principle from functional languages that everything we can make an expression is an expression. So if is not a statement and cotlin is an expression and the turnary operator is the sort of a patch on the design on on C and other C like languages that makes an if expression basically and the logic was okay we have if as an expression already can we just get rid of this extra syntax construct especially given that it's uh using very precious characters like there is a question mark and a colon and we might find some other use for that. So we decided to not have it. We used question marks for nullable things and colons for types and so forth. But it turned out that if uh as an expression is pretty verbose people don't like it and and like I I resisted for some time and then by the time I agreed it was too late because you can't retrofit the turnary operator and the current syntax in Cotlin because it just doesn't agree with how other operators are done.

主持人: So you're actually sad about it not being there a little bit.

Andre: Yeah, it's I think in retrospect it was a mistake because you know pragmatically it's more use than harm to have it but we just can't retrofit it.

主持人: What are some other interesting uh features that you like about the language that that you added that we could just explain for those who are not familiar?

Andre: Okay, so the the good ones there's quite a lot of them. So one feature that you know not is not a traditional kind of language feature is Java interperability. That's probably the single thing we spend the most time on. And I always say that you know if if someone offers you a job to create a system that interoperates transparently with another huge system you don't control, ask for a lot of money. It's a very tricky deal to to to figure this out.

主持人: Interpreter means that from cotlin you can invoke Java and from Java you can invoke cotlin and I mean you do a bunch of work there but it just works in the end as a developer you don't need to think about it.

Andre: Yeah. So the idea is whenever you have a Java library somewhere in the world you can always use it from cotlin and it was it was a big selling point uh because you know if if you start as just a language in a vacuum and you don't have any libraries that's not a good start in this direction definitely uh it was an absolute requirement for cotlin but also we had the requirement to go the other direction in an existing project you could just uh rewrite what parts of your code from Java to Cotlin and everything keeps working and some libraries actually did that and many projects started using Cotlin bit by bit uh you know a lot of people started with just writing tests but then you know you you start adding things uh in cotlin new things for example and all the Java code around that has to transparently use uh the cotlin code so we put a lot of effort into that and that was fun.

主持人: can you explain to us as as engineers like you know sounds like it was a freaking big project what what is the work right cuz from the outside again I'm just being your average developer where like all right I'm invoking okay I I'm invoking a Java class and things I can think of like well maybe you know Cotlin or Java doesn't support things in a certain way or or maybe but I mean is it really that hard what is hard tell me tell me I I'm dying to know

Andre: so one thing to note here is that We don't control the Java compiler. So we somehow need to make it work so that you in in your Java code you make a call into something that only exists in the Cotlin source and the Java compiler somehow agrees to call it to begin with. It's not a Java file. It doesn't know it exists. So the way it actually works is when we build a mixed project what we do is we first compile all the cotlin code and uh that can depend on the java sources in the in the project. So we have a java front end baked into the cotlin compiler so we can resolve everything in the java code and then we produce class files so binaries for the jvm that the java compiler can read. So when Java compiles it takes Cotlin sources as binaries and this is how it works. So you know the we would have to implement a Java compiler otherwise fortunately Java has separate compilation. So this works. So this trick means that you know whenever you have in your tooling like in in your ID for example when you navigate from Java sources to Cotlin sources has to be a special trick. So someone needs to go and teach the Java world to know about cotlin world. Of course the ID doesn't do the compilation to navigate. But in in the compilation time we don't control the compiler. So we we did our own ID. So we could do something about the uh Java tooling. But we couldn't do anything about the Java compiler. So that's trick number one. And then you know when it comes to incremental compilation it becomes even funnier because Java incremental compilation is a complex algorithm on its own. And now we're incrementally compiling two languages at once and that's fun. And you know incremental compilation algorithms are generally a very messy very complicated heristic that you have. So you know there are tons of corner cases and stuff. So that's that's like one example but then you know you start making interesting new things in cotlin. You need to expose them to Java. You need to make sure that whatever fancy thing you have, Java can actually interoperate with that. And one example there would be Cotlin. We figured out how to make Java collections nicer in Cotlin without rewriting the collections using the same library. So Java collections are what's called invariant because they're all readwrite. So if you have a list, it always has a set method.

主持人: Yep. And that's a little bit of a problem because whenever you have a list of object you cannot assign a list of string to that and that's a little annoying because you know you want to be able to represent a list of anything and that you need to play with question marks wild cards and stuff like that. It would be very nice if we had a readonly list interface that doesn't have a set methods and then there is no problem in assigning a subclass a list of subasses to a list of super classes but this interface doesn't exist at runtime right we can't just invented or can we so we we actually can

主持人: no

Andre: and so in the cotlin compiler we have this layer of trickery specifically for Java collections where cotlin always sees Java collection s like if they come from the Java world they are read write mutable collections we call them but

主持人: mutable right

Andre: yeah yeah yeah so so the Java collections are always mutable or

Andre: platform mutable I I'll talk about that later

Andre: uh but when you do it in cotlin you can actually distinguish between readonly mutable collections

Andre: and it's all very nice on the cotlin side but then when java sees the cotlin collections they are normal again like when we expose them through binaries the Java world always sees them as normal collections. They're mutable for Java and it's it's all right.

主持人: Okay. I'm I'm starting to see why it's you said like you need a lot of money for this because this is just one one of many things but this itself sounds like uh I don't know how you solve that.

Andre: Yeah. So so ju just to add a little bit of detail to this. So the nice thing about uh those predom collections is that you can pass a list of string for a list of object right wouldn't it be nice if a cotlin method that takes a list of list of any uh could accept a list of string in Java but aren't we erasing all the cotlin nice stuff we are but we know that this list is actually what's called covariant

Andre: so we can expose it to Java as a list of question mark extends and not just list of object. So you know it becomes coariant for the Java Java world as well and that's like one hack that makes it a little more transparent and there's a bunch of that. uh so you know so that's another thing that we had to play with but the biggest uh thing is of course nullable types and actually we we handle nullable types and these things with collections kind of similarly which makes the whole in typing layer of the interop quite interesting

Andre: but basically so Java doesn't know anything about nulls right and uh

主持人: well it knows about nulls but not not about nullable types it does not exist

Andre: yeah Java doesn't know about nulls at compile Yes.

Andre: So in terms of types, it's just not represented. So technically every Java type is a nullable type. And this is where we started. We said, okay, so Cotlin types can be not null and it's very convenient. And when you have a notnull type, you can just call a method on it normally, right? But if something is nullable, you can't just dreference it. You have to first check for null and then use it, right? Or there is a safe call operator question mark. Well, just propagate null if null is on the left hand side. So we started with saying okay all Java types are nullable which is a conservative like very mathematical way of treating this is correct right

主持人: yeah you you're not going to be wrong with that

Andre: yeah and we we implemented that and we started using it inside JetBrains and the feedback was horrible like your code is plagued with those null checks and you know that there shouldn't be there because you can't express anything on the Java side the right way and there were like we had some annotations for the Java side wasn't it was also brittle not always worked because you know there can be long chains and stuff and some some libraries just don't have the annotations and we struggled with that for a long time and basically we realized that this assumption that everything in Java has to be treated as nullable just doesn't work this this was a turning point where we sat down and re reimagined the whole thing and we worked with uh great uh type theory type practice I would say guy from I think it was back then he was in in Pernell Ross state. So Ross helped me figure out the sort of mathematical side of uh how you can represent those types that come from Java and should be like we should be aware of the that they they are from Java and can possibly be nullable but we shouldn't treat them as nullable because it was very inconvenient and Ross put together a very nice sort of calculus about those and when we started implementing it like all the nice things are gone.

Andre: the the actual yeah the mathematical beauty is completely gone from from from all that and I think we took the general idea of sort of splitting a type in two and everything else is just very messy industrial kind of thing that's not sound but it works well

主持人: okay and interpretably sounds like it was a journey but a necessary one how long did it take and can you give me just just a sense of of like how many people working on it how much cuz I think In traditional project we can get a sense but I have no idea with a language how does this work and how long did you think it would take versus how much it took.

Andre: Yeah. So so let's let's start with that. So every time I was asked when we were going to release cotton I would say one year from now.

主持人: Yep.

Andre: And you know this is this is not a plan. I had no idea. Had no idea. I also had the illusion that the initial version I was building was a prototype and we would write everything. And I I'm sure a lot of people out there have been there. I think that prototype has been rewritten more or less completely now, but it took six years, something like that. Yeah. So maybe longer actually.

Andre: Uh yeah. So so I had no idea and I always said like, okay, a year from now's far enough. We'll probably be done by then. Uh in practice, we we started in 2010. Yeah. autumn of 2010 basically. And we released in 2016, February 2016. So, you know, it was a long time, fiveish years.

Andre: And that uh you know, and in part it was just because I didn't know how to manage projects. And my initial team, the people who worked full-time on the project, I I looked up on GitHub to to to verify that everybody who almost everybody who joined JetBrains to work on Cotlin was a fresh graduate because I used to teach and I had some good students and I knew how to work with students. And so basically everybody on the team was a student apart from a few veterans from JetBrains who were were helping not all of them even full-time. So we started getting experienced engineers on the team a bit later. And you know to be fair a lot of those people you know people who are following Cotlin know those names. people who are core contributors who built out like absolutely foundational parts of cotlin joined as fresh graduates and they they became great engineers but I think I've I overdid it a little bit so it's great to have you know younger people have no fear and that's wonderful but you know the balance was not right

主持人: and how big was the team initially and then towards the release

Andre: so we started we started out basically with four four people part part-time and yeah we we went like that for maybe a year or something so the initial prototype was built like that and then people started joining in by the time we released I think it was around 25 people or something and the team grew quite a bit so by the time I left in 2020 it was about 100 people on the team 70 of them engineers

Andre: so it became a pretty big undertaking

主持人: can you tell us about the development process inside a language I I I think a lot of us are used to building you know like services backend services or or products or mobile apps etc. They typically have a release process. How does this work inside a language like what is your release process and what is the I guess best practices like do you even do code reviews or or you know like how can we imagine because again it feels such a rare project. There are people building languages but not many of them.

Andre: Yeah. So, one peculiar thing about building languages is what's called bootstrapping. When you write your compiler in your language,

主持人: oh, nice.

Andre: Which means that, you know, to compile your code, you need a previous version of your compiler and you better agree with your colleagues which version it is. It can be really tricky, especially when you do things about the binary format. And there is like quite a lot of bootstrapping magic going on. And I don't think it can reproduce the cotlin uh builds from scratch because you know if you just take a snapshot of the cotlin repo you can only build that with the cotlin compiler and I don't think we kept all the bootstrap versions.

Andre: Now I it might not be really possible without a lot of manual intervention to rebuild all the sources from the very beginning and reproduce all the versions because sometimes you know we we had to like commit a hack into a branch and use that branch as a bootstrap compiler for the next build and then throw the branch away. So that was like a oneoff compiler used to facilitate some change in in the binary format or syntax or something. Uh so that's a separate kind of fun but generally I mean many many practices are very similar like had code code reviews pretty early on. It's my personal quirk again that I like to talk to people. So in code reviews I often just sat together with someone and and either they reviewed my code or I reviewed theirs. But this is you know I can't argue that it's much better or or worse. It's just how I prefer because I like talking to people. So code reviews. Yes. And of course we we had an you know an issue tracker like everybody else. Ours was always open so everybody can submit bugs to the cause and bug tracker which was very helpful. Uh it's hard to manage because there will be like with usage there will be a lot of bugs and a lot of like feature requests and and all all kinds of stuff but it's worth it. You you have a communication channel. uh release cadence is a very difficult thing to figure out for such projects because one big consideration you have for languages is backwards compatibility. In part, this is what delayed 1.0

Andre: because we wanted to be reasonably sure we can maintain compatibility as soon as we call it 1.0. in part because it was the expectation especially Java is incredibly stable and very good with that until Java 9 came about and also Scala had a lot of trouble because they were breaking compatibility a lot and the community was struggling really so we really didn't want to repeat that but you know there turns out you can even break compatibility Python 2 to Python 3 and survive so you know

主持人: barely barely survive

Andre: They're doing very well now.

主持人: They're doing well. Yes.

Andre: Yeah. So we we were really serious about that. Uh but basically what it means is you start doing interesting things like deprecation cycles and so we we actually invented an entire tool set for compatibility management.

Andre: So before 1.0 we tried to help people migrate. So we we had those milestone builds. Embarrassingly, we had 13 of those

Andre: and uh you know when we broke the language in major ways we tried to provide tools for automatic migration.

主持人: That's nice of you.

Andre: Which was I don't think it was a standard practice in industry back then. Now people are doing it more. So I'm like very happy to have sort of popularized this idea. And then when we were preparing for 1.0, We did a major review of everything and took a year to sort of review all the design and what we're doing is basically trying to anticipate what changes we might want to make or what new features will require and to basically prohibit things that might block that. So we tried to make sure that the changes that we were planning were guarded well by compiler errors to make sure that users don't accidentally write anything that likes that looks like a new feature and that was fun like we had design meetings I think every day at some point basically working on that like okay let's outlaw this let's prohibit that and we prohibited a lot of stuff correctly and some stuff incorrectly uh but you know generally really worked out. So, so this compatibility thing was was a big deal, but there's also a lot of stuff that we didn't anticipate. So, we had to figure out ways to manage this. And there is something in Cotlin um in the Cotlin compiler called message from the future.

主持人: Mhm.

Andre: Which is basically

Andre: when in a newer version of a compiler, you introduce something that the old compiler doesn't understand. You have different options. And one option a lot of languages go for is the new kind of binary is in is completely unreadable for the old compiler. So the version is higher. I don't read it. That's it. I bail. But it's a little hard for people uh then to to manage their versions because new libraries new versions of libraries come with the new compiler expectations and you have to migrate your entire project to do that. It's a little annoying. And if what you're adding is like one method that basically invalidates the whole library for an old compiler, that's not great. So what we're doing, a newer compiler can write something into the binary that tells the old compiler, okay, this method is what you can't understand, but everything else is fine.

主持人: Oh, that's smart.

Andre: Yeah. So we call this a message from the future and like it can provide some details. So there's that and there's also um the discipline of experimental features which is incredibly helpful and I am very happy to see other languages doing it now and even Java does experimental features now which is wonderful.

主持人: Andre just talked about experimental features in programming languages and how that used to be rare back in the 2010s. What this reminded me is that running experiments in production used to also be rare. Not because teams did not want to do it, but because doing it meant building a lot of internal tooling around it. Assignment, rollouts, measurements, dashboard, debugging, the whole thing. For a long time, only a handful of companies really pulled this off at scale. Companies like Meta and Uber, which brings me to Static. Static is our presenting partner for the season. Stata gives engineering teams the tooling for experimentation and feature flagging that used to require years of internal work to build. Here's what it looks in practice. You ship a change behind a feature gate and roll it out gradually. Say to 1% or 10% of users at first. You watch what happens. Not just did it crash, but what did it do to the metrics you care about? Conversion, retention, error rates, latency. If something looks off, you turn it off quickly. If it's trending the right way, you keep rolling it forward. And the key is that the measurement is part of the workflow. You're not switching between three different tools and trying to match up segments and dashboards after the fact. Feature flags, experiments, and analytics are in one place using the same underlying user assignments and data. This is why teams and companies like Notion, Brex, and Atlassian use StatSik. Static has a generous free tier to get started and pro pricricing for Teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to stats.com/pragmatic. And with this let's get back to Andre and experimental features in cotlin.

Andre: So we did quite a lot of work you know when when you're doing something experimental this is something that's supposed to break and you want to emphasize this to make sure that the user is aware that you know this is something we are not promising to keep compatible. This is something we're going to break. And you know we we used to put the word experimental and package names for people to understand that this will going to is going to be renamed and you know warnings when you use language features and we require like compiler keys to enable language features and stuff like that and kind kind of helps. So we did quite a lot of that. So, so all of this is an extra layer. Unlike a SAS system for example, a compiler leaves behind not behind but creates a lot of artifacts that pin down its history in the wild. There is source out there and there are binaries out there and you're guaranteed to encounter them. Every time anyone hopes that no, this is an obscure case. Nobody will ever hit that. With enough users, you hit every freaking case.

Andre: And this is so surprising and I I discovered this fairly early on. I think before 1.0 when we had a few thousand users, I realized that if something's possible, some person out there will actually do it.

主持人: Now you you got 1.0 out. Can you tell me how Cotlin grew in popularity when you released it? What was your target audience? And then how did Android happen?

Andre: Okay, so that's that's a complicated story. Let's let's try to not get off track because this is like has a lot of side s side tracks to it. So when we started Cotlin, we were not really very aware of Android and I mean we knew that there was a thing called Android.

主持人: Kind of ironic.

Andre: Yeah.

主持人: From from now message from the future, right?

Andre: Yeah. So basically in 2010 we were focused on the majority of Java developers that was all about the server side.

主持人: Yep. I can clear.

Andre: Yeah. So the the most money Intelligj was making was on Spring users and you know everybody knew that this was what the Java platform was about by then. So we were targeting serverside developers basically and also desktop developers because JetBrains uh had the the probably the last desktop application written in Java or in at least in swing. So and that that was the target. It was initially not even a plan to do Android

Andre: and codlin like got some usage for the server side um and you know it's still there and it's growing there not as fast as on Android but still has some quite some representation on the server side but then a few years in some person on the internet asked us like whether cotlin works in Android and I was like I heard Android uses Java the cotlin should work. We never tried. Go and try. And I think it was the either the same user or a different user came back and said like the tool chain crashes. And it wasn't even the cousin to tool chain. It was the Android tool chain that crashed.

Andre: And you know, we looked into it and it turns out that it's some um some some tool in the Android tool chain that's written in C that just fails with the core dump and it's not very clear what's going on. And we later figured it out and it turned out that you know the Android developers and the people who built the Android platform, they actually read the spec of the JVM unlike the people who implemented the hotspot VM because the hotspot VM I suspect came before the spec. So it was the reference implementation but it was actually specified after it was built. So the hotspot VM was super lenient to weird things like that there would be like if we put a flag on a class file that was not allowed for classes hotspot wouldn't care and would we ran everything on hotspot and so we we thought everything was fine but then the Android side those were the people who actually read the spec

主持人: and they actually implemented it. Yeah, they would complain about everything and this is why we used Android tool chain as a testing uh environment basically because you know this is how we could get rid of stupid things in in our bite code and they helped us a lot with validating everything. But you know there were some gotchas there and some some legacy stuff nobody cares about in the mainstream Java just you know were faithfully implemented on the Android Android platform that that was fun. So you know and at some point pretty early on I think I had this realization that Android was a growing platform which to me then I I don't think I had a much of of understanding of you know dynamics of markets then but to me it meant that there will be a lot of new applications and it's much easier to start completely a new with a new language.

Andre: So I made sure at some point that we worked well in Android. It was already after the lawsuit. So you know the big context to all this was that when Oracle acquired Sun Microsystems they sued Google for billions of dollars for using Java and I think that is settled.

主持人: It it it was settled in some way. Yeah. And then everyone could go on their own way,

Andre: right? But uh it took years and years to settle. Yeah.

主持人: So back then it was very much a thing and you know so that dispute was somewhere in the background.

Andre: Uh but yeah so so basically we we saw that a lot of people on Android really liked cotlin

主持人: they they loved it.

Andre: Yeah as soon as it was stable pretty much. I mean I think for all the things that you mentioned right like it was just so much nicer than Java. Easier to write easier to read lots of nice features. So you know you use Android as as a way to actually you know make sure that Cotlin compiled correctly and then why did it take off on Android? Yeah. So the situation in Android was pretty interesting because unlike Java uh server side that you know is kind of under control of the teams that develop on it. uh in the case of Android there are devices in the pockets of people right and when you have and billions of those devices and those devices don't always update the virtual machine so people in Android were basically stuck with old Java

Andre: and even when Java started progressing and for example Java 8 came out in 2014 it was very difficult to roll out this new version of Java across the entire Android ecosystem because it required updates to the virtual machine and there were workarounds and retro lambda really helped and so on so forth but you know there was still a lot of people stuck with really old Java so Java wasn't you know on par with cotlin or C# uh in 2014 uh but it still was much better like and solved the major problem uh but it was not available to the Android people So there was a lot more frustration with Java in the Android community and also there was Swift on iOS.

主持人: Oh yeah.

Andre: Where you know it was a real example of a big ecosystem transitioning from a really dated language to something really nice.

主持人: Yep.

Andre: And I think compounding these two things were uh like the major factors. And also I mean we we made sure that cotlin worked well on Android. Also very fortunately at some point Google switched the developer tooling from the Eclipse platform to the Intelligj platform when Intelligj was open sourced back in I don't remember 2014 2013 I think or something like that. So, you know, it was we we had a nice plugin because uh everything worked on the Intelligj platform and the same plug-in worked for Android and many other things like were just very smooth. Well, very smooth. There were a lot of bugs but um reasonably smooth. So it felt like uh a very good match and a lot of people appreciated that and we really wanted to somehow draw the attention of the team at Google to you know maybe talk about it or something and it just didn't happen when so we released in 2016 and there was you know we we had some communication with Google in general but there was no interest in that side they're like okay we I guess we'll just keep going as we do and some people were already building Android applications

Andre: And well some people were building production applications in cotlin before we released 1.0 and you know uh kudos to the brave people because they gave us invaluable feedback but you guys are too brave. Yeah. So, you know, it just grew organically and when when we started in the very beginning. Uh I set this internal goal to myself uh that if we get to 100,000 users, it's a success. Like I've done well enough if it gets to 100,000. And of course, it's hard to tell how many users a language has, but you know, you can kind of estimate that. And I think we were on track to get to a 100 thousand users during 2016 because it it was growing. It was in the tens of thousands, you know, it looked good. But then uh some people from Google reached out and said they wanted to chat and it turned out they wanted to chat about announcing official support for Cotlin at Google I/O 2017. that would be in like 3 months from the time of that conversation. We were like, "Yeah, sure. Let's do it. What do we need to do?" And it turned out we we had to figure out quite a few things, but we managed. And I think it was a heroic effort on the side of the Google team. They did amazing things, impossible things there. And uh I have good friends um among them uh now. And it was like it was really really close like we we could have missed the deadline but we figured it out and yeah on our side also we had to make many things work and you know figure out how we now interoperate with Android Studio better and then you know how do we set up processes and and everything but there was like a big legal thing around it. uh this is when the Kotlin Foundation was invented and we had to design the protocols for decision-m the cot foundation and uh you know Google owned the trademark for cotlin for one year because of legal things it was basically a guarantee from the jet brain side u until the foundation gets set up uh so you you can look up the public record Google was in possession of the cotlin trademark for a year, but then the foundation was set up and was transferred to the foundation. So, you know, it it was it was fun. Uh it was pretty crazy time, but it was amazing to see how happy people were at Google I/O when the announcement happened. That was

主持人: and that usage must have skyrocketed. You you probably blew past 100,000 pretty quickly.

Andre: Yes. Yes, we I think we went Yeah, we probably got into millions that year. This is what was basically like the the moment happening and you know I knew many years before that I knew that the easiest way for a language to succeed is to be part of a platform and you know like C was part of Unix basically or like C# was part of Windows or JavaScript was part of the web platform and I I knew that Cotlin had no platform. So it was supposed to be much tougher time for cotlin than for some other languages but yeah the platform came along somehow.

主持人: Jumping forward to a lot more closer to today you you you have you left cotlin in 2020 later you left jet brains. What are you doing right now?

Andre: Yeah. So I'm also working on a language right now but it's sort of a different kind of language because the times have changed and you know you can you can look at it uh from a similar perspective like in Cotlin we wanted to get rid of boilerplate

Andre: we wanted to make programs more to the point and less of a ceremony and I think this is where we today we have a great opportunity to do the same thing at a different level

主持人: because of AI.

Andre: It's all because of AI.

Andre: Yes, AI is great because many things that are obvious to humans are obvious to LLMs as well, which closes this gap between what the machine can understand and what a human can understand quite a lot, which means we might not need to write dumb code anymore. That would be very nice. So on the one hand uh you know the the entire history of uh programming languages is going from lower to higher levels of abstraction. We started with machine codes then assembly was a step up actually assembly language is a higher level language and

主持人: than machine code. Okay. Yeah.

Andre: Yeah. And and and then C was a high level language back in the day. And then of course like managed languages like Java were a great step up and made programming a lot more accessible and and like teams could grow and you didn't have to be a super competent programmer to build working software and then you know things like cotlin built on top of um that success and we raised levels some more but now we can do even better in that so you can imagine uh like a normal program some some application code. A lot of the things in this code are obvious to you and to me. So if if you ask me to write this code, you don't spell everything out. You explain what the program needs to do and I can implement it and it will work the way you want. There there are, you know, it depends on how detailed the specification is, but you can tell me a lot less than you would have to tell a compiler.

主持人: Yeah.

Andre: Yeah. And so this is the point with code speak. We want to basically shrink the amount of information a programmer needs to tell the computer to make the program work. And from my current anecdotal experience, you can shrink a lot of the code about 10x

Andre: which means that you know a lot of projects out there can be a lot smaller and it will be a lot easier for humans to deal with that and a lot easier to read and reading is the most important bit and a lot easier to navigate and it becomes you know the essence of software engineering when you are not like dealing with the stupid compiler. You're not restricted by that anymore. What you're expressing is what only you know about what needs to happen because everything else the machine knows as well.

主持人: So can you tell me a bit more on what code speak is or what this language is? Is it designing an actual like kind of formal language just simpler? Is it using of course we know that that AI and LMS and agents can do all all the funky stuff. Where is this? What is this?

Andre: Okay. Yeah. Yeah. So I'll I'll try to explain this. So I think the best way of uh thinking about code speak is it's a programming language that based on English. It's not a formal language or not an entirely formal language but it's a programming language. It's a language that's supposed to be used by engineers but it uses LLMs heavily and uh this is like the way new languages will be because you know you can think about uh the ultimate language of today as a program normal programming language that uses an LLM as a library. You know there was a time where npm was wonderful because you know it's it's a huge repository of all kinds of JavaScript lie packet manager one of the biggest package in the world.

主持人: Right.

Andre: Right. Yeah. So you have a huge library out there that you can all but now you have an even better npm

Andre: the LLM that has seen all the code in the world and if you're inventive enough you can fish this code out of the LLM.

主持人: Yeah, you need to have to prompt, right?

Andre: Uh, and the trick is like it would be really nice to have a programming language that has the entire LLM as a library or as as a bag of libraries, right? The the trick is to take anything out of an LLM, you have to use natural language. So the query language to this incredible database of all the knowledge is informal and there is no way at least known today that you can make it formal. So inherently this ultimate language of today has to be at least in part informal

Andre: and this is what we're working on. So it's still in the air like how formal can we make it and you know it's it's not the goal to make it super restricted but the goal is to uh leverage all the power and support the user you know we need to rule out stupid mistakes and things like that and we're still working on that but the basic idea is uh if you instead of spelling out every line of code and every bit of your algorithm you can basically communicate intent the same way I can communicate to you, you will just get there much faster.

主持人: Mhm. So, one question that I asked Chris Latner uh was which I'm going to ask you as well. You're talking about designing a language for software engineers to build software more efficiently, maybe more concise and in a new way and it sounds super exciting. But going to the other side, we have LLMs. Do you think there is a need to design a new type of programming language for LLMs to use more efficiently?

Andre: That's a very interesting question and I had a few discussions about this. My position is it's probably misguided

Andre: because of a number of things. So one to get an LLM to understand some language well you need a huge training set and with the new language that training set is not there. You can try to synthesize it and so on forth but it's not going to be as good as other languages. Like for example, right now the newer languages are just harder for LLMs than the more established ones. Like any LLM writes Python better than it writes Rust or even Cotlin. Even the LMS who that write Java very well won't write co cotlin as well because it's not as present in the training set because it's younger and you know that there are ways around it and I think the later models like added some more codlin into the RL sets and it's getting better but still like it's pretty hard and so that's challenge number one also challenge number two I don't think there necessarily have to has to exist a language that makes it better because LLMs are trained on human language. Their knowledge of programming languages is part of that. Their power is in having been exposed to all the code in the world and it's existing code and inventing a new language for that. I don't know how promising that can be.

Andre: You can do another thing which is an interesting research project. you can sort of extract a language from an LLM because you know internally it has some intermediate representations of what's going on and during inference and maybe you can sort of extract a the optimal prompting language it's not guaranteed to be intelligible to humans and there are some experiments that show that you know you can create completely unintelligible prompts that give the same results as normal uh human prompts but they will be shorter.

Andre: You maybe you can do something like this. I don't know if it will help a lot. But what we're doing in code speak as part of uh working in this language we need to really nail down this query language capacity. And what we're doing now is we're looking at existing code and we're trying to find the shortest English descriptions for this code that can generate equivalent implementations. Not necessarily character to character, but they have to work the same way. And that's an interesting exercise because you need to figure out how to represent the ideas in the code in a way that a you can generate the same kind of code but the ideas you represented were a lot more compact but also this code you represent it evolves over time. Right? So you have a commit history on top of this version and so going forward in time you need to be able to represent all the changes in your uh codespeak version and you know you you need to make sure that when it's a small change in the original code the change in the spec is smaller that's an interesting challenge. So in this way we we're sort of discovering uh codespeak as a language or at least parts of it uh and not really designing that bit of it. You know it's it's a very new world in the sense that you know nowadays if you work with AI everything is a machine learning problem and that means you know back in the day if you had a very smart algorithm on paper you could just implement it and make sure it works.

Andre: Nowadays whatever algorithms you have in mind you need a data set first of all like if you don't know how to collect a data set don't even start and yeah this is what we're doing.

主持人: so just taking a a look at you you are using these tools day in day out I mean you're you're building with them how do you think programming as a whole or soft I'll say software engineering is being changed by by AI and how do you think the future is starting to look especially think about software engineers. You're a software engineer yourself. You you've you've written so much code in your life. And are you still writing code?

Andre: Yeah, I'm writing some code. Yeah. And uh

主持人: type sorry, typing or prompting?

Andre: Uh I'm doing both. I'm sometimes I'm just typing. Um more often I'm typing with cursor tab completion. I'm doing quite a lot of prompting as well. And you know that's a combination of of all this. But cursors completion is really a step up from traditional IDs. And I think the IntelliJ has something similar now. So it's it's like a lot of coding but in a very different kind of mindset and a different tool set. Yeah. So in terms of what's happening to programming, I think we are in the early days of the new era. So you know it's only last year that figured out that coding agents are good. Yeah.

主持人: Cloud Code and and cursor agent and so on so forth.

Andre: And I think this is a very early step. Right now we are in this phase where yeah a lot of people are in love with agents and they can be very useful and I use them every day. But I think there are there are inherent problems with the model with how you interact with a coding agent because it's a one-on-one chat and as a human I talk to the agent in human language. So I'm uh communicating my intent on a high level and that intent gets translated into code and it's the code that I commit to the repo and it's the code that my teammates will see. So my chat history is lost.

主持人: A big problem.

Andre: Yeah. So so it turns out I'm talking to a machine in a human language but the way I communicate with my team is the machine language. That's kind of backwards.

Andre: Uh so yeah so what we're trying to do in code speak is to elevate everything to the human language level. So this is this is where we start. We say okay we have this incredible tool we can prompt agents to implement code for us and we are just picking it up. So I think a lot of teams haven't yet realized how difficult it is to review all the code. And I've talked to people who are like maybe we can just not review this code. I'm like, "Yeah, I mean, you can for a couple of days and then it just collapses."

Andre: And I I think a another big theme uh of today is that we'll be doing a lot of testing and it like you may not need to review the code if your tests are really good.

主持人: You need to verify it, right? That's what you're saying is and verifying might not mean reviewing,

Andre: right? So,

主持人: or it could not mean

Andre: Yeah. depending on on the domain of course you you might get by without reviewing the code as much but being sure somehow either reviewing the test or somehow else making sure that your tests are good. That's a trend and and we are putting a lot of effort at C code speak into automated testing and making sure the tests actually check the right things and that they check all the code and all that stuff. That's very interesting computer science and also it's now a question of especially in the case of code speak and I think for other agents as well like yeah reviewing code can be too much but can we present the tests we generated to the user in a way that actually verifies that we did what what was to be done. It's tricky. some tests will be just very long and tedious to read and you know but we're working on that and that's that's what where we are and I think we'll we'll see a lot of development in terms of power of the models and we'll get some quote unquote obvious things implemented in agents for example the agents are just starting to use like language servers and basically all the stuff that we've always had for code is not very utilized And you know if you compare like ID integrated link u ID integrated agents like cursor or um juni at jet brains you have a lot of like code navigation capability and and you know databases of uh code is indexed and you can navigate it very quickly. You can find things very quickly. When you run cloud code for example it might not have that and use gp and it will be as successful but take a lot longer and burn a lot more tokens. So you know I I'm sure this year uh all these tools come to most agents and we'll have a lot more sophisticated scaffolding around the models. So that's that's one thing but then uh you know my question is always what's going to happen sort of in the end game or in further future and there it's it's very hard to predict and we can assume that models will become much smarter but important thing is that humans will not.

Andre: So one thing I know about the future and it's hard to know the future but this thing I do know about the future humans will be as smart or as dumb as they are today. And if we have incredibly smart models

Andre: uh what we will be doing is constrained by how humans are and and this is one of the reasons why I'm working on code because a tool for humans not for models.

主持人: Yeah.

Andre: And humans I know I can build a tool for them. I guess an important footnote is that many people will say things like you know if we have smart enough models they can review the code themselves and they can test the code themselves but then my question would be like who's making the decisions here you know if if all the software engineering work is done by models it means humans don't have any say in that and this has a name it's called technological singularity

主持人: when humans are not making decisions it means We're not in charge.

Andre: Yep.

Andre: So this is not the future I'm building codes speak for. Nobody should build any projects for that future. In that future, we're gone. Your projects don't matter. But so my assumption when I'm talking about the future is that the tech technological singularity is not happening. And so the the basic assumption is humans are in charge. And if humans are in charge, it's their job to communicate intent. So we have to say what kind of software we need to build. And when we're talking about like serious software, it's always complex. There's no way there's some very simple thing that will make a difference.

Andre: And when we talk talk about this complexity, this is what our jobs will be like dealing managing this complexity, figuring out what we actually need to do. And this is absolutely engineering. There is no way someone can tackle huge amounts of complexity without an engineer mindset. It can be called software engineering, can be called something else. But you will have to do it. You will have to navigate this complexity, organize this complexity, figure it out. And I'm not talking about the complexity of many many layers of implementation. Maybe not. Maybe that is what's called accidental complexity. Something that happens uh like or arises from how we implement systems. But there is also uh essential complexity. How we want it to behave is complex enough that we need to figure it out. And this is why I believe there will be teams of engineers working on systems like today. Maybe they will be a lot more powerful teams. Maybe fewer people can deliver a lot more software. Yes, but still teams of people working on organizing complexity. And this is what CodeSpeak is for. Going back to where we are today with what the models can do today,

主持人: what do you see with developer tools? It feels a little bit of a wild wild west right now.

Andre: Very much so. I mean there's a lot of you know obviously with clot code with cursor w with with with others but what are areas that you you think we will see we will have to see new different better tools to to actually just catch up with with how we can generate and what parts feel the most messy and the most interesting especially because at cotlin you have and the team has built so many tools for developers

Andre: right so I think uh as I already mentioned this year will be the year of making developer tools available to agents And there are some technical challenges, but you can figure it out. The people will be doing that. Uh there's also a surprising advantage to using a good UI for your agent. It's very nice to have everything in in your terminal in one sense, but then you can have a lot better user experience if it's a dedicated environment. And the terminal tools, especially Cloud Code, are amazing. And it's it's a complete breakthrough of what you can do in a terminal. But generally you you can do better in a specialized environment. So I think we'll see more of uh this integration into development environments or just uh new development environments built from the ground up to work with agents primarily. So that is an important thing. Uh since we are putting a lot more emphasis on review, uh there should be new tools for review and I think we can do better than what we're doing now. in many respects. I don't expect many breakthroughs in testing this year because it's hard. I'm I'm doing it right now. It's hard. It's not going to happen this year. But maybe some advances uh will arrive this year. But generally I think the the big lesson of the last couple of years is that all the things that were quote unquote obviously needed and you know the the idea of connecting agents to developer tools was absolutely the trivial thing to think of two years ago. But they take a long time to happen because it's hard and you know nobody's in this industry is lazy. like everybody's working their asses off but it just takes time you know you you need to figure out the basics before you can do advanced things so uh you know all the straightforward ideas will get implemented at some point.

主持人: I think there's been this massive jump with with AI especially over the winter break where where the coding agents the the CLIs have become a lot more capable and I know so many developers who are actually just prompting most of their code if not all of it is just a massive massive jump I don't think we've seen anything this fast I see a lot of engineers is scared because it can shake you to the bone. You know, it took 10 years to get really good at coding and the writing the code part feels that it's kind of going out, you know, the trash can. You you yourself have been coded for a longer time. What would your advice be for developers who are feeling like this that they're feeling, you know, it it it is scary. I think we and I I I talked with with some folks, a lot of people message me as well. How are you thinking about this specifically these these last few months?

Andre: It's really hard to give advice. There there are a few ideas I can share. So one thing is there's a lot of hype and a lot of it gets to the management and a lot of people make suboptimal decisions but that will go away. Uh so you know there's there's like more and more news about people not hiring junior developers for example. This is dumb.

主持人: It's stupid.

Andre: This is dumb. This is not going to stay for long. I mean, it's hard to tell how long this can go on, but people will figure out that they need new people in the industry and a lot of other things can be really stressful in the moment, but some of them will be rolled back. So, that's that's one thing. Another thing, it's absolutely worth it uh to to invest your time into learning these tools and getting good at it. There's a lot of skepticism around uh in the developer community about how useful it actually is and you know I tried it on my project it's then it's no good. There is quite a bit of skill to using these tools. Unfortunately it's not super formalizable. Uh at least so far nobody figured out a really good clear way of communicating how to do it well. But there are people who can do it much better than others. They not always can articulate why their prompts work better, but you know, you can learn it. You can get a lot better at it. And you know, not necessarily believing everyone on Twitter, you know, some people claim crazy things, but uh you can be very productive with these things when you use them well. And it's absolutely worth investing into that. And yeah, so as as I mentioned before, in the future, it will still be engineers building complex systems. So keep that in mind. It's not like we all go to nothing.

主持人: And for for new grads, people coming out of university, what would your advice be for them who are like determined like, "All right, I actually want to be a standout engineer. Maybe with these tools, I can do it faster." What would you advise them to focus on either skills or experiences to get?

Andre: I guess it's it's a matter of uh what your inclinations are. If you can just become incredibly productive and put out a lot of working code that is like really robust and you can evolve it for a long time, get good at that. And and like there is a lot to be done there. Uh if you can or like to do like harder things, go into the most hardcore things you can and get good at that because it will be your rare expertise. It will be marketable. Even if that very thing goes away, you will just become a lot smarter through that. So, you know, generally like if you have any inclination in looking under the hood and figuring out how things work, go as deep as you can. As a younger person, you have a lot of mental capacity for that. And this helps a lot. You become a very good expert in very wide fields just through, you know, drilling down on many things.

主持人: That's closing. I just wanted to do some rapid questions. I just ask and and you shoot what comes next. What is a favorite tool that you have? It can be digital. It doesn't have to be digital.

Andre: Well, I love my AirPods. They're they're incredibly convenient. They fit under my ear muffs. Well, another tool would be ear muffs. Earuffs.

主持人: Incredibly good.

主持人: Yeah, I saw you wearing it. I'll I'll take that one. Ear muff. And what's a book recommendation that you recommend and why?

Andre: There is this classic that's been recommended across the tech community for many years. Uh, it's called Zen and the Art of Moycle Maintenance.

主持人: I heard that recommended.

Andre: Yeah, it's a very good book. I mean, there is a part of it that's about technology and how to deal with the real systems and and others, but it's also a very good novel. I really like it.

主持人: Well, Andre, thank you so much. This was very interesting and I think inspiring as well.

Andre: Thank you very much. It was great a chat.

主持人: It was great. Thank you. The thing that struck me with most from this conversation with Andre was his observation about how we work with AI coding agents today. You talk to an agent in plain English. It generates code. You commit the code. But that conversation, your actual intent, it disappears. You communicate with the machine in human language, but we're your teammates in code in machine language. Whether or not code speaks the answer, what is sure that we're missing an intent layer? And someone is going to figure out how to preserve it. If you enjoy this episode, please do share with a colleague who's been thinking about where programming is headed. And if you're not subscribed yet, now's a good time. We have more conversations like this one coming. Thank you and see you in the next