The programming language after Kotlin – with the creator of Kotlin

17:47Andrey Breslav:Yeah, so, you know, there were crazy ideas as well.

17:50The Pragmatic Engineer hosts:And some of them just fall off over time as we were discussing or prototyping. And I think I started writing code maybe six months in or something like that. 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 IDE plugin. I have it in the editor first, which is, you know, an IDE plugin 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.

18:30The Pragmatic Engineer hosts:So all the parsing infrastructure, and it was awesome. Like, parsing infrastructure in IntelliJ IDEA is better than anything else in the world because it's the heart of the IDE. It has to be incredibly fast and very robust and so on. But then later, someone who knew the infrastructure a lot better than I do had to factor that bit out to make the Kotlin compiler autonomous. And it was Dmitry Zemirov who did that. And he's an 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 was already 10 plus years old back then.

19:05The Pragmatic Engineer hosts:So we started with this IDE plugin. I think Max wrote the scaffold and I actually plugged in the parser and everything. And that was an interesting story because it was very interactive. So I could show off the language as if it existed because it had some tooling, but I couldn't compile anything in the very beginning. And that was actually a very good way to experiment with the syntax. But then soon after I started working on a full-fledged frontend and on some translation and Dmitry and Alex Katchman were working on the backend, everybody was part-time.

19:40Andrey Breslav:When you say you work on frontend, they work on backend. In a language context, what does that mean?

19:44The Pragmatic Engineer hosts:It's slightly different in different languages, but basically the frontend is what deals with the syntax and with the checking and understanding what the program means and the backend is what translates to the executable code. In our case, the front end is like reading the text and parsing and doing types and all that and the backend generates Java bytecode. And Kotlin has multiple backends for different target languages like we have Java backend, we have a native backend for our like iOS and other native platforms and JavaScript

20:18Andrey Breslav:through backend, wasn't backend.

20:19The Pragmatic Engineer hosts:At that time, nobody was full-time working on this project. Even I was part-time, a PhD student, part-time Kotlin 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, isn't it a weird decision to start a new language part-time? Yeah. Looking back, I was young and stupid. Yeah.

20:44Andrey Breslav:There's a saying that we didn't do it because it was easy. We did it because we thought it was easy.

20:48The Pragmatic Engineer hosts:Absolutely that. I didn't realize how hard the problem was. I also had an unreasonable amount of hubris. I just thought I knew how to do everything. I didn't, but it worked out in the end.

21:03Andrey Breslav:So when the language started, what did you call it internally? There's always internal code names, right?

21:08The Pragmatic Engineer hosts:Right. Yeah. So I don't think there was a discussion of this first name at all. It was generally understood that the language will be named Jet, and it was logical. So we had all the code base was using the name Jet or we had JetParser and JetEditor or whatever, JetHighlighter, something like that. And then someone realized that the name was trademarked by someone else. And it was actually people we know, they're in the Novosibirsk in Russia, doing something, it's not a language, but it's a compiler. And we couldn't use it. And this is when we started looking for another name. It was very painful.

21:51The Pragmatic Engineer hosts:Like looking for names, guys, this is so bad. It's 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 Google-able. 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 a verb in English, a very common way. Yeah, so we had weird options. And in one of my old presentations, I found a list of early names.

22:30The Pragmatic Engineer hosts:And we had Robusta there as a flavor of 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 called Ceylon. And the logic was that Java was the island of coffee and Ceylon was an island of tea. And Dmitry Shemirov 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 Kotlin. And it's a good name in the sense that it's very Google-able. Nobody uses it for anything. It's very recognizable.

23:12The Pragmatic Engineer hosts:It's not super smooth for many languages, but it's kind of okay. Nobody was in love with that name. And we were kind of hesitant. And, you know, kot means a bad thing in German. And also there is like 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 had this deadline, so we were basically putting this off. When we announced, we were still not sure. So we decided it would be a code name. We called it Project Kotlin to have a wiggle room to later replace the name, but it stuck.

23:55The Pragmatic Engineer hosts:The first thing we did, we put out 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. I think. And there, you know, the word Kotlin 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 Kotlin. And 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 Kotlin in that documentation.

24:32The Pragmatic Engineer hosts:But yeah, the name stuck and it turns out to be not a bad name.

24:36Andrey Breslav:So when it started, what were the main differences with Kotlin compared to Java? Because Java was what was the big one. How did you explain to developers, you know, who initially started onboard or wanted to give it a go?

24:48The Pragmatic Engineer hosts: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 a null safety in mind. null safety came a little later after one of the internal presentations it was a max refiro who invited roman yalezarov who later was the project lead for kotlin and roman came 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 in the very beginning it was the general idea of like what makes java feel so outdated and 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 boilerplate because it is yeah and you know it's super annoying to type out yeah and you know 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 but the bigger problem is always readability so reading is more important reading code is more important than writing code.

26:23The Pragmatic Engineer hosts: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 can debug for days not seeing that. So, you know, that was the point of 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 were like semicolons. You know, the modern languages of the time already got rid of semicolons.

27:07Andrey Breslav:And so in Kotlin you also got rid of it?

27:10The Pragmatic Engineer hosts:Yeah, yeah. So we got rid, basically in terms of syntax, we got rid of semicolons and duplicated types and that was a lot of noise across the code. what does it mean that java had duplicated types yeah so in um that version of java when you declare say a local variable you say it's a list of string called strings equals new area list of string oh

