Andrey Breslav on Designing Kotlin, and Why the Language After It Is Written in English
The Pragmatic Engineer
Andrey Breslav led the design of Kotlin at JetBrains from its first whiteboard sketches in 2010 through its 1.0 release, its adoption as an official Android language, and a team of about a hundred people. In this conversation with the host of The Pragmatic Engineer, Breslav explains how the language was designed, which ideas it deliberately borrowed, what it left out, and what made Java interoperability so hard. The second half turns to CodeSpeak, their new project. It is a programming language based on English that uses LLMs, and Breslav frames it as the same fight against boilerplate that motivated Kotlin, moved up a level of abstraction. Throughout, Breslav holds that humans, not models, will remain responsible for deciding what software should do.
An unplanned path to a language job
Breslav describes their early career as unplanned. They studied computer science in St. Petersburg, started teaching programming in schools while still at university, and then joined Borland to work on developer tools in the UML space near the end of that era. Borland went under soon after they joined ("I hope it's not because of me"), and Breslav returned to full-time teaching before starting a PhD on domain-specific languages. They had long been curious about typed languages but had never approached them seriously. The PhD, in their words, was "a mess" and was never defended.
While spending a year as a visiting PhD student in Tartu, Estonia, Breslav was contacted by someone who had run Borland's St. Petersburg office and had since moved to JetBrains. Breslav assumed the conversation would be about MPS, JetBrains' meta-programming system for DSLs. Instead, JetBrains wanted to start a new general-purpose programming language. Breslav's first reaction was that nobody needed a new language.
Why JetBrains thought the JVM needed a new language in 2010
The JetBrains engineers laid out the situation for Breslav. The last major Java release was Java 5, from 2004. Java 6 made no language changes and Java 7 made only minor ones. C# had meanwhile gained lambdas, higher-order functions, properties with getters and setters, and much else. Lambdas for Java had been in development for years and would not ship until 2014.
Alternatives existed on the JVM, and JetBrains knew them well because it built tools for them, usually in the languages themselves. The Scala plugin was written in Scala, and Groovy was used widely inside the company. Their assessment was that Groovy was too dynamic for large-scale mainstream production. Breslav explains the trade-off this way: dynamic languages like Python, Ruby, JavaScript, and Groovy are friendlier at the start because the language gets out of your way. They quote the saying that "nothing limits the imagination of a programmer like a compiler." As projects grow, though, large refactorings and confidence that everything fits together become hard, and teams must lean much more on testing. Static languages offer precise refactoring tools and rule out whole classes of errors. For large projects and big teams, the language clearly had to be static. Groovy also had performance problems from layering a dynamic language on a very static runtime.
Breslav calls Scala "a wonderful static language" with "tons and tons of good ideas," and credits Martin Odersky as a great designer. Scala was used at scale at companies like Twitter and LinkedIn. But Breslav says it relied heavily on implicits, and recalls once spending an hour debugging a single line of Scala to work out what it did. The compiler was slow, stability was a concern, and many features were not accessible to many engineers. Scala was also, at the time, very hard to build precise tools for. Breslav puts it alongside C++ as a language where precise tooling was extremely challenging, and notes that Scala 3 is more tooling-friendly.
JetBrains' pitch had two parts. There was a window of opportunity, and JetBrains was the company that could make a language succeed because it had access to developers, their trust, and the ability to build good tools. Breslav was convinced the idea was "not completely dead in the water," though they had no idea whether it could be pulled off. In that first meeting the engineers were already sketching features on a whiteboard, including the syntax for extensions, borrowed from C#, which is still what Kotlin uses.
Breslav did not commit immediately. They finished in Tartu, spent a month in the St. Petersburg office working with a colleague named Max, and then left for a planned internship of about three and a half months at Microsoft Research in Redmond. That was their first exposure to top-level academia. Afterward, they framed the decision as a choice between an academic career they did not feel built for and "the crazy thing." They chose the crazy thing.
How a language begins: whiteboards, lists of pain, and a bad idea
Asked how a language actually starts, Breslav describes months of talking, mostly with Max, plus several internal presentations at JetBrains. Some of the slides survive, English spelling mistakes included. The advantage of JetBrains, Breslav says, was that many people had strong opinions about the problems programmers face and what they like and dislike in other languages. Breslav was 26, did not know how such things were usually done, and says of their colleagues' trust in them, "I'm not sure it was very rational on their part."
The method was to collect Java's pain points, gather proposed fixes, and argue about which problems actually mattered. For a while these were "pieces of the puzzle" in a table. Later they were fitted together, mostly in Breslav's head, which they admit is "not the best way."
Some early ideas were bad. Breslav wanted full multiple inheritance, which they now call "a dumb idea." The hard part, they explain, is not resolving method conflicts but initializing state through constructors. Someone outside JetBrains explained why it was a bad idea, and Breslav remains grateful.
Starting with an IDE plugin instead of a compiler
Coding started around six months in, perhaps a little earlier, and it began unusually: with an IntelliJ IDEA plugin rather than a compiler. An IDE plugin shares much with a compiler front end, and IntelliJ's parsing infrastructure is, in Breslav's view, better than anything else in the world, because as the core of the IDE it must be extremely fast and robust. Max wrote the scaffolding, Breslav plugged in the parser, and the result was an interactive editor for a language that could not yet compile anything. Breslav says this was a very good way to experiment with syntax. Later, an engineer with deep knowledge of the IntelliJ codebase, which was already more than ten years old, factored the parsing infrastructure out so the Kotlin compiler could run on its own.
Breslav then built a full front end while others worked on the back end. They explain the distinction: the front end reads and parses text, handles types, and works out what the program means. The back end generates executable code. For Kotlin that was initially JVM bytecode, and later there were back ends for native targets such as iOS, JavaScript, and Wasm. Early on nobody was full-time, including Breslav, who was still a part-time PhD student before dropping the PhD to focus entirely on Kotlin. Looking back, they call it the decision of someone "young and stupid," and agree with the host's quip that they did it because they thought it was easy. They say they had "an unreasonable amount of hubris."
From "Jet" to "Project Kotlin"
The internal name was Jet. The codebase was full of names like the Jet parser and Jet highlighter. Then the team found the name was trademarked by a company in Novosibirsk that made a compiler, though not a language. The search for a new name was, in Breslav's words, "one of the worst things." Good names are taken, the untaken ones are often unsearchable, and they point to Go, which people call "Golang" because "go" is too common an English word. Rejected candidates included Robusta, a coffee variety.
Another JVM language of the time was named Ceylon, following the logic that Java is an island of coffee and Ceylon an island of tea. A colleague looked out the window and pointed to Kotlin, a large island in the Gulf of Finland near St. Petersburg. It was searchable, unused, and recognizable. Nobody loved it. "Kot" means something bad in German, and Breslav was told it had a negative connotation in Mandarin. So the language was announced as "Project Kotlin" to leave room for renaming. The first public artifact was a set of Confluence wiki pages describing the language, with no compiler, and the name appeared everywhere in them. To make a future rename possible, Breslav created an empty page called "Kotlin" and linked to it wherever the name appeared, so renaming that one page would update every reference. The rename never happened, and Breslav concludes it "turns out to be not a bad name."
Fighting ceremony: what Kotlin fixed about Java
The central complaint about Java in 2010, Breslav recalls, was verbosity. It was a "ceremony language," with public static void main, getters and setters for every property, constructors, and overloads, all of which amounted to boilerplate. The host notes that this is tedious to type, but Breslav argues typing is not the main problem, since tools can generate and fold boilerplate. The real problem is readability. Code is read far more than it is written, and in boilerplate a small deviation in the middle of otherwise standard code becomes invisible. "You become blind to it," and you can debug for days without seeing it. The goal was to make programs about what they do rather than the ceremony of satisfying the compiler.
Lambdas were a major part of this. So were type inference and removing semicolons, which other modern languages had already dropped. Breslav gives the example of duplicated types. In Java of that era you wrote something like a list of strings called strings equals a new ArrayList of strings, naming the type twice. For a map from one type to a list of strings, that repetition grows long and hard to read. The diamond operator, which reduced it somewhat, came later.
Null safety: enforced by types, free at runtime
Null safety was not part of the original plan. It came after an internal presentation that Max invited a colleague named Roman to attend. Roman later became Kotlin's project lead, and his feedback was: "if you want to do something really big for enterprise developers, figure out null safety." The team did, and it took years.
Breslav cites Tony Hoare's description of null references as the "billion-dollar mistake" and says that among runtime errors in Java code, null pointer exceptions would be at the top. A type system is supposed to prevent certain errors, such as class cast exceptions or missing methods, unless the programmer explicitly overrides the checks. In Java, however, anything can be null, and when it is, the program throws an exception and dies.
Kotlin's approach was to enforce nullability in the type system while making it free at runtime. A common alternative is an option type, a box that may or may not contain a value. That box has to be allocated and carried around, which can create many objects for the garbage collector, although runtimes have become better at optimizing some of them away. In Kotlin, nullable and non-null references are the same as Java's references at runtime. The work happens at compile time, with some runtime checks at the boundary with Java code, which Breslav says is much cheaper than allocating objects.
Standing on the shoulders of giants
Kotlin's slogan was "pragmatic language for industry," a deliberate contrast with Scala's reputation as academic. Breslav says the team was not doing research and that "if we don't get to invent anything, it's a good thing, not a bad thing." Familiar ideas are easier for people to grasp, and borrowing lets you study how other communities reacted to a design and what it implied in practice. Breslav has a whole talk on this, called "Shoulders of Giants."
Java was the biggest influence, since Kotlin runs on the JVM. After that came Scala, which contributed primary constructors, data classes, val and var, and declaration-site variance for generics. Breslav calls declaration-site variance a great idea of Martin Odersky's and "a huge pity" that Java reversed course on it at the very end of its design process. Kotlin had to handle the mismatch at the Java boundary. Kotlin also simplified some Scala ideas. Scala traits could hold state as well as method bodies, and that raised hard questions about constructor ordering. Kotlin kept method bodies in interfaces but dropped state, a compromise Breslav considers good, especially since Java ended up in the same place, which made integration easier.
From C# came extensions, lessons about compiler implementation, and one parsing trick a colleague on the C# IDE team told Breslav about. Generic calls inside expressions use angle brackets, but to a parser those are just less-than and greater-than signs, and the grammar is mathematically ambiguous. Java works around this by requiring type arguments after a dot, as in Collections.<T>function(), which Breslav calls awkward. Scala uses square brackets for types, which forces arrays to use round brackets, an unfamiliar choice. C# uses an ad hoc disambiguation hack in the parser, and Kotlin does something very similar. The result is familiar syntax that people read without confusion, with an explicit way to disambiguate when needed.
Groovy, which JetBrains used for build scripts, inspired one of Kotlin's more novel features: type-safe builders. These keep almost all of Groovy's syntactic flexibility for constructing objects but are fully typed, so arguments are checked. That goal is why Kotlin has extension function types and trailing lambdas. The less-known language Gosu inspired smart casts.
Smart casts, and what was left out
Breslav calls smart casts "one of the nicest things a compiler can do to a developer." In many languages, after checking that x is a string, you still have to cast x to a string to use it. Kotlin infers the cast. The implementation is complicated because variables can change and a check can go stale, so smart casts apply only to expressions stable enough to trust. The payoff is removing the instanceof-then-cast pattern that fills codebases.
Pattern matching was designed, drawing on functional languages like Scala and Haskell, but Breslav postponed it on realizing, while writing the parser, that it amounted to "an entire language in size," a parallel universe of syntax. Around the 1.0 review, they concluded that smart casts plus destructuring gave ordinary developers about 80% of the benefit. The remaining value mattered mostly to a vocal group of compiler developers and functional programming enthusiasts. Kotlin's when expression with smart casts covers much of the ground. Breslav says pattern matching might reach the roadmap someday and notes that Java is moving toward it.
The ternary operator is what Breslav calls "the saddest story" in Kotlin's design. Because if is an expression in Kotlin, the ternary seemed redundant, a patch in C-like languages to get a conditional expression. It also used valuable characters, the question mark and colon, which Kotlin wanted for nullable types and type annotations. It turned out people found if expressions verbose and wanted the ternary. Breslav resisted for a while, and by the time they agreed, the operator could not be retrofitted because it clashes with how Kotlin's other operators work. In retrospect they consider the omission a mistake.
Java interoperability: the most expensive feature
The single thing the team spent the most time on, Breslav says, was Java interoperability. Their advice: if someone offers you a job building a system that interoperates transparently with a huge system you don't control, "ask for a lot of money." The requirement went both ways. Kotlin had to use any Java library, and existing Java projects had to be able to convert code to Kotlin piece by piece, often starting with tests, while the surrounding Java code kept calling it transparently.
The first difficulty is that JetBrains does not control the Java compiler, which knows nothing about Kotlin source files. In a mixed project, the Kotlin compiler runs first. It contains a Java front end so it can resolve references into Java sources, and it produces class files. The Java compiler then treats the Kotlin code as binaries, which works because Java supports separate compilation. The IDE needs its own tricks so navigation between Java and Kotlin works. Incremental compilation, already a complex and heuristic-heavy algorithm for Java alone, becomes what Breslav drily calls "fun" when two languages are compiled incrementally together.
Collections illustrate the work of exposing Kotlin features to Java. Java collections are invariant because they are all read-write, so a list of strings cannot be assigned to a list of objects without wildcards. Kotlin wanted read-only collection interfaces that allow this, but such interfaces do not exist at runtime. The compiler has "a layer of trickery" so that Kotlin distinguishes read-only from mutable views of the same Java collection classes, while Java sees ordinary collections. Kotlin also exploits covariance at the boundary. A Kotlin method taking a read-only list of Any is exposed to Java as taking List<? extends Object>, so Java callers can pass a list of strings.
Nullability at the boundary was the biggest problem. Java types carry no nullability information, so the team first treated every Java type as nullable, which is mathematically correct. Internal feedback at JetBrains was "horrible." Code was plagued with null checks everyone knew were unnecessary, and annotations on the Java side were brittle and often missing. The team re-imagined the approach with help from Ross, a type theorist Breslav recalls being at Cornell at the time, who worked out a calculus for types that come from Java. They might be null but should not be treated as nullable. Breslav says that once implemented, "the mathematical beauty is completely gone." What remains is the core idea of splitting a type in two, surrounded by something "messy," "industrial," and "not sound," but it works well. Collections and nullability are handled in a similar way at the boundary.
Six years to 1.0, and a team of fresh graduates
Whenever Breslav was asked when Kotlin would ship, they said "one year from now," which they admit was not a plan. They also believed their first implementation was a throwaway prototype. They think it has since been mostly rewritten, but that took around six years or more. Work started in autumn 2010, and 1.0 shipped in February 2016.
Breslav attributes part of the delay to not knowing how to manage projects, and part to team composition. Having been a teacher, they hired mostly fresh graduates. Some became core contributors who built foundational parts of Kotlin and grew into great engineers, but Breslav thinks they "overdid it" and the balance with experienced engineers was wrong. The team began as four part-time people for about a year, reached around 25 by release, and by the time Breslav left in 2020 was about 100 people, 70 of them engineers.
Bootstrapping, compatibility, and messages from the future
Some language development practices are ordinary. Kotlin had code reviews early on, often done with Breslav sitting next to the other person because they like talking to people, and a public issue tracker that was hard to manage but valuable as a communication channel. Others are unusual. The Kotlin compiler is written in Kotlin, so building it requires an earlier compiler, and the team had to agree on which version. Sometimes a hack was committed to a branch, used once as the bootstrap compiler for a binary-format or syntax change, and then discarded. Breslav doubts Kotlin's full history could be rebuilt from scratch without a lot of manual intervention.
Backward compatibility shaped the release process and helped delay 1.0. Java was known for stability, and Scala's community had suffered from frequent breakage. Breslav also notes, wryly, that Python survived the break from Python 2 to Python 3. Before 1.0 there were 13 milestone builds, which Breslav calls embarrassing, and for major breaking changes the team provided automated migration tools. They believe this was not standard practice then and are happy to have helped popularize it. The year before 1.0 was spent reviewing the whole design and prohibiting, through compiler errors, any code that might conflict with planned future features. At one point there were design meetings almost every day. Some things were prohibited correctly and some incorrectly, but overall it worked.
For changes nobody anticipated, the compiler has a mechanism called "message from the future." Many languages make newer binaries entirely unreadable to older compilers, which forces whole projects to upgrade when a library adds a single method. Instead, a newer Kotlin compiler can mark only the specific elements an older compiler cannot understand, and the rest of the library stays usable. Kotlin also developed a discipline around experimental features: "experimental" in package names, warnings, and compiler flags required to enable them. Breslav is glad other languages, now including Java, do the same.
Their broader lesson is that a compiler, unlike a SaaS system, leaves behind source code and binaries that pin down its history in the wild. They say that with enough users, "you hit every freaking case." They realized this before 1.0, with only a few thousand users: anything possible, someone will do.
How Android happened
Android was not in the original plan. In 2010 the target was server-side Java developers, the biggest source of IntelliJ revenue through Spring users, plus desktop developers, since JetBrains had "probably the last desktop application written in Java," or at least in Swing. A few years in, a user asked whether Kotlin worked on Android. Breslav assumed it should and told them to try. The report came back that the Android toolchain, not Kotlin's, was crashing with a core dump in a tool written in C.
The cause, Breslav explains, was that the Android team had actually implemented the JVM specification, while the HotSpot VM, which Breslav suspects predates the spec, was lenient about things like disallowed class-file flags. The Kotlin team had only tested on HotSpot. From then on they used the Android toolchain as a validation environment to clean up their bytecode, though it also faithfully enforced some legacy details mainstream Java ignored. Breslav came to see Android as a growing platform with many new applications, where adopting a new language would be easier, and made sure Kotlin worked well there. All of this happened against the background of Oracle's lawsuit against Google over Java after acquiring Sun, which took years to settle.
Breslav gives several reasons Kotlin caught on with Android developers. Android apps run on billions of devices whose virtual machines are not always updated, so Android developers were stuck with old Java even after Java 8 arrived in 2014. Workarounds like Retrolambda helped, but frustration with Java was much higher in the Android community than on the server. Swift on iOS showed a large ecosystem moving from a dated language to a much nicer one. And Google had moved Android developer tooling from Eclipse to the IntelliJ platform after IntelliJ was open-sourced, so Kotlin's plugin worked in Android Studio "reasonably smooth[ly]."
Kotlin's team tried to get Google's attention without success, even after 1.0 in 2016. Growth was organic. Breslav had privately set 100,000 users as the threshold for success, and by 2016 usage was in the tens of thousands and on track. Then Google reached out about announcing official Kotlin support at Google I/O 2017, about three months away. Breslav calls the Google team's effort "heroic" and says they came very close to missing the deadline. JetBrains had to improve Android Studio integration and set up processes. The legal side led to the creation of the Kotlin Foundation and its decision-making protocols. As a guarantee from JetBrains, Google held the Kotlin trademark for a year until the foundation was established and the trademark was transferred to it. Usage probably reached millions that year. Breslav had long believed the easiest way for a language to succeed is to be part of a platform, as C was for Unix, C# for Windows, and JavaScript for the web. Kotlin had no platform, "but yeah, the platform came along somehow."
CodeSpeak: removing boilerplate at the next level
Breslav left Kotlin in 2020 and later left JetBrains. They are working on another language, CodeSpeak, which they present as a continuation of Kotlin's goal of making programs more to the point, now possible at a higher level because of AI. LLMs find obvious the same things humans find obvious, which narrows the gap between what a machine and a human can understand. That, Breslav argues, means "we might not need to write dumb code anymore."
They place this in the history of programming as a rise in abstraction: machine code, assembly, C, managed languages like Java that let teams grow and made it possible to build working software without being an exceptionally skilled programmer, and then languages like Kotlin. When one engineer asks another to write some code, they explain what the program must do rather than spelling out every line. CodeSpeak aims to shrink what a programmer must tell the computer in the same way. From their "current anecdotal experience," Breslav says much code can be shrunk by about 10x, making projects easier to read and navigate and leaving programmers to express only "what only you know about what needs to happen."
Breslav describes CodeSpeak as "a programming language that's based on English." It is not an entirely formal language, but it is meant for engineers and uses LLMs heavily. Their framing is that the ultimate language of today is a normal programming language that uses an LLM as a library. If npm was a huge repository of JavaScript packages, an LLM is "an even better npm" that has seen all the code in the world. The catch is that the only way to query it is natural language, and there is no known way to make that fully formal. So such a language must be at least partly informal. How formal CodeSpeak can become is, in Breslav's words, "still in the air." The goal is not heavy restriction but using the model's power while ruling out stupid mistakes.
Should there be new languages designed for LLMs?
The host asks whether new languages should be designed for LLMs themselves, a question also put to Chris Lattner on the show. Breslav thinks the idea is probably misguided. First, LLMs need large training sets, which a new language lacks. They say today any LLM writes Python better than Rust or even Kotlin, and models that write Java very well still write Kotlin less well because it is younger and less represented, though they believe later models have added more Kotlin to their RL data and are improving. Second, LLMs are trained on human language, their programming knowledge is part of that, and their power comes from exposure to existing code, so Breslav is not sure how promising a new language would be. They mention one interesting research direction: extracting an optimal prompting language from a model's internal representations. It might not be intelligible to humans, and they note experiments showing unintelligible prompts can produce the same results as normal ones while being shorter. Breslav doesn't know if this would help much.
In CodeSpeak's own work, the team takes existing code and searches for the shortest English descriptions that can generate equivalent implementations, meaning ones that behave the same, not identical character by character. The code also evolves through its commit history, so the descriptions must represent changes too, and a small change in code should produce an even smaller change in the spec. Breslav says they are in this sense "discovering" parts of CodeSpeak rather than designing them. In AI work, they add, everything becomes a machine learning problem: "if you don't know how to collect a data set, don't even start."
The backwards workflow of coding agents
Breslav still writes code, sometimes by typing, more often with Cursor's tab completion, which they consider a real step up from traditional IDEs, and often by prompting. They see the current moment as the early days of a new era, noting that only in the past year did it become clear coding agents are good. They use agents daily but see an inherent problem in the model. A developer communicates intent to the agent in human language in a one-on-one chat, the agent produces code, and the code is what gets committed and what teammates see. The chat history is lost. "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." CodeSpeak aims to lift everything to the human-language level.
Breslav thinks many teams have not realized how hard it is to review all this generated code. When people suggest simply not reviewing it, Breslav replies that you can do that "for a couple of days and then it just collapses." Testing will become a major theme. Depending on the domain, good tests may reduce the need to review code, and CodeSpeak is investing heavily in automated testing that checks the right things and covers all the code. The open problem is presenting generated tests to users in a way that actually lets them confirm the right thing was built, since some tests are long and tedious to read.
In the near term, Breslav expects "obvious" improvements to agent scaffolding. Agents are only beginning to use language servers and the other tooling that has long existed for code. IDE-integrated agents, such as Cursor or JetBrains' Junie, can use indexed code navigation, while a terminal agent like Claude Code might fall back on grep, succeeding just as often but taking longer and burning more tokens. Breslav expects these capabilities to reach most agents this year.
Humans stay in charge, so engineering stays
For the longer term, Breslav says the one thing they know is that models will get much smarter and humans will not: people will be "as smart or as dumb as they are today." What we do will therefore be constrained by human limits, which is why CodeSpeak is a tool for humans rather than for models. To those who say sufficiently smart models will review and test their own code, Breslav asks who then makes the decisions. If humans have no say, that is the technological singularity, and "nobody should build any projects for that future. In that future, we're gone." Their working assumption is that the singularity does not happen and humans remain in charge.
If humans are in charge, their job is to communicate intent, and serious software is always complex. Breslav distinguishes accidental complexity, which comes from how systems are implemented and may shrink, from essential complexity, the inherent intricacy of how we want systems to behave. Managing essential complexity requires an engineering mindset, whatever it ends up being called. Breslav expects teams of engineers to keep building systems, possibly smaller teams delivering far more, and says CodeSpeak is built for that work.
Developer tools in the "wild west"
On the state of tooling, Breslav repeats that this will be the year developer tools become available to agents. They also see value in dedicated environments over terminals. Terminal tools, especially Claude Code, are "a complete breakthrough" in what a terminal can do, but specialized environments can offer a better experience, and Breslav expects more IDE integration and new environments built for agents from the ground up. With more emphasis on review, they expect new review tools that improve on current practice. They do not expect testing breakthroughs this year "because it's hard. I'm doing it right now," though some advances may arrive. The broader lesson of recent years, in Breslav's view, is that obviously needed features, like connecting agents to developer tools, take a long time not because anyone is lazy but because you must build the basics before the advanced things.
Advice for anxious engineers and new graduates
The host describes engineers shaken by how quickly coding agents improved over the winter break. Breslav says advice is hard to give, but offers a few thoughts. Much of the hype reaches management and leads to suboptimal decisions that will be reversed. Not hiring junior developers, for instance, is "dumb" and won't last, though it is hard to say how long it will go on. It is worth investing time in learning AI tools. Breslav acknowledges widespread skepticism but says using these tools well is a real skill. It is not yet formalizable, and some people get much better results than others without being able to explain why, but it can be learned. They caution against believing everything claimed on Twitter. And engineers will still build complex systems in the future.
For new graduates, Breslav suggests following their inclinations. If you can be highly productive at producing robust, evolvable code, get good at that. If you like harder problems, go into "the most hardcore things you can." That expertise will be rare and marketable, and even if the specific area disappears, you will have become much smarter by learning it. Young people have a lot of mental capacity for going deep, and drilling down on many things builds expertise across wide fields.
In a closing rapid-fire round, Breslav names AirPods, which fit under their ear muffs, and the ear muffs themselves as favorite tools, and recommends Zen and the Art of Motorcycle Maintenance, both for its thinking about technology and real systems and as a good novel. The host's closing reflection returns to Breslav's point about agents: developers express their intent in English, commit only code, and lose the intent. Whether or not CodeSpeak is the answer, the host concludes, something is missing, a layer that preserves intent, and someone will have to figure out how to keep it.
Why would anyone create a new programming language today if AI can already write most of your code? Andrey Breslav has an interesting answer. Andrey is the creator of Kotlin, a language that runs on billions of Android devices and is one of the fastest growing languages in the world. Today we cover how Andrey designed Kotlin by deliberately borrowing ideas from Scala, C# and Groovy, and why he considers leaving out the ternary operator one of his biggest regrets. Why making Kotlin interoperate seamlessly with Java was a gigantic undertaking and what it took to get it done. How Kotlin adoption went through the roof after Google announced it making it the official language for Android in a move that even took Andrey and the Kotlin team by surprise. Andrey'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 WorkOS. Andrey, welcome to the podcast.
Hello. 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 start?
Okay, so that was a little messy because I went to school back in St. Petersburg, 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, you know, at some point while I was still in the university I started teaching programming in school and, you know, 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 went under pretty soon after I joined and I hope it's not because of me.
Yeah, 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 in my PhD I was working on domain specific languages and generally I was interested in languages. It 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 slightly more serious, although my PhD was a mess and I never defended because of that.
But at some point, you know, someone reached out. It was actually a person who was in charge of the Borland St. Petersburg and by that time he was already at JetBrains and he reached out to me while I was in Tartu in Estonia. I was there for a year as a visiting PhD student. It was a lovely time. So he reached out and invited me to, when I next visited St. Petersburg, to visit the JetBrains office there and talk about something about languages.
What I thought was that it was about this project called MPS, Meta Programming 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 language.
And I was completely unprepared for that. Like, 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 basic pitch was 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. And I was like, but there are other languages, like everybody's doing fine, why do you need to do that? And this conversation was actually a very insightful one because the guys at JetBrains, they simply explained to me how the things actually were and, you know, it was a big problem by that time. So Java didn't really evolve and hadn't been 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 the last major version of Java by 2010 was Java 5 that was released in 2004.
Ooh. Six-year-old language.
Yeah. And since then there were updates. There was Java 6 that made no changes to the language at all.
And then there was Java 7 that made minor changes. In parallel there were things 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 higher-order functions and all that nice stuff. There were getters and setters and many other things that made the language much nicer. And Java felt like it was standing still. And there was a project to work on lambdas for Java, but that 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, you know, 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 JetBrains knew both Scala and Groovy, they built tools for them. It's traditional to build your tools in the language you're building the tools for. So the Scala plugin was built in Scala and there was a lot of Groovy used at 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 basically Groovy was too dynamic and too far from, you know, hardcore mainstream large-scale production because dynamic languages are not for that basically.
What are dynamic languages for? What are their strengths and best use cases?
So the trade-off, I guess, if you look at a statically typed language like Java and Kotlin and Scala for example versus dynamic languages like Python and Ruby and JavaScript and Groovy. 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.
And you know this may be changing nowadays a little bit and this is in part what I'm working on now, but back in the day it was completely true. You know, the whole art of making a good language was to restrict the user in a good way.
Yeah, but in any case, 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, you know, precise refactoring tools 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, at least in our mind back then, it was absolutely clear that if we're building a language for large projects, big teams, so on so forth, it has to be a static language.
Static one. Yes.
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. So that was on 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 implicits 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 a lot of engineers. So from the experience of using Scala at JetBrains, 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 Odersky is a great language designer, you know, and...
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.
And I think LinkedIn as well. Yeah, so in any case, it's always very nice when other languages kind of pioneer things and then you can build on top of their successes and failures, and we were in that position basically.
So the argument that people at JetBrains were making was basically that 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, you know, if you have a static language you can 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 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 was then when we actually sketched some initial features on the whiteboard, just because JetBrains is generally run by engineers.
Hold that thought from Andrey 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 engineering 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 SonarQube, 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. It's 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 maintainability 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 code 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/sonarsummit.
So, everybody I talked with were deeply in the weeds with IDEs and everything and knew programming languages very well and, you know, we had a very technical discussion. So I don't remember exactly all of the features we were talking about, but the current syntax for extensions in Kotlin was already there. 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 a very exciting conversation.
But I didn't make a decision then, because I was in Tartu 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 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 to Microsoft and then I will decide whether I commit or not, which in hindsight, I mean...
Well, I made the right decision in the end. I had a great time for this month or so. I worked with the guys in the office. It was mostly Max Trafi I was working with and it was incredible, like we had such great discussions, and I actually saw Max this morning and it was like... it was a great time.
So then I went to Seattle, did something completely different there. Microsoft Research, saw really great researchers working there, actually was exposed to the top-notch level of academia for the first time. It 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, and was not sure whether I can be a good researcher on my own or I'll have to follow in somebody else's footsteps, versus 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, 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?
In our case we basically talked a lot for a few months. I think not everyone is like that, but I think best when I'm talking to people, and this was the ideal environment because we were basically discussing things with Max constantly for many months, and there were a few internal presentations that I made at JetBrains 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 see 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 programmers face and what they like and don't like in other languages. So I had tons and tons of input from other people, and very good people. So that helped. And I really 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. But somehow these people just trusted me. I'm not sure it was very rational on their part. It 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, wrote out, like, we're going to have these features, or how can we imagine?
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 there was a lot of experience of using Java 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. And for some time it was just, you know, pieces of the puzzle basically laid out on 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 that we thought were important back then. For example, I wanted to implement multiple inheritance, fully fledged multiple inheritance, which was a dumb idea.
Multiple inheritance meaning that a class can inherit from like several classes. Yeah. And you have to take care of like conflict resolution and all sorts of edge cases, right?
Yeah. So 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 JetBrains 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 as well, and some of them just fall off over time as we were discussing or prototyping.
I think I started writing code maybe 6 months in or something like that, maybe a little earlier than that, and I started with a parser. It was 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, so all the parsing infrastructure, and it was awesome. Like, the 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.
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 Jemerov who did that. And he's an awesome engineer. He's probably one of the best people to refactor a large code base and then take this one bit out of something that was already 10-plus years old back then.
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 front end and on some translation, and Dmitry and Alex Tkachman were working on the back end. Everybody was part-time.
When you say you work on front end, they work on back end, in a language context, what does that mean?
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, the front end is reading the text and parsing and doing types and all that, and the back end generates Java bytecode. And Kotlin has multiple backends for different target languages. We have a Java back end, we have a native back end for iOS and other native platforms, and a JavaScript back end, a Wasm back end.
At that time, nobody was full-time working on this project. Even I was part-time a PhD student and 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. There's a saying that we didn't do it because it was easy. We did it because we thought it was easy.
Absolutely. 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.
So when the language started, what did you call it internally? There's always internal code names, right?
Right. Yeah. So 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 the whole code base was using the name Jet. We had a Jet parser and, you know, Jet editor or whatever, Jet highlighter, something like that. And then someone realized that the name was trademarked by someone else, and it was actually people we know there in Novosibirsk, Russia, doing something. It's not a language, but it is a compiler. And we couldn't use it.
And this is when we started looking for another name. It was very painful. 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 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 a verb in English, and a very common one.
Yeah, so we had weird options. In one of my old presentations I found a list of early names, and we had Robusta there, as a flavor of coffee, and we had, for example, up 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 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 Kotlin. And it's a good name in the sense that it's very googleable. 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.
And we were kind of hesitant, and, you know, Kot means a bad thing in German. And also there was 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 wiggle room to later replace the name. But it stuck.
The first thing we did, we put out basically a Confluence page with a description of the language. It was just a bunch of wiki pages, and there was no compiler available, no nothing. And there, you know, the word Kotlin appeared many, many times. I was like, my god, I can't do search and replace and then change the name everywhere. So the workaround that I came up with was to create an empty page called Kotlin, 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. 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 Kotlin compared to Java? Because Java was the big one. How did you explain to developers, you know, who initially started onboarding or wanted to give it a go?
Yeah, I guess there were a few major selling points, and then there were other things on top of that. When we started, in the very beginning, we didn't have null safety in mind. Null safety came a little later, after one of the internal presentations. It was Max Shafirov who invited Roman Elizarov, who later was the project lead for Kotlin, and Roman came and listened to the presentation, gave some feedback and said, 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 what makes Java feel so outdated, and there were a bunch of things. Lambdas were very big. The general feeling about 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 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 and so forth. But the bigger problem is always readability. 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 can debug for days not seeing them.
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 type inference was also a big thing, because Java was repeating types a lot, and many other things like that, like semicolons. You know, the modern languages of the time already got rid of semicolons.
And so in Kotlin you also got rid of it.
Yeah. So basically in terms of syntax we got rid of semicolons and duplicated types, and that was a lot of noise in code.
What does it mean that Java had duplicated types?
Yeah. So in that version of Java, when you declare, say, a local variable, you say it's a list of string called strings equals new ArrayList of string.
Oh yes, I remember this one. Yes. You need to type it out twice, and if you get one of them wrong, compile error, etc.
Right. And at best you could omit the second mention of string by using a diamond operator, but that only came later. You know, it was basically very verbose, especially if your types are long. 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 a bunch of things like that were really annoying to a lot of people, especially compared to C# or Scala.
So we did all of that, and then 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. I think it's one of the main differentiating factors now for Kotlin, alongside extensions and other things, but null safety is one of the core features.
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 on the Dutch post website there's a null issue happening in production. But, you know, before Kotlin and in a lot of languages, why is it such a big problem? It is.
Yeah. So dealing with null references is a big hassle in most languages, and I think it was Tony Hoare who called it the billion-dollar mistake at some point, because, 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. But there are also errors that should be prevented by the compiler. So, for example, ClassCastException or missing method error are things that the compiler is trying to protect you from. 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.
Yeah.
And with nulls it's not a thing in Java. Anything can be null, and if it's null, it will just fail.
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 are different ways of being disciplined about it and so on and so forth, but basically this is a plague across any code base. You know, there are different approaches to this, and in Kotlin we took the approach of enforcing it in the type system, but also making it free at runtime.
What does that mean, that you made it free?
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.
And that box is not free. You have to allocate it, you have to carry it around everywhere, and this easily creates a lot of objects in the old generation for the garbage collector, which 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. Although, you know, the runtime is getting better and they can optimize some of those objects away, but still, it's an overhead.
What are features that you took into Kotlin that were inspired by other languages that you admired?
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.
Andrey 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 season sponsor, comes in. WorkOS is the infrastructure layer that helps AI companies handle that complexity without slowing down. SSO for enterprise buyers, MCP auth for agentic workflows, even protection against free trial abuse with Radar. Teams like OpenAI, Cursor, Perplexity, and Vercel rely on WorkOS 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 workos.com. With this, let's get back to Andrey and how Kotlin was standing on the shoulders of giants.
So the slogan for Kotlin was "pragmatic language for industry," and the pragmatic bit, which I mean is a 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, we're not doing academic research here. We're not trying to invent anything. 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, 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 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 communities' 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 JVM and we depend on that, but apart from that, Scala had a huge influence, and we used so many ideas from Scala, from primary constructors and data classes and vals and vars and all these things, and to some interesting tricks about how generics work. For example, variance declarations is a great idea of Martin's, 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 definitely Martin's idea was much better. We had to, sort of on the boundary, the Java boundary, we had to fix the problem of Java having it different and figure that out.
There were many, many ideas we took from Scala, and that was very helpful, and 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. What you couldn't have was constructor arguments, like you always have a default constructor and can initialize all your fields. And it's not as bad as multiple inheritance in C++, but it's still a little complicated when it comes to in what order you're calling the constructors, so 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 in 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.
So Scala was a big influence. C# was a very big influence, extensions of course, and we learned quite a lot from how C# compilers do things. 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#. It was actually my colleague who worked on the C# IDE who told me about this, which is basically a super pragmatic thing they do in C#. When you call generic functions, you use angle brackets.
Yeah.
Inside an expression. But the thing is that there is no such thing as angle brackets. There is less and greater.
Mhm. Yeah.
Right. And the parser can easily get 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 an inequality, right? It's not a call. And this is mathematically unresolvable. It's an ambiguous grammar. You can't 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, the function name.
Really awkward.
Kind of weird.
Yeah.
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. It's not the end of the world. Scala is doing fine, but still. 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 it. When you read it, as a person I never get confused, like this is not a smaller sign, I know it's a... Yeah, so most of the time it's not a practical problem, and then there is a way to disambiguate if you like.
So C# 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 typed 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 and 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 dangling lambdas and other things that are actually very nice syntactic constructs. So many, many things came from different languages. A less known language called Gosu, I think, was what inspired us to do smart casts.
What are smart casts?
Oh yeah. So I think smart casts 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 instanceof 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 after you've done the if, you know it's a string, but then
You need to write it out again.
Yeah. So you've just done the check, but you have to say String again to make the compiler happy. So smart casts 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?
So nice.
Yeah, it's a very nice thing. It's a pretty complicated algorithm because variables can change values and the check that you've just made can go stale, and there's a bunch of algorithmic trickery around this, and you can't do a smart cast on any expression; it has to be a certain type of expression that can be stable enough and so on and so forth. But it's a very nice thing, and you can get rid of so much noise in the code, because all the code in the world is riddled with this instanceof, cast, instanceof, 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 in other languages, you considered maybe we should bring it in, but after debate you're like, no, let's just leave this out? Not all of them obviously, but some of the big ones that kind of came close.
We had a design for pattern matching in 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. When I was sketching it out on a piece of paper, it looked like a very useful thing 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. 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, when we were doing review for 1.0, or maybe a little earlier than that, I just realized that smart casts plus something we have called destructuring together give us like 80% of all the good things pattern matching can do for 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 of them. So we decided to not have pattern matching back then, and maybe there comes a day that pattern matching gets added to Kotlin.
And pattern matching is in the case statement, so you can have a lot nicer case statements, a lot more expressive ones, right?
Yeah. So generally, Kotlin has this compromise where you have our version of switch case, which is called when, and you can have smart casts there. So you can say, 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. And I think it was a good compromise, because it's a really big feature. It's hard to design well, and it would be a lot of work on the tooling side. So maybe it gets on the roadmap 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 ternary 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?
Yeah.
Was it for readability reasons?
This is the saddest story, I think, in the design of Kotlin. I didn't realize how much people liked it. So the reason was, Kotlin used this principle from functional languages that everything we can make an expression is an expression. So if is not a statement in Kotlin, it's an expression, and the ternary operator is sort of a patch on the design of 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? 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 as an expression is 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 into the current syntax in Kotlin, 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.
Yeah, I think in retrospect it was a mistake, because pragmatically it's more use than harm to have it, but we just can't retrofit it.
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?
Okay, so the good ones, there's quite a lot of them. So one feature that is not a traditional kind of language feature is Java interoperability. That's probably the single thing we spent the most time on. And I always say that 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.
Interop 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.
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 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 working. And some libraries actually did that, and many projects started using Kotlin bit by bit. A lot of people started with just writing tests, but then you start adding things in Kotlin, new things for example, and all the Java code around that has to transparently use the Kotlin code. So we put a lot of effort into that, and that was fun.
Can you explain to us as engineers, because it sounds like it was a freaking big project, what is the work? Because from the outside, again, I'm just being your average developer, where, all right, I'm invoking a Java class, and things I can think of, like, well, maybe Kotlin or Java doesn't support things in a certain way, or maybe... But I mean, is it really that hard? What is hard? 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 in your Java code you make a call into 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, 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. We would have to implement a Java compiler otherwise; fortunately, Java has separate compilation, so this works.
So this trick means that whenever you have, in your tooling, like in your IDE for example, when you navigate from Java sources to Kotlin sources, there has to be a special trick. So someone needs to go and teach the Java world to know about the Kotlin world. Of course the IDE doesn't do the compilation to navigate. But at compilation time we don't control the compiler. We did our own IDE, 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 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 incremental compilation algorithms are generally a very messy, very complicated heuristic that you have. So there are tons of corner cases and stuff. So that's one example.
But then 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: in 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.
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 want to be able to represent a list of anything, and then you need to play with question marks, wildcards and stuff like that. 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 subclasses 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, if they come from the Java world, as read-write, mutable collections, we call them. But
Mutable, right.
Yeah, yeah. So the Java collections are always mutable, or platform mutable, I'll talk about that later. But when you do it in Kotlin, you can actually distinguish between read-only and mutable collections.
And it's all very nice on the Kotlin side, but then when Java sees the Kotlin collections, they are normal again. 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.
Okay. I'm starting to see why you said 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 solve that.
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 ? extends and not just list of Object. So it becomes covariant for the Java world as well, and that's one hack that makes it a little more transparent, and there's a bunch of that. So that's another thing that we had to play with.
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, Java doesn't know anything about nulls, right?
Well, it knows about nulls, but not about nullable types. It does not exist.
Yeah, Java doesn't know about nulls at compile... Yes.
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 safe call operator, question mark, which will 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, very mathematical way of treating this. It's correct, right?
Yeah, you're not going to be wrong with that.
Yeah, and we implemented that and we started using it inside JetBrains and the feedback was horrible. 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. We had some annotations for the Java side; it was also brittle, not always worked, because there can be long chains and stuff, and 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 was a turning point where we sat down and reimagined the whole thing, and we worked with a great type theory, type practice I would say, guy from, I think back then he was at Cornell, Ross Tate. So Ross helped me figure out the sort of mathematical side of how you can represent those types that come from Java, where we should be aware that 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, all the nice things are gone. The actual 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 a very messy industrial kind of thing that's not sound but it works well.
Okay, and interop sounds like it was a journey, but a necessary one. How long did it take, and can you give me just a sense of how many people were working on it? Because I think in a 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?
Yeah. So let's start with that. So every time I was asked when we were going to release Kotlin, I would say one year from now.
Yep.
And 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 rewrite everything. And 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 I had no idea, and I always said, okay, a year from now is far enough, we'll probably be done by then. In practice, we started in 2010. Yeah, autumn of 2010 basically. And we released in 2016, February 2016. So it was a long time, fiveish years.
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 looked up on GitHub to verify that 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. So we started getting experienced engineers on the team a bit later. And to be fair, a lot of those people, people who are following Kotlin know those names, people who are core contributors who built out 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 younger people, they have no fear, and that's wonderful, but the balance was not right.
And how big was the team initially, and then towards the release?
So we started out basically with four people part-time, and 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.
Can you tell us about the development process inside a language? I think a lot of us are used to building services, backend services, or products or mobile apps, etc. They typically have a release process. How does this work inside a language? What is your release process, and what are the best practices? Do you even do code reviews? How can we imagine it, because again it feels like such a rare project. There are people building languages, but not many of them.
Yeah. So one peculiar thing about building languages is what's called bootstrapping, when you write your compiler in your language.
Oh, nice.
Which means that to compile your code, you need a previous version of your compiler, and you'd 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 quite a lot of bootstrapping magic going on. And I don't think it can reproduce the Kotlin builds from scratch, because if you just take a snapshot of the Kotlin repo, you can only build that with the Kotlin compiler, and I don't think we kept all the bootstrap versions. 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 we had to 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 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, many practices are very similar. We 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 I can't argue that it's much better or worse. It's just how I prefer, 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 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. 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 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 now. They're doing well. Yes.
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 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 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 were 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. We had design meetings, I think every day at some point, basically working on that: okay, let's outlaw this, let's prohibit that. And we prohibited a lot of stuff correctly and some stuff incorrectly, but generally it really worked out.
So this compatibility thing 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 Kotlin, in the Kotlin compiler, called message from the future.
Mhm.
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, 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 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 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.
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.
Andrey 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, dashboards, 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. Statsig 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 like 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 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/pragmatic. And with this, let's get back to Andrey and experimental features in Kotlin.
So we did quite a lot of work. 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 this is something we are not promising to keep compatible. This is something we're going to break. And we used to put the word experimental in package names for people to understand that this is going to be renamed, and warnings when you use language features, and we require compiler keys to enable language features, and stuff like that, and it kind of helps. So we did quite a lot of that.
So all of this is an extra layer. Unlike a SaaS 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. 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, some person out there will actually do it.
Now 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 Android happen?
Okay, so that's a complicated story. Let's try to not get off track, because this has a lot of side tracks to it. So when we started Kotlin, we were not really very aware of Android. I mean, we knew that there was a thing called Android.
Kind of ironic.
Yeah.
From now, message from the future.
Right? Yeah. So basically in 2010 we were focused on the majority of Java developers, and that was all about the server side.
Yep. I can clear.
Yeah. So the most money IntelliJ was making was on Spring users, and 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 on the server side, and it's still there and it's growing there, not as fast as on Android, but it still has quite some representation on the server side. But then a few years in, some person on the internet asked us whether Kotlin works on Android, and
I was like, I heard Android uses Java, then Kotlin should work. We never tried. Go and try. And I think it was either the same user or a different user came back and said the toolchain crashes. And it wasn't even the Kotlin toolchain. It was the Android toolchain that crashed.
And we looked into it and it turns out that it's some tool in the Android toolchain that's written in C that just fails with a core dump, and it's not very clear what's going on. And we later figured it out, and it turned out that the Android developers and the people who built the Android platform 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. 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 on 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 the Android toolchain as a testing environment basically, because this is how we could get rid of stupid things in our bytecode, and they helped us a lot with validating everything. But there were some gotchas there, and some legacy stuff nobody cares about in mainstream Java was faithfully implemented on the Android platform. That was fun.
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 an understanding of the 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 anew with a new language.
So I made sure at some point that we worked well on Android. It was already after the lawsuit. So 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 was settled in some way. Yeah. And then everyone could go their own way.
Right. But it took years and years to settle. Yeah.
So back then it was very much a thing, and so that dispute was somewhere in the background.
But yeah, so basically we saw that a lot of people on Android really liked Kotlin.
They loved it.
Yeah, as soon as it was stable pretty much. I mean, I think for all the things that you mentioned, right, it was just so much nicer than Java. Easier to write, easier to read, lots of nice features. So you used Android as a way to actually make sure that Kotlin compiled correctly, and then why did it take off on Android?
Yeah. So the situation in Android was pretty interesting, because unlike Java server side, which 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, 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 Retrolambda really helped, and so on and so forth, but there were still a lot of people stuck with really old Java. So Java wasn't on par with Kotlin or C# in 2014, but it still was much better 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, and also there was Swift on iOS.
Oh yeah.
Where it was a real example of a big ecosystem transitioning from a really dated language to something
really nice.
Yep.
And I think these two things compounding were 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 we had a nice plugin, because everything worked on the IntelliJ platform, and the same plugin worked for Android and many other things. It was 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 maybe talk about it or something, and it just didn't happen. So we released in 2016, and we had some communication with Google in general, but there was no interest on that side. We're like, okay, 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 kudos to the brave people because they gave us invaluable feedback, but you guys are too brave.
Yeah. So it just grew organically. And when we started in the very beginning, I set this internal goal for 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 a language has, but 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. 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 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 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 really, really close. 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 how do we set up processes and everything. But there was a big legal thing around it. This is when the Kotlin Foundation was invented, and we had to design the protocols for decision-making in the Kotlin Foundation. And Google owned the trademark for Kotlin for one year because of legal things. It was basically a guarantee from the JetBrains side until the foundation got 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 it was transferred to the foundation. So 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. That was
And that usage must have skyrocketed. You probably blew past 100,000 pretty quickly.
Yes. Yes, I think we went... Yeah, we probably got into millions that year. This was basically the moment happening. And I knew many years before that, I knew that the easiest way for a language to succeed is to be part of a platform. Like C was part of Unix basically, or C# 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 a much tougher time for Kotlin than for some other languages, but yeah, the platform came along somehow.
Jumping forward a lot closer to today, you left Kotlin in 2020, later you left JetBrains. What are you doing right now?
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 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 today we have a great opportunity to do the same thing at a different level.
Because of AI. Because of AI.
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. That would be very nice.
So on the one hand, the entire history of 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.
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 levels some more, but now we can do even better.
So you can imagine 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. You explain what the program needs to do, and I can implement it, and it will work the way you want. 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.
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 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 the essence of software engineering when you are not 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 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?
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 the way new languages will be, because you can think about the ultimate language of today as a normal programming language that uses an LLM as a library.
There was a time when npm was wonderful, because it's a huge repository of all kinds of JavaScript libraries.
Package manager, one of the biggest packages in the world. Right.
Right. 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.
Yeah, you need to prompt.
Right. And the trick is, 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 how formal we can make it, and it's not the goal to make it super restricted, but the goal is to leverage all the power and support the user. We need to rule out stupid mistakes and things like that, and we're still working on that. But the basic idea is, 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, and you will just get there much faster.
Mhm. 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 concisely 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?
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 a 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. For example, right now the newer languages are just harder for LLMs than the more established ones. 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, because it's not as present in the training set, because it's younger. And there are ways around it, and I think the later models added some more Kotlin into the RL sets, and it's getting better, but still it's pretty hard. And so that's challenge number one.
Also, challenge number two: I don't think there necessarily 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, the existing code, and inventing a new language for that, I don't know how promising that can be.
You can do another thing, which is an interesting research project. You can sort of extract a language from an LLM, because 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 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 on 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 are a lot more compact, but also this code you represent 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, and 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, or 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 nowadays, if you work with AI, everything is a machine learning problem. And that means, 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 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 look at you, 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 I'll say software engineering, is being changed 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've written so much code in your life. And are you still writing code?
Yeah, I'm writing some code. Yeah. And...
Sorry, typing or prompting?
I'm doing both. Sometimes I'm just typing. 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 IDEs. And I think IntelliJ has something similar now. So 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.
Claude Code and Cursor agent and so on, so forth.
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 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.
A big problem.
Yeah. 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.
So yeah, 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 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."
And I think another big theme of today is that we'll be doing a lot of testing, and 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, and verifying might not mean reviewing.
Right. So,
Or it could not mean...
Yeah, depending on the domain, 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. That's very interesting computer science. And also it's now a question of, especially in the case of CodeSpeak, 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 was to be done? It's tricky. Some tests will be just very long and tedious to read, 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 language servers, and basically all the stuff that we've always had for code is not very utilized. And you know, if you compare IDE-integrated agents like Cursor or Junie at JetBrains, you have a lot of code navigation capability, and databases of code; code is indexed and you can navigate it very quickly. You can find things very quickly. When you run Claude 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 I'm sure this year all these tools come to most agents, and we'll 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 sort of in the end game, or in further future. And there it's very hard to predict, and we can assume that models will become much smarter, but the 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. 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 a tool for humans, not for models.
Yeah.
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. And this has a name, it's called technological singularity.
When humans are not making decisions, it means we're not in charge.
Yep.
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. But 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. 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 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 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.
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 Claude Code, Cursor, with others. But what are areas that you think we will see, we will have to see new, different, better tools to actually just catch up 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?
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 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 Claude 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. 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. It's not going to happen this year. But maybe some advances will arrive 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 off, 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, I...
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, and 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 coding 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? I talked with some folks, a lot of people message me as well. How are you thinking about this, specifically these last few months?
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 more and more news about people not hiring junior developers, for example. This is dumb.
It's stupid.
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, then it's no good." There is quite a bit of skill to using these tools. 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, 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 new grads, people coming out of university, what would your advice be for them, who are 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?
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 like, there is a lot to be done there. If you can or like to do 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, 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 you shoot what comes next. What is a favorite tool that you have? It can be digital. It doesn't have to be digital.
Well, I love my AirPods. They're incredibly convenient. They fit under my ear muffs. Well, another tool would be ear muffs. Earmuffs.
Incredibly good.
Yeah, I saw you wearing it. I'll take that one. Ear muff. And what's a book recommendation that you recommend, and why?
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, Andrey, thank you so much. This was very interesting and I think inspiring as well.
Thank you very much. It was a great chat.
It was great. Thank you.
The thing that struck me most from this conversation with Andrey 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 with your teammates in code, in machine language. Whether or not CodeSpeak is the answer, what is sure is 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
Article published