27:34Andrey Breslav:yes i remember this one yes yes you need to type it out twice and if you get one of them wrong

27:38The Pragmatic Engineer hosts:compiler etc 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, it was very verbose, especially if your types are long. Like if it's just a list of string, it's sort of not so bad, but if it's a map from something 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-sharp or Scala. So we did all of that. And then, you know, on top of that, there were other value add features and null safety was a big thing that we spent multiple years actually on implementing.

28:24The Pragmatic Engineer hosts:And I think it's one of the main differentiating factors now for Kotlin alongside with extensions and other things. But null safety is one of the core features.

28:34Andrey Breslav:And can we just spell out why null safety is so big? I mean, just today I came across a bug. I couldn't send a package because in JavaScript, in the Dutch Post website, there's a null issue happening in production. But before Kotlin and in a lot of languages, why is it such a big problem? It is.

28:55The Pragmatic Engineer hosts:Yeah, so dealing with null references is a big hassle in most languages. and I think it was Tony Hoer who called it the billion-dollar mistake at some point because like introducing, I think it was about introducing null pointers to C or something. 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 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 a file system error or something like that.

29:38The Pragmatic Engineer hosts:But there are also errors that should be prevented by the compiler. So for example, class cast 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 unless you switch off the check by making an enforced cast or something. And with nulls, it's not a thing in Java. Like anything can be null. And if it's null, it will just fail.

30:05Andrey Breslav:It throws an exception and program dies.

30:07The Pragmatic Engineer hosts:It's a very common thing. So a lot of people are kind of used to it. And there are like different ways of being disciplined about it and so on and so forth. But basically, this is a plague across any code. You know, there are different approaches to this. and in Kotlin we took the approach of A, enforcing it in the type system, but also making it free at runtime.

30:32Andrey Breslav:What does that mean, that you made it free?

30:34The Pragmatic Engineer hosts: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. And that box is not free. Like, you have to allocate it, you have to carry it around everywhere, and And this easily creates a lot of objects in the old generation for the garbage collector. So it can be challenging. And what we did was 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.

31:16The Pragmatic Engineer hosts:Although the runtime is getting better and they kind of can optimize some of those objects away. bit stealth. It's an overhand.

31:24Andrey Breslav:What are features that you took in from Kotlin that were inspired by other languages that you admired?

31:29The Pragmatic Engineer hosts:A lot of them. I have an entire talk about this. It's called Shoulders of Giants. And we really learned from lots and lots of languages. And it was always the point.

31:41Andrey Breslav:Andrei just mentioned how Kotlin was built on top of the shoulders of giants, taking good ideas that existed, not reinventing them. This was one of the reasons Kotlin 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 WorkOS, our seasoned sponsor, comes in.

32:15Andrey Breslav:WorkOS is the infrastructure layer that helps AI companies handle that complexity without slowing down. SSO for enterprise buyers, MCP offer agenda workflows, even protection against free trial abuse with radar. Teams like OpenAI, Cursor, Perplexity and Vercel rely on WorkerWars 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 WorkerWars.com. With this, let's get back to Andrei and how Kotlin was standing on the shoulders of giants. So the slogan for Kotlin was pragmatic language for industry.

32:48The Pragmatic Engineer hosts:And the pragmatic bit, which, I mean, is a nice sort of nice rhyme with your podcast. 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 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 do this. Usually you end up making something new.

33:24The Pragmatic Engineer hosts:But 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 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 Kotlin the most is, of course, Java, because, you know, the entire runtime of Kotlin is the JDM and we depend on that.

34:03The Pragmatic Engineer hosts:But apart from that, Scala had a huge influence and we used so many ideas from Scala from, you know, primary constructors and data classes and VALs and VARs and all these things and to some interesting tricks about how generics work, for example, you know, variants, declarations-type variants, is a great idea of Martians. And it's a huge pity that it didn't 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 Martians idea was much better. we had to sort of on the boundary on the 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 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 like an interface, and you can have method implementations in traits, but also in Scala traits, you could have fields as well, properties, that what you couldn't have was constructor arguments.

35:29The Pragmatic Engineer hosts:Like, you have always have a default constructor, and can initialize all your fields, and it's not as bad as multiple inheritance and so plus plus but it's still a little complicated when it comes to in what order you're calling the constructors that we decided 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 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 sharp was a very big influence extensions, of course, and we learned quite a lot from how C Sharp compilers do things.

36:12The Pragmatic Engineer hosts:There, there was also one particular trick that makes Kotlin syntax a lot nicer, nicer than Java's and nicer than Scala's, that we learned from C Sharp. And it was actually my colleague who worked on the C Sharp IDE who told me about this, which is basically a super pragmatic thing they do in C Sharp. there is like when you call generic functions you use angle brackets inside an expression but the thing is that there is no such thing as angle brackets there is less and greater yeah right and and the parser can easily get confused and think that this expression since we're not in type context it's an expression context this expression is a comparison it's not an inequality, right?

36:57The Pragmatic Engineer hosts:It's not a call. And this is mathematically unresolvable. It's an ambiguous grammar. Yeah, look, you can do anything about it. And the way other languages handle this is Java, for example, when you're passing type arguments to a call, it has to be after a dot. So you say collections dot angle brackets, function name, which is kind of weird. yeah uh and the way scala deals with that they use square brackets for types and then arrays

37:29Andrey Breslav:can't use square brackets so they use round brackets which is unfamiliar like it's not the

37:36The Pragmatic Engineer hosts:end of the world scala is doing fine but still like and c sharp 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

37:54Andrey Breslav:we're very happy about that when you read it i as a person i never get confused like this is not a smaller sign like i know it's a genesis yeah yeah so most of the time it's not a practical problem

38:04The Pragmatic Engineer hosts:um yeah and it's then there is a way to disambiguate if you if you like so c sharp was a big influence groovy was a big influence as well jetbrains used groovy for build scripts and there were incredibly useful patterns in the Groovy syntax that they call builders, which is not about building programs, but building objects. And this is what inspired something fairly novel that we did in Kotlin, which was types builders, where we had the same syntactic flexibility or almost the same syntactic flexibility as Groovy, but it was all types and we could make sure that all the arguments matched and so on and so forth.

38:43The Pragmatic Engineer hosts: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 dangling lambdas and other things that are actually very nice syntactic constructs so yeah many many things came from different languages a less known language called Gosu, I think it was what inspired us to do smartcasts.

39:11Andrey Breslav:What are smartcasts?

39:12The Pragmatic Engineer hosts:Oh, yeah. So I think smartcasts 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

39:38Andrey Breslav:like you've done the check you know it's a string but then you need to write it out again

39:44The Pragmatic Engineer hosts:yeah so you've just done the check but you have to say string again to make the compiler happy so smartcasts basically get rid of that so that cast gets figured out automatically

39:55Andrey Breslav:if that's a string and then inside the bracket you can now use it because it's a string

40:00The Pragmatic Engineer hosts:you can use it as a string and isn't it an easy thing, right? So nice. Yeah, it's a very nice thing. 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 algorithmic trickery around this and you can't do a smart gas on any expression. It has to be a certain type of expression that can be stable enough and so on and 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.

40:36The Pragmatic Engineer hosts:So we wanted to get rid of that. And it worked. And it was fun to implement.

40:41Andrey Breslav: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 leave this out. Like not all of them, obviously, but some of the big ones that kind of came close.

40:54The Pragmatic Engineer hosts:We had a design for pattern matching Kotlin that was inspired by functional languages like Scala and Haskell and others. 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 I was sketching it out 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 parser, I realized it's an entire language in size. Like you have to create a parallel universe in syntax for pattern matching. And I was like, okay, this will be a lot of work. Let's postpone it.

41:35The Pragmatic Engineer hosts:And then later on, when we were doing review for 1.0 or maybe a little earlier than that, I just realized that smart casts plus we have something called destructuring, 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. And they have a point, but that point is only relevant to them and 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 Kotlin.

42:18Andrey Breslav:And pattern matching, is it in the case?

42:21The Pragmatic Engineer hosts:Yeah, it's...

42:22Andrey Breslav:So you can have like a lot nicer case statements, a lot more expressive ones, right?

42:26The Pragmatic Engineer hosts:Yeah, so generally, so Kotlin 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 niceties of pattern matching, but some things you can't express like that. 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. There would be a lot of work on the tooling side. So, you know, but maybe it gets in the roadmap one day.

43:05The Pragmatic Engineer hosts:I'm not sure. Java is trying to get towards pattern matching. So we'll see. Maybe they kind of make it more mainstream.

43:12Andrey Breslav:Why did you admit the infamous ternary operator, which is when you write out something, the question mark and the dot, and it confuses new developers every single time if you've not seen it before? Yeah. Was it for readable reasons?

43:24The Pragmatic Engineer hosts:This is the saddest story, I think, in the design of Kotlin. I didn't realize how much people liked it. And yeah, so the reason was, so Kotlin used this principle from functional languages that everything we can make an expression is an expression. So if is not a statement, Kotlin is an expression. And the ternary operator is the sort of a patch on the design 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 using very precious characters?

44:08The Pragmatic Engineer hosts: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 the colons for types and so forth. But it turned out that if, as an expression, it's pretty verbose, people don't like it. And I resisted for some time, and then by the time I agreed, it was too late because you can't retrofit the ternary operator and the current syntax in Kotlin because it just doesn't agree with how other operators have done.

44:40Andrey Breslav:So you're actually sad about it not being there a little bit?

44:43The Pragmatic Engineer hosts: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.

44:54Andrey Breslav:What are some other interesting features that you like about the language that you added that we could just explain for those who are not familiar?

45:02The Pragmatic Engineer hosts:Okay, so the good ones, there's quite a lot of them. So one feature that, you know, is not a traditional kind of language feature is Java interoperability.

45:14Andrey Breslav:That's probably the single thing we spend the most time on.

45:19The Pragmatic Engineer hosts:And I always say that, you know, 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 figure this out.

45:36Andrey Breslav:And interpreter means that from Kotlin, you can invoke Java. And from Java, you can invoke Kotlin. 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.

45:46The Pragmatic Engineer hosts:Yeah. So the idea is whenever you have a Java library somewhere in the world, you can always use it from Kotlin. And it was a big selling point. Because, you know, 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 it was an absolute requirement for Kotlin but also we had the requirement to go the other direction in an existing project you could just rewrite parts of your code from Java to Kotlin and everything keeps work and some libraries actually did that and many projects started using Kotlin bit by bit you know a lot of people started with just writing tests but then you know you you start adding things uh in Kotlin new things for example and all the java code around that has to transparently use uh the Kotlin code so we put a lot of effort into that and that was fun can you explain to us as as

46:47Andrey Breslav:engineers like you know it sounds like it was a freaking big project what what is the work right because from the outside again I'm just being your average developer we're like all right I'm invoking okay I'm invoking a Java class and things I can think of like well maybe you know Kotlin or Java doesn't support things in a certain way or maybe but I mean is it really that hard what is hard

47:10The Pragmatic Engineer hosts:tell me tell me I'm dying to know 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 your Java code you make a call into to something that only exists in the Kotlin 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 Kotlin code and that can depend on the Java sources in the project. So we have a Java front end baked into the Kotlin compiler so we can resolve everything in the Java code.

47:55The Pragmatic Engineer hosts:and then we produce class files, so binaries for the JVM that the Java compiler can read. So when Java compiles, it takes Kotlin sources as binaries. And this is how it works. So, you know, 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 your ID, for example, when you navigate from Java sources to Kotlin sources has to be a special trick. So someone needs to go and teach the Java world to know about Kotlin world. Of course, the ID doesn't do the compilation to navigate.

48:36The Pragmatic Engineer hosts:But in the compilation time, we don't control the compiler. So we did our own ID. So we could do something about the 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 are incrementally compiling two languages at once. And that's fun. And, you know, incremental compilation algorithms are generally a very messy, very complicated heuristic that you have. So, you know, there are tons of corner cases.

49:10The Pragmatic Engineer hosts:So that's like one example. But then, you know, you start making interesting new things in Kotlin. 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 Kotlin. We figured out how to make Java collections nicer in Kotlin without rewriting the collections using the same library. So Java collections are what's called invariant because they're all read-write. So if you have a list, it always has a set method. 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.

49:53The Pragmatic Engineer hosts:And that's a little annoying because you want to be able to represent a list of anything and you need to play with question marks,

50:02Andrey Breslav:wildcards and stuff like that.

50:03The Pragmatic Engineer hosts:It would be very nice if we had a read-only list interface that doesn't have a set method and then there is no problem in assigning a list of SAP classes to a list of superclasses. But this interface doesn't exist at runtime, right we can't just invent it or can we so we actually can no and so in the Kotlin compiler we have this layer of trickery specifically for Java collections where Kotlin always sees Java collections like if they come from the Java world they are read write mutable collections we call them but mutable right yeah yeah so so the Java collections are always mutable or platform mutable I'll talk about that later.

50:48The Pragmatic Engineer hosts:But when you do it in Kotlin, you can actually distinguish between read-only mutable collections and it's all very nice on the Kotlin side. But then when Java sees the Kotlin 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 all right.

51:07Andrey Breslav:Okay, I'm starting to see why you said like you need a lot of money for this because this is just one of many things, but this itself sounds like, I don't know how you solved that.

51:18The Pragmatic Engineer hosts:Yeah, so just to add a little bit of detail to this. So the nice thing about those read-only collections is that you can pass a list of string for a list of object, right? Wouldn't it be nice if a Kotlin method that takes a list of any could accept a list of string in Java? But aren't we erasing all the Kotlin nice stuff? we are but we know that this list is actually what's called covariant so we can expose it to java as a list of question mark extends and not just list of objects so you know it becomes covariant 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 so you know so that's another thing that we had to play with.

52:09The Pragmatic Engineer hosts:But the biggest thing is, of course, nullable types. And actually, we handle nullable types and these things with collections kind of similarly, which makes the whole typing layer of the interop quite interesting. But basically, so Java doesn't know anything about nulls, right?

52:28Andrey Breslav:Well, it knows about nulls, but not about nullable types. It does not exist. Yeah, Java

52:33The Pragmatic Engineer hosts:doesn't know about nulls at compile time. 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 Kotlin types can be not null, and it's very convenient. And when you have a not null type, you can just call a method on it normally, right? But if something is nullable, you can't just dereference it. You have to first check for null and then use it, right? Or there is a save call operator, question mark, dot, 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're not going to be wrong with that 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 they 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 it wasn't it was also brittle and not always worked because, you know, there can be long chains and stuff.

53:37The Pragmatic Engineer hosts: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, it just doesn't work. This, this was a turning point where we sat down and re re-imagined the whole thing. And we worked with a great type theory type practice, I would say guy from, I think it back then he was in Cornell, Ross State. So Ross helped me figure out the sort of mathematical side of how you can represent those types that come from Java and should be, like we should be aware of that they are from Java and can possibly be nullable, but we shouldn't treat them as nullable because it was very inconvenient.

54:24The Pragmatic Engineer hosts: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. The actual, yeah, the mathematical beauty is completely gone 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.

54:53Andrey Breslav:Okay. And interoperatively sounds like it was a journey, but a necessary one. How long did it take? Can you give me just a sense of like how many people working on it? how much because I think in traditional project we can get a sense but I have no idea with the language how does this work and how long did you think it would take versus how much it took

55:11The Pragmatic Engineer hosts:so let's start with that so every time I was asked when we were going to release Cuddle I would say one year from now and you know this is this is not a plan I had no idea I also had the illusion that the initial version I was building was a prototype and we 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. So, yeah, so I had no idea. And I always said, like, OK, a year from now feels far enough. We'll probably be done by then. In practice, we started in 2010.

55:58The Pragmatic Engineer hosts:Yeah, autumn of 2010, basically. And we released in 2016, February 2016. So, you know, it was a long time, five-ish years. And that, you know, in part 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 looked up on GitHub to verify that. Everybody who, almost everybody, who joined JetBrains to work on Kotlin 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 helping, not all of them even full-time.

56:49The Pragmatic Engineer hosts: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 Kotlin know those names. People who are core contributors, who built out like absolutely foundational parts of Kotlin, joined as fresh graduates. And they became great engineers. But I think 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.

57:25Andrey Breslav:And how big was the team initially and then towards the release?

57:28The Pragmatic Engineer hosts:So we started out basically with four people part-time. And, yeah, 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. So it became a pretty big undertaking.

57:58Andrey Breslav:Can you tell us about the development process inside language? I think a lot of us are used to building, you know, like services, back-end services 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, 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.

58:26The Pragmatic Engineer hosts:Yeah, so one peculiar thing about building languages is what's called bootstrapping when you write your compiler in your language.

58:36Andrey Breslav:Oh, nice.

58:37The Pragmatic Engineer hosts: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 Kotlin builds from scratch. Because, you know, if you just take a snapshot of the Kotlin repo, you can only build that with a Kotlin compiler. And I don't think we kept all the bootstrap versions. So 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.

59:20The Pragmatic Engineer hosts:because sometimes, you know, 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 one-off compiler used to facilitate some change in the binary format or syntax or something. So that's a separate kind of fun. But generally, I mean, many, many practices are very similar, like had 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 either they reviewed my code or I reviewed theirs. But this is, you know, I can't argue that it's much better or worse.

1:00:02The Pragmatic Engineer hosts:It's just how I prefer it because I like talking to people. So code reviews, yes. And of course, we had an issue tracker like everybody else. Ours was always open. So everybody can submit bugs to the Kotlin bug tracker, which was very helpful. It's hard to manage because there will be like with usage, there will be a lot of bugs and a lot of feature requests and all kinds of stuff. But it's worth it. You have a communication channel. 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 because we wanted to be reasonably sure we can maintain compatibility as soon as we call it 1.0.

1:00:50The Pragmatic Engineer hosts: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, it turns out You can even break compatibility Python 2 to Python 3 and survive. So, you know. Barely. Barely survive. They're doing very well.

1:01:21Andrey Breslav:Now they're doing well, yes.

1:01:22The Pragmatic Engineer hosts:Yeah. So we were really serious about that. But basically what it means is you start doing interesting things like deprecation cycles. And so we actually invented an entire tool set for compatibility management. so before 1.0 we tried to help people migrate so we had those milestone builds embarrassingly we had 13 of those and you know when we broke the language in major ways we tried to provide tools for automatic migration that's nice of you 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.

1:02:04The Pragmatic Engineer hosts:And then when we were preparing for 1.0, we did a major review of everything and took a year to sort of view 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 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.

1:02:49The Pragmatic Engineer hosts:And we prohibited a lot of stuff correctly and some stuff incorrectly, but generally worked out. So this compatibility thing was a big deal. 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 kotlin in the kotlin compiler called message from the future which is basically 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 completely unreadable for the old compiler. So the version is higher.

1:03:31The Pragmatic Engineer hosts:I don't read it. That's it. I bail. But it's a little hard for people then 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.

1:04:06Andrey Breslav:Wow, that's smart.

1:04:07The Pragmatic Engineer hosts:Yeah, so we call this a message from the future, and it can provide some details. So there's that, and there's also 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.

1:04:24Andrey Breslav:Andrei 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 Statsig. Statsig is our presenting partner for the season. static 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.

1:05:02Andrey Breslav: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.

1:05:34Andrey Breslav:This is why teams and companies like Notion, Brex, and Atlassian use Statsig. Statsig has a generous free tier to get started and pro pricing for teams starts at$150 per month. To learn more and get a 30-day enterprise trial, go to statsig.com slash pragmatic. And with this, let's get back to Andre and experimental features in Kotlin.

1:05:53The Pragmatic Engineer hosts:So we did quite a lot of work, you know, 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 used to put the word experimental and package names for people to understand that this will gonna is gonna 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 it kind of kind of helps so we did quite a lot of that so so all this is an extra layer unlike a sas system for example a compiler leaves behind but not behind but creates a lot of artifacts that pin down its history in the world there is source out there and there are binaries out there and you're guaranteed to encounter them.

1:06:49Every time anyone hopes that,

1:06:52The Pragmatic Engineer hosts:no, this is an obscure case, nobody will ever hit that. With enough users, you hit every freaking case. And this is so surprising. And 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,

1:07:12Andrey Breslav:some person out there will actually do it now you you got 1.0 out can you tell me how Kotlin grew in popularity when you released it what was your target audience and then how did

1:07:26The Pragmatic Engineer hosts:Android happen 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 side tracks to it so when we started Kotlin we were not really

1:07:38Andrey Breslav:very aware of Android. And I mean, we knew that that was a thing called Android. Kind of ironic. Yeah. From now, message from the future.

1:07:48The Pragmatic Engineer hosts:Right. Yeah, so basically in 2010, we were focused on the majority of Java developers that was all about the server side. Yep, clear. Yeah, so the most money IntelliJ was making was on string users. And, you know, everybody knew that this was what the Java platform was about by then. So we were targeting server-side developers, basically, and also desktop developers because JetBrains had probably the last desktop application written in Java, or at least in swing. So that was the target. It was initially not even a plan to do Android. And Kotlin got some usage for the server side and, you know, it's still there and it's growing there, not as fast as on Android, but still has quite some representation on the server side.

1:08:45The Pragmatic Engineer hosts:But then a few years in, some person on the internet asked us whether Kotlin works in Android. And I was like, I heard Android uses Java, so Kotlin should work. We never tried. go and try and i think it was the either the same user or different user came back and said like the tool chain crashes and it wasn't even the cotton tool chain it was the android tool chain that crashed 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 we ran everything on hotspot and so we thought everything was fine but then the android side those were the people

1:10:15Andrey Breslav:who actually read the spec and they actually implemented it yeah they would complain about

1:10:19The Pragmatic Engineer hosts:everything. And this is why we used Android toolchain as a testing environment, basically, because, you know, this is how we could get rid of stupid things in our bytecode. And they helped us a lot with validating everything. But, you know, there were some gotchas there and some legacy stuff nobody cares about in mainstream Java just, you know, were faithfully implemented on the Android platform. 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 don't think I had much of understanding of, you know, dynamics of markets then.

1:11:06The Pragmatic Engineer hosts: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. So I made sure at some point that we worked well on 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.

1:11:34Andrey Breslav:It was settled in some way. And then everyone could go on their own way.

1:11:39The Pragmatic Engineer hosts:Right. But it took years and years to settle. So back then, it was very much a thing. And, you know, so that dispute was somewhere in the background. But, yeah, so basically we saw that a lot of people on Android really liked Kotlin.

1:11:55Andrey Breslav:They loved it.

1:11:56The Pragmatic Engineer hosts:Yeah.

1:11:57Andrey Breslav: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 a way to actually, you know, make sure that Kotlin compiled correctly. And then why did it take off on Android?

1:12:14The Pragmatic Engineer hosts:Yeah, so the situation in Android was pretty interesting because unlike Java server side that, you know, is kind of under control of the teams that develop on it. In the case of Android, there are devices in the pockets of people, right? And when you have billions of those devices, and those devices don't always update the virtual machine. so people in Android were basically stuck with old Java 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 and 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 kotlin or c-sharp uh in 2014 uh but it still was much better like and solved the major problem but it was not available to the android people so there was a lot more frustration with Java in the Android community.

1:13:31The Pragmatic Engineer hosts:And also, there was Swift on iOS. Oh, yeah. Where, you know, it was a real example of a big ecosystem transitioning from a really dated language

1:13:44Andrey Breslav:to something really nice. Yep.

1:13:47The Pragmatic Engineer hosts:And I think compounding these two things were, like, the major factors. And also, I mean, we made sure that Kotlin worked well on Android. also very fortunately at some point google switched the developer tooling from the eclipse platform to the intellij platform when intellij was open sourced back in i don't remember 2014 2013 i think or something like that so you know it was we had a nice plugin because everything worked on the intellij platform and the same plugin worked for android and many other things like were just very smooth well very smooth there were a lot of bugs but reasonably smooth so it felt like 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 just didn't happen when so we released in 2016 and there was you know we had some communication with Google in general, but there was no interest in that side.

1:14:52The Pragmatic Engineer hosts:They're like, okay, we, I guess we'll just keep going as we do. And some people were already building Android applications. And well, some people were building production applications in Kotlin before we released 1.0. And, you know, kudos to the brave people because they gave us invaluable feedback, but you guys are too brave.

1:15:13Andrey Breslav:Yeah, so, you know, it just grew organically.

1:15:16The Pragmatic Engineer hosts:And when we started in the very beginning, I set this internal goal to myself 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 the language has, but, you know, you can kind of estimate that. and I think we were on track to get to 100 ,000 users during 2016 because it was growing, it was in the tens of thousands, you know, it looked good. But then 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 Kotlin at Google I.O.

1:16:05The Pragmatic Engineer hosts:2017 that would be in like three months from the time of that conversation. They were like, yeah, sure, let's do it. What do we need to do? And it turned out 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 I have good friends among them now. and it was like it was really really close like 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 figure out how we now interoperate with Android Studio better and then you know how do we set up the processes and everything but there was like a big legal thing around it this is when the Colin Foundation was invented and we had to design the protocols for decision making the Colin Foundation and, you know, Google owned the trademark for Kotlin for one year because of legal things.

1:17:09The Pragmatic Engineer hosts:It was basically a guarantee from the JetBrains side until the foundation gets set up. So you can look up the public record. Google was in possession of the Kotlin trademark for a year. But then the foundation was set up and transferred to the foundation. So, you know, it was fun. It was a pretty crazy time, but it was amazing to see how happy people were at Google I.O. when the announcement happened.

1:17:39Andrey Breslav:And then usage must have skyrocketed. You probably blew past 100 ,000 pretty quickly.

1:17:44The Pragmatic Engineer hosts:Yes, yes. I think we went, yeah, we probably got into millions that year. This is what was basically 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 C Sharp was part of Windows or JavaScript was part of the web platform. And I knew that Kotlin had no platform. So it was supposed to be much tougher time for Kotlin than for some other languages. But, yeah, the platform came along somehow. Jumping forward to a lot more closer to today, you left Kotlin in 2020, later you left JetBrains.

1:18:27Andrey Breslav:What are you doing right now?

1:18:29The Pragmatic Engineer hosts: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 look at it from a similar perspective. Like in Kotlin, we wanted to get rid of boilerplate. 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 right because of ai yes it's all because of ai 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.

1:19:20The Pragmatic Engineer hosts:That would be very nice. So on the one hand, you know, the entire history of programming languages is going from lower to higher levels of abstraction. We started with machine code, then assembly was a step up, actually. Assembly language is a higher level language.

1:19:38Andrey Breslav:And then machine code, okay, yeah.

1:19:40The Pragmatic Engineer hosts:Yeah, and then C was a high-level language back in the day. And then, of course, managed languages like Java were a great step up and made programming a lot more accessible. And teams could grow, and you didn't have to be a super competent programmer to build working software. And then things like Kotlin built on top of that success, and we raised level of instruction some more. But now we can do even better in the dance. So you can imagine like a normal program, some application code. A lot of the things in this code are obvious to you and to me. So if you ask me to write this code, you don't spell everything out.

1:20:23The Pragmatic Engineer hosts:You explain what the program needs to do, and I can implement it. And it will work the way you want. 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.

1:20:37Andrey Breslav:Yeah.

1:20:37The Pragmatic Engineer hosts:Yeah. And so this is the point with Codespeak. 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, 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 a 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

1:21:31Andrey Breslav:So can you tell me a bit more on what Codespeak is or what this language is? Is it designing an actual kind of formal language, just simpler? Is it using, of course, we know that AI and LLMs and agents can do all the funky stuff. Where is this? What is this?

1:21:47The Pragmatic Engineer hosts:Okay, yeah, so I'll try to explain this. So I think the best way of thinking about Codespeak is it's a programming language that's 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 this is like the way new languages will be. Because, you know, you can think about the ultimate language of today as a 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 a huge repository of all kinds of JavaScript libraries.

1:22:34Andrey Breslav:The Node Packet Manager, one of the biggest packet managers in the world, right? Right.

1:22:37The Pragmatic Engineer hosts:Yeah. So you have a huge library out there that you can all, but now you have an even better NPM, 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.

1:22:55Andrey Breslav:Yeah, you need to know how to prompt.

1:22:57The Pragmatic Engineer hosts:Right. 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 a bag of libraries, right? 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. 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 not the goal to make it super restricted, but the goal is to leverage all the power and support the user, you know, we need to rule out stupid mistakes and things like that.

1:23:49The Pragmatic Engineer hosts:We're still working on that. But the basic idea is 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 it to you, you will just get there much faster.

1:24:07Andrey Breslav:So one question that I asked Chris Lattner, 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 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?

1:24:31The Pragmatic Engineer hosts:That's a very interesting question, and I had a few discussions about this. My position is it's probably misguided 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 and so 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 Kotlin. Even the LLMs that write Java very well won't write Kotlin as well.

1:25:12The Pragmatic Engineer hosts:because it's not as present in the training set because it's younger. And, you know, there are ways around it. And I think the later models like added some more Kotlin 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 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 its existing code. And inventing a new language for that, I don't know how promising that can be.

1:25:53The Pragmatic Engineer hosts: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 during inference. and maybe you can sort of extract 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 human prompts, but they will be shorter. Maybe you can do something like this. I don't know if it will help a lot. But what we're doing in Codespeak as part of working in this language, we need to really nail down this query language capacity.

1:26:44The Pragmatic Engineer hosts: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 Codespeak version.

1:27:32The Pragmatic Engineer hosts:And, you know, 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're sort of discovering Codespeak as a language, at least parts of it, and not really designing that bit of it. You know, 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. Nowadays, whatever algorithms you have in mind, you need a data set.

1:28:11The Pragmatic Engineer hosts: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.

1:28:18Andrey Breslav:So just taking a look at you are using these tools day in, day out. I mean, 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 thinking about software engineer you're a software engineer yourself you you've written so much code in your life and are you still writing code yeah i'm writing some code yeah and uh sorry typing

1:28:46The Pragmatic Engineer hosts:or prompting uh i'm doing both um sometimes i'm just typing uh 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 all this. But cursor's completion is really a step up from traditional IDs. And I think the IntelliJ side has something similar now. So it's like a lot of coding, but in a very different kind of mindset and 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 we figured out that coding agents are good.

1:29:27The Pragmatic Engineer hosts:Cloud code and cursor agent and so on and so forth. And I think this is a very early step. Right now, we are in this phase where a lot of people are in love with agents and they can be very useful and I use them every day.

1:29:41Andrey Breslav:But I think there are

1:29:42The Pragmatic Engineer hosts: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 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.

1:30:09Andrey Breslav:Big problem.

1:30:10The Pragmatic Engineer hosts:Yeah. So it turns out I'm talking to a machine in human language. But the way I communicate with my team is the machine language. That's kind of backwards. So yeah, so what we're trying to do in Codespeak is to elevate everything to the human language level. So 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 reveal 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 and I think another big theme of today is that we'll be doing a lot of testing and And you may not need to review the code if your tests are really good.

1:31:08Andrey Breslav:You need to verify it, right? That's what you're saying is verifying might not mean reviewing. Right. Or it could not mean.

1:31:15The Pragmatic Engineer hosts:Yeah, depending on the domain. Of course, of course. You might get by without reviewing the code as much, but being sure somehow either reviewing the tests or somehow else making sure that your tests are good. That's a trend. And we are putting a lot of effort at Codespeak into automated testing and making sure the tests actually check the right things and that they check all the code and all that stuff it'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.

1:32:01The Pragmatic Engineer hosts:Some tests will be just very long and tedious to read and, you know, but we're working on that. And that's where we are. And I think 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 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 agents like Cursor or Juni at JetBrains, you have a lot of like code navigation capability and, you know, databases of code is indexed and you can navigate it very quickly.

1:32:49The Pragmatic Engineer hosts:You can find things very quickly. when you run Cloud Code, for example, it might not have that and use grep. And it will be as successful, but take a lot longer and burn a lot more tokens. So, you know, I'm sure this year all these tools come to most agents and will have a lot more sophisticated scaffolding around the models. So that's one thing. But then, you know, my question is always what's going to happen in the end game or in the further future? And there, it's very hard to predict. And we can assume that models will become much smarter. An important thing is that humans will not. 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.

1:33:36The Pragmatic Engineer hosts:And if we have incredibly smart models, what we will be doing is constrained by how humans are. And this is one of the reasons why I'm working on Codespeak, because Codespeak is a tool for humans, not for models. 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 all the software engineering work is done by models, it means humans don't have any say in that.

1:34:18The Pragmatic Engineer hosts:And this has a name. It's called technological singularity. When humans are not making decisions, it means we're not in charge. So this is not the future I'm building CodeSpeak for. Nobody should build any projects for that future. In that future, we're gone. Your projects don't matter. So my assumption when I'm talking about the future is that the technological singularity is not happening. And so 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 serious software, it's always complex.

1:34:57The Pragmatic Engineer hosts:There's no way there's some very simple thing that will make a difference. And when we 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 engineering 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.

1:35:36The Pragmatic Engineer hosts:Maybe not, maybe that is what's called accidental complexity, something that happens like or arises from how we implement systems. But there is also 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.

1:36:11Andrey Breslav: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 very much so i mean there's a lot of you know obviously with cloud code with cursor 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 Kotlin, you have and the team has built so many tools for developers.

1:36:43The Pragmatic Engineer hosts:Right, so I think, 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't figure it out. The people will be doing that. There's also a surprising advantage to using a good UI for your agent. It's very nice to have everything 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 a complete breakthrough of what you can do in a terminal, but generally you can do better in a specialized environment.

1:37:25The Pragmatic Engineer hosts:So I think we'll see more of this integration into development environments or just new development environments built from the ground up to work with agents primarily. So that is an important thing. Since we are putting a lot more emphasis on review, 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 doing it right now. It's hard.

1:37:59The Pragmatic Engineer hosts:It's arrived this year. But generally, I think the big lesson of the last couple of years is that all the things that were quote-unquote obviously needed, and, you know, 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 in this industry is lazy. like everybody's working their asses on. But it just takes time. You know, you need to figure out the basics before you can do advanced things. So, you know, all the straightforward ideas will get implemented at some point.

1:38:42Andrey Breslav:I think there's been this massive jump with AI, especially over the winter break where the coding agents, the CLIs have become a lot more capable. I know so many developers who are actually just prompting most of their code, if not all of it. It's just a massive, massive jump. I don't think we've seen anything this fast. I see a lot of engineers 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 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 is scary.

1:39:18Andrey Breslav:I think we and I talk with some folks, a lot of people message me as well. How are you thinking about this specifically these last few months?

1:39:27The Pragmatic Engineer hosts:It's really hard to give advice. 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. So, you know, there's like more and more news about people not hiring junior developers, for example. This is dumb.

1:39:51Andrey Breslav:It's stupid.

1:39:52The Pragmatic Engineer hosts: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 one thing. Another thing, it's absolutely worth it to invest your time into learning these tools and getting good at it. there's a lot of skepticism around in the developer community about how useful it actually is. And, you know, I tried it on my project and it's no good. There is quite a bit of skill to using these tools.

1:40:33The Pragmatic Engineer hosts:Unfortunately, it's not super formalizable. 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 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 I mentioned before, in the future, it will still be engineers building complex systems.

1:41:15The Pragmatic Engineer hosts:So keep that in mind. It's not like we all go to nothing.

1:41:19Andrey Breslav:And 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?

1:41:34The Pragmatic Engineer hosts:I guess it's a matter of 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.

1:42:19The Pragmatic Engineer hosts: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.

1:42:32Andrey Breslav:That's closing. I just wanted to do some rapid questions. I just ask 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.

1:42:43The Pragmatic Engineer hosts:Well, I love my AirPods. They're incredibly convenient. They fit under my earmuffs. Well, another tool would be earmuffs.

1:42:51Andrey Breslav:Earmuffs.

1:42:52The Pragmatic Engineer hosts:Incredibly good.

1:42:53Andrey Breslav:Yeah, I saw you wearing it. I'll take that one earmuff. And what's a book recommendation that you recommend and why?

1:42:59The Pragmatic Engineer hosts:There is this classic that's been recommended across the tech community for many years. It's called Zen and the Art of Motorcycle Maintenance. I heard that recommended. 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 others, but it's also a very good novel. I really like it. Well, Andrei, thank you so much. This was very interesting and I think inspiring as well. Thank you very much. It was great to chat.

1:43:29Andrey Breslav:It was great. Thank you. The thing that struck me with most from this conversation with Andrei was his observation about how we work with AI coding agents today. You talk to an agent and play in 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 with your teammates in code, in machine language. Whether or not Codespeak becomes 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 enjoyed this episode, please do share with a colleague who's been thinking about where programming is headed.

1:44:03Andrey Breslav: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 one.