Why would anyone create a new

programming language today if AI can

already write most of your code? Andrew

Brela has an interesting answer. Andre

is the creator of Cotlin, a language

that runs on billions of Android devices

and is one of the fastest growing

languages in the world. Today we cover

how Andre designed Cotlin by

deliberately borrowing ideas from Scala,

C and Groovy, and why he considers

leaving out the turnary operator one of

his biggest regrets. Why making Cotlin

interoperate seamlessly with Java was a

gigantic undertaking and what it took to

get it done. How Cotlin adoption went

through the roof after Google announced

it making it the official language for

Android in a move that even took Andre

and the Cotlin team by surprise. Andre's

new project Codespeak, a new programming

language built on English designed for

an era where AI writes most of the code.

If you're interested in the future of

programming languages from someone who

built one of the most loved languages of

today, then this episode is for you.

This episode is presented by Statsig,

the unified platform for flags,

analytics, experiments, and more. Check

out the show notes to learn more about

them and our other season sponsors,

Sonar and Work OS. Andre, welcome to the

podcast.

>> Hello. Uh, thank you for having me.

>> It is not often that I meet someone who

designed such an influential language

across mobile across back end. So, let's

start with how did it all started? Okay,

so that was a little messy because I

went to school uh back in St. Petersburg

uh started studied computer science and

I didn't really know exactly what kind

of programmer I wanted to become. I knew

I wanted to be a programmer and then you

know at some point while I was still in

the university I started teaching uh

programming in school and uh 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 they

went under pretty soon after I joined

and I hope it's not because of me. Yeah,

but but I worked on the it was at the

tail end of the UML era. So, we were

doing some developer tools in the UML

space. That was very interesting. I

learned a lot. But then Borland went

under and I went back to teaching

full-time and then I started PhD school

and you know all that was kind of not

really planned out and uh in my PhD I

was working on domain specific languages

and generally I was interested in

languages. was something I was curious

about and specifically typed languages

were interesting. I was always curious

about how these things worked but never

really serious. When I started looking

into DSLs, it was uh slightly more

serious, although my PhD was a mess and

I never defended because of that. Uh but

at some point um you know some someone

reached out. It was actually a person

who was in charge of the Orland St.

Petersburg and by that time he was

already at Jet Brains and he reached out

uh to me while I was in Tarto in

Estonia. I was there for a year on as a

visiting PhD student. It was a lovely

time. Um so he he reached out and

invited me to when when I next visited

St. Petersburg to visit the Jet Brains

office there and talk about something

about languages.

What I thought was that there was about

the this project called MPS

metarogramming system that Jet Brains

had. I knew about it. It's about DSLs. I

worked on DSLs. You know, it was

generally something like plausible that

they would be interested in talking

about stuff like that. But it turned out

I was completely wrong. And what they

wanted was to start a new programming

link.

>> And I was completely unprepared for

that.

like I you know I've never thought about

doing something like this and my first

reaction was you don't do a new language

like you don't need it and the the the

basic pitch was uh that the Java

ecosystem needs a new language Java is

outdated so on so forth we can talk a

little more about this it was 2010 I

think yeah 2010 um yeah and uh I was

like but there there are other languages

like everybody's doing fine why do you

need to do that and And this

conversation was actually a very

insightful one because uh the guys at J

brains they uh simply explained to me

how the things actually were and you

know it was it was a big problem by that

time. So Java didn't really evolve uh

and hadn't been for for a long time.

>> What was the reason behind it? Can you

take us back for those of us who are not

in the ins and outs? Yeah. So, uh the

last major version of Java uh by 2010

was Java 5 that was released in 2004.

>> Oo. Six year old language.

>> Yeah. And since then there there were

updates. There was Java 6 that made no

changes to the language as at all.

>> And then there was Java 7 that made

minor changes. In parallel there there

were things that that were happening in

other languages, especially C was

progressing very well. And by 2010, C#

had all the nice things. There already

were lambdas like horror functions and

and all that nice stuff. There were

getters and setters and and many other

things that made the language much

nicer. And Java was felt like it was

standing still. And there was a project

uh to to work on lambdas for Java, but

that what was in the works and had been

in the works for a long time and only

came out in 2014. So that was the

situation and you know uh the the

ecosystem didn't stand still in the

sense that other people were building

languages and there was Scala there was

Groovy and of course people at J brains

knew both Scala and Groovy they built

tools for them. It's traditional to

build your tools in the language you're

building uh the tools for. So the Scala

plug-in was built in Scala and there was

a lot of Groovy used Jet Brains 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 like best use cases?

So the trade-off I guess if you look at

a like a statically typeyped language

like Java and Cotlin and Scala for

example versus dynamic languages like

Python and Ruby and JavaScript and uh

Groovy. Uh in dynamic languages it's

very easy to start and build something

working very quickly because basically

the language is not in your way as much.

There's this saying that nothing limits

the imagination of a programmer like a

compiler.

And you know this may be changing

nowadays a little bit and this is in

part what I'm working on now but um back

in the day was completely true. You know

the the the whole art of uh making a

good language was to restrict the user

in a good way. Uh yeah, but in any case,

the the situation with dynamic languages

is that they are much more user friendly

in the beginning, but then when the

project scales, you have trouble making

large refactorings. You have trouble

making sure that everything works

together. where you need to do a lot

more testing and rely on other things

like that as opposed to static languages

where you have uh you know precise

refactoring tools and and other things

that can make sure that at least a

certain class of problems just doesn't

happen. And you know this is why in at

least in our mind back then it was

absolutely clear that if we're building

a language for uh large projects, big

teams so on so forth it has to be a

static lang

>> static one. Yes.

>> Uh yeah. So with Groovy that was a big

issue performance as well because Groovy

was building a dynamic language on top

of a very static runtime. So there was

quite a bit of tension there. Uh so that

was in the Groovy side and the Scala

side. Scala is a wonderful static

language and incredibly powerful and

with tons and tons of good ideas but it

had its own problems. It relied very

heavily on implicit for example and I

have a history of debugging one line of

Scala for an hour to try and figure out

what it does just because you know it

was pretty complicated and also the

compiler was very slow and there were

issues of stability and many many things

were just not accessible enough for for

a lot of engineers. So from the

experience of using scala jet brains my

colleagues basically understood that

it's not what's going to change the

industry although scala got a lot of

adoption and again like Martin and Derki

is a great language designer you know

and and uh

>> I think one of the biggest use cases was

old Twitter a lot of it was built on

scala and they scaled to however you

know massive scale etc

>> and I think LinkedIn as well yeah so in

any case uh these were you uh it's

always very nice when other languages uh

kind of pioneer things and then you can

build on top of uh their successes and

failure and we were in that position

basically. So the the argument that

people at Jet Brains were making uh was

basically that uh there is a window of

opportunity. People need this language.

We Jet Brains are the company who can

actually put out a language and make it

successful because we have access to the

users. We have their trust. We can make

good tools. And it was another issue

with Scala. For example, it was very

difficult to build tools for Scala back

then. Now Scala 3 is more tooling

friendly. But back then it was a

nightmare. Like I said that you know if

if you have a static language you can't

have precise refactorings if the

language is not too complex and you know

some languages are particularly

challenging. So Scala back then and C++

were incredibly challenging to make

precise tools for. So, and that was that

was the basic pitch and I quickly

understood that yeah, they were right

and this was something that was worth a

shot in the sense that it was not

completely hopeless, not completely dead

in the water. I had no idea if we could

pull it off. It's it was then when we

actually sketched like some initial

features on the whiteboard

just because Jet Brains is generally run

by engineers. Hold that thought from

Android on how Jet Brains is genuinely

run by engineers. This is because I

happen to know another company also run

by engineers. Sonar, our season sponsor.

If there's a time when we need true

engineers, it's now. As AI coding

assistants change how we build software,

code is generated faster than before.

But engineuring basics remain important.

We still need to verify all this new AI

generated code for quality, security,

reliability, and maintainability. A

question that is tricky to answer. How

do we get the speed of AI without

inheriting a mountain of risk? Sonar,

the makers of Sonar Cube, has a really

clear way of framing this. Vibe then

verify. The Vibe part is about giving

your teams the freedom to use these AI

tools to innovate and build quickly. The

verify part is the essential automated

guardrail. is the independent

verification that checks all code human

and AI generated against your quality

and security standards. Helping

developers and organizational leaders

get the most out of AI while still

keeping quality, security, and

maintainably high is one of the main

themes of the upcoming Sonar Summit.

It's not just a user conference. It's

where devs, platform engineers, and

engineering leaders are coming together

to share practical strategies for this

new era. I'm excited to share that I'll

be speaking there as well. If you're

trying to figure out how to adopt AI

without sacrificing cold quality, join

us at the Sonar Summit to see the agenda

and register for the event on March the

3rd, head to

sonarsource.com/pragmatic/onarsummit.

So, everybody I talked with uh were

deeply in the in the weeds with with IDs

and everything and new programming

languages very well and you know, we had

a very technical discussion. So I don't

remember exactly all of the features

we're talking about but the current

syntax for extensions in Cotlin was

already there. Uh and I don't remember

why exactly we focused on extensions but

it was there. So you know from day one

we were basically building on top of

ideas from other languages like

extensions obviously came from C. Yeah.

So it was it was a very exciting

conversation

but I didn't make a decision then uh

because I I was in Tarto and I needed to

finish there and it took me a few months

to finish and then I came to St.

Petersburg for one month because after

that I had a an internship scheduled

with Microsoft research in Redmond. So I

was going to Seattle to stay there for

like three and a half months and I was

like okay guys so I have this month I

can work in the office and we can try to

sketch things but then I'll go into

Microsoft and then I will decide whether

I commit or not which in hindsight I

mean

um well I made the right decision in the

end. I had a great time uh for for this

month or so um I worked uh with the guys

in the office. It was mostly Max Trafi

we were working with and it was

incredible like we had such great

discussions and I I actually saw Max

this morning and uh it was like it was

great time. So then I went to Seattle

did something completely different

there. Microsoft research saw really

great researchers. Uh working there

actually was exposed to like the

top-notch level of academia for the

first time was very insightful. But

after that I kind of realized what the

question was whether I want to sort of

try to pursue an academic career which

you know I didn't feel like I was really

built for that and was not sure whether

I can be like a good researcher on my

own or I'll I'll have to follow in

somebody else's footsteps

uh versus like do a crazy thing and

build my own language here. I'm like

okay I'm doing the crazy thing. So for

those of us engineers which will be the

majority who have not built a language

from scratch,

how do you start with it? Like you know

we we know speaking for myself I know

how to write code. I know how to open

the editor. I know how to write hello

world and a more complex app and even

more complex one. How does a language

start?

>> In our case we basically talked a lot

for a few months. So it's I think not

everyone is like that but I think the

best when I'm talking to people and this

was the ideal environment because we

were basically discussing things with

the max constantly for many months and

there were a few presentations internal

that I made at J brains and some of the

slides survived so I can see including

my spelling mistakes in those slides my

English wasn't as good then and you can

you can see some some of the evolution

through those slides and I think there's

a recording of one of those

presentations. So we were basically

doing whiteboard design for some time

and the great thing about doing this at

Jet Brains was that there were a lot of

people with opinions about not so much

how to make a language but what problems

do programmers face and what they like

and don't like in other languages. So I

had a tons of tons of input from other

people and very good people. So that

helped. And I really I don't think I

realized how special that environment

was back then. Like I was 26 to be

clear. And I had no idea how things were

done in general.

But somehow these people just trusted

me. I I'm not sure it was very rational

on their part. worked out, but I'm not

sure I would recommend anyone to do

this.

>> And so in the first few months, do I

understand that you kind of whiteboarded

and you kind of wrote down how you want

this language to evolve? You kind of,

you know, like wrote out like we're

going to have these features or how can

we imagine?

>> I guess the easiest way to explain this

would be like this. So we basically went

off what the pains were with Java and

there were quite a few and and there was

a lot of experience of using Java uh

across the community and inside Jet

Brains and we kept making lists of

things we wanted to fix and I came up

with some ideas and some other people

suggested other ideas about how things

can be fixed and what is an actual

problem and what we don't care about and

so on so forth. uh and for some time I

was just you know pieces of the puzzle

basically laid out in a table without

fitting together and then at some point

we started fitting them together and I

was just doing a lot of that in my head

which is not the best way but this is

how I knew how to do it. There were also

some crazy ideas uh that we thought were

important back then for example I wanted

to implement multiple inheritance fully

fledged multiple inheritance.

>> Mhm. which was a dumb idea.

>> Multiple inherits meaning that a class

can inherit from like several classes.

Yeah. And and you you have to take care

of like conflict resolution and all

sorts of edge cases,

>> right? Yeah. So, so the the actual

challenge is not so much conflict

resolution in terms of methods, but

initialization of state constructors are

really hard. It was actually someone

outside of JBR who explained to me that

was a very bad idea and I'm very

grateful to them. Yeah. So you know

there were crazy ideas uh as well and

some of them just fall off over time as

we were discussing or prototyping and we

I think I started writing code maybe 6

months in or something like that maybe

maybe a little earlier than that and I

started with a parser and it was

actually it was a very also a very

unique way to start a language because

the idea was to start not with a

compiler but with an ID plugin. I have

it in the editor first which is you know

an ID plug-in shares a lot with the

front end of the compiler so it's not

absolutely crazy but I was just relying

a lot on the infrastructure that was

available in intellig idea so all the

parsing infrastructure and it it was

awesome like parsing infrastructure

intellig ID is better than anything else

in the world because it's it's the heart

of the ID it has to be incredibly fast

and very robust and so but then later

someone who knew the infrastructure a

lot better than I do. Uh had to factor

that bit out to make the column compiler

autonomous. And it was the Mit Jemer who

did that. And he's a awesome engineer.

Like he's probably one of the best

people to refactor a large code base and

then like take this one bit out of

something that that was already 10 plus

years old back then. So we started with

this ID plugin. I think Max wrote the

scaffold and I actually plugged in the

parser and everything. And that was that

was an interesting story because it was

very interactive. So I could show off

the language as if it existed because it

has had some tooling but I couldn't

compile anything in the very beginning

and that was was actually a very good

way to experiment with the syntax but

then soon after I started working on a

full-fledged front end and on some

translation and Ditri and Alex Katchman

were working on the back end. Everybody

was part-time. uh when you say you work

on front end they work on back end in a

language context what does that mean

>> it's slightly different in different

languages but basically the front end is

what deals with the syntax and with the

checking and understanding what the

program means and the back end is what

translates to the executable code in our

case u the front end is like reading the

text and parsing and doing types and and

all that and the back end generates Java

bite code and cotlin has multiple

backends for different target languages

is like we have Java back end, we have a

native back end for our uh like iOS and

and other native platforms and

JavaScript back end wasn't back. At that

time, nobody was full-time working on

this project. Even I was part-time a PhD

student and part-time cotton developer.

And it was like the very early days. And

then at some point, I gave up my PhD and

focused 100%. Which was also like it's a

isn't it a a weird decision to start a

new language part-time?

>> Yeah. Looking back, I was young and

stupid.

>> 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. that I didn't realize how

hard the problem was. I was I also had

an unreasonable amount of hubris. I just

thought I I knew how to do everything. I

didn't. But it worked out in the end.

>> So when the language started, what did

you call it internally? There's always

internal code names, right?

>> Right. Yeah. So u I don't think there

was a discussion of this first name at

all. It was just generally understood

that the language will be named Jet and

it was logical. So we had all the code

base was uh using the name jet or we had

a jet parser and you know jet editor or

whatever jet highlighter something like

that and then someone realized that the

that the name was trademarked by someone

else and it was actually people we we

know there in Novaskin Russia doing

something it's not a language it's a

comp but it is a compiler um and we

couldn't use it and this is When we

started looking for another name, it was

very painful.

Like looking for names, guys, this is so

bad. It's one one of the worst things

because you never know what name will

work unless you want to do like an

extensive study and then all the good

names are taken of course and then some

of the names that are not taken are not

taken because they're not really

googleable and you know some people are

just very brave people who named their

language go. This is why people now call

it Golang because otherwise you can't

identify it. It's it's it's a verb in

English and very common one. Uh yeah, so

we had weird options and I in one of my

old old presentations I found a list of

early names and we had robusta there as

a flavor of co coffee and we had up for

example or G or something else like that

and those weren't great by that time.

other languages were popping up and one

of the alternative languages was was

called son and the logic was that Java

was the island of coffee and salon was

an island of tea and uh midriov

basically looked out of the window and

said okay we have an island here in St.

Petersburg in the Gulf of Finland

there's a big island called Scotland and

it's a good name in the sense that it's

very googable. Nobody uses it for

anything. It's very recognizable. It's

not super

smooth for many languages, but it's kind

of okay. Nobody was in love with that

name.

And we were kind of hesitant and you

know cot means a bad thing in German.

And also there was like some some

negative connotation in Mandarin I was

told or something like that. you know

it's always some language has some nasty

association with any word and we

basically were super hesitant so when we

announced and we we had this deadline so

we were basically putting this off when

we announced we were still not sure so

we called it we decided would be a code

name we called it project cotlin

uh to have a wiggle room to later

replace the name but it stuck the first

thing we we did we put out a uh

basically a confluence page with a

description of a language. It was just a

bunch of wiki pages and there was no

compiler available, no nothing. And

there uh you know the the word cotlin

appeared many many times. I was like my

god this thing doesn't like I can't do

search and replace and then change the

name everywhere. So the workaround that

I came up with was create an empty page

called cotlin and it so it has a name

and then everywhere else you mention it

as a page and when you rename a page it

gets renamed everywhere. So this is why

there was an empty page called cotlin in

that documentation. Uh but yeah the name

stuck and it turns out to be not a bad

name.

>> So when it started what were the main

differences with cotlin compared to java

because java was what was the big one?

How how did you explain to developers uh

you know who initially start on board or

wanted to give it a go? Yeah, I guess

there were a few major selling points

and then there were other things on top

of that. When we started like in the

very beginning, we didn't have uh null

safety in mind. Null safety came a

little later after one of the internal

presentations. It was Maxurov who

invited Roman Yazarov who later was the

project lead for Cotlin. and Roman came

and and listened to the presentation,

gave some feedback and said like guys,

if you want to do something really big

for enterprise developers, figure out

null safety and we did and it took a

while. So, uh in the very beginning it

was the general idea of like what makes

Java feel so outdated and there there

were a bunch of things. Lambdas were

very big. The general like the general

uh feeling from Java back then was it

was very verbose. It was called the

ceremony language. You know a lot of

people were grumpy about too many

keywords like public static void main is

something everybody was really grumpy

about. But also you know there were

getters and setters for every property.

There were you know constructors and

overloads and all that stuff that looks

like boiler plate because it is.

>> Yeah.

>> And you know

>> is super annoying to type out.

>> Yeah. and and you know the the problem

with boilerplate is on the one hand it's

annoying to type out but tools can

generate it for you and fold it and so

on so forth. Uh but the bigger problem

is always readability. So reading is

more important reading code is more

important than writing code. We do a lot

more of that and with boilerplate it's

terrible because if some tiny thing is

different in the middle of completely

standard boilerplate code you'll miss

it. you become blind to it and you you

can debug for days not seeing them. So,

you know, that that was the point of um

sort of modernizing Java, making Java

programs be more about what they do and

less about the ceremony of making the

compiler happy basically. And you know

type inference was also a big thing

because Java was repeating types a lot

and many other things like that where

like semicolons you know but the modern

languages of the time already got rid of

semicolons

>> and and so in cotlin you also got rid of

it.

>> Yeah. Yeah. So we we got rid basically

in terms of syntax we got rid of uh

semicolons and duplicated types and that

was a lot of noise of code. What does it

mean that Java had duplicated types?

>> Yeah. So in um that version of Java when

you declare say a local variable you you

say it's a list of string called strings

equals new array list of string.

>> Oh yes I remember this one. Yes. Yes.

You need to type it out twice and if you

get one of them wrong compile error etc.

>> Right. So and at best uh you could omit

the second mention of string by using a

diamond operator but that only came

later. you know, basically was very

robust, especially if your types are

long. Like if it's if it's just a list

of string, it's sort of not so bad, but

if it's a map from something to some to

a list of string, for example, that's

already really long and you don't want

to read that. So, and a bunch of things

like that were

really annoying to a lot of people,

especially compared to C# or Scala.

So we we did all of that and then uh you

know on top of that were there were

other value add features and null safety

was a big thing that we spend multiple

years actually on implementing and I

think it's one of the main

differentiating factors now for cotlin

alongside of with extensions and other

things uh but null safety is one of the

core features

>> and can can we just spell out why null

safety is so big I mean I just today I

came across a bug on the I I couldn't

send a package because in JavaScript in

the Dutch post website there's a null

issue happening in production. Uh but

you know like before cotlin and in a lot

of languages why is it such a big

problem? It is.

>> Yeah. So, u dealing with null references

uh is a big hassle in most languages and

I think it was uh Tony Ho who um called

called it the billiond dollar mistake at

some point because like introducing I

think it was about introducing uh null

pointers to C or something. Uh so

basically when we look at all the

runtime errors that we have in Java code

I think null pointer exceptions will be

at the top. You know the type system of

the of the language is supposed to

protect you from those unexpected

errors. So there are errors you're

designed for and maybe errors that are

not even your fault like you know file

system error or something like that. But

there are also um errors that should be

prevented by the compiler. So for

example, class cast class exception or

missing method error for example are

things that the compiler is trying to

protect you for. It's trying to make

sure that this never happens in your

program if unless you you know switch

off the check by making an enforced cast

or something. Yeah.

>> And with nulls it's not a thing in Java

like anything can be null and if it's

null it will just fail.

>> Yeah. It throws an exception and dies.

>> It's a very common thing. So a lot of

people are kind of used to it and there

there are like different ways of being

disciplined about it and so on so forth

but basically this is a plague across

any code base you know there there are

different approaches to this and in

cotlin we took the approach of a

enforcing enforcing in the type system

but also making it free at runtime.

>> What what does that mean that you made

it free? 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 like you have

to allocate it, you have to carry it

around everywhere and you know this this

easily creates a lot of objects in the

old generation for the garbage

collector. uh can be challenging and

what we did was uh just have a direct

reference at runtime. Our nullable or

not null reference is the same as Java's

reference. All we do is compile time

checking and some runtime checking when

we cross the boundary. But that's a lot

cheaper than allocating objects.

Although you know the runtime is getting

better and they kind of can optimize

some some of those objects away, but

still like it's it's an overhead. What

what are features that you took in from

Cotlin that were inspired by other

languages that you admired?

>> A lot of them. I have an entire talk

about this. It's called Shoulders of

Giants and we uh really learned from

lots and lots of languages and it was

always the point.

>> Andre just mentioned how Cotlin was

built on top of the shoulders of giants

taking good ideas that existed not

reinventing them. This was one of the

reasons Cotlin succeeded as much as it

did. But jumping forward from 2010 to

2026, one thing that is totally

different today is the speed of things.

AI is allowing nimble teams to build

faster than ever before. Companies that

used to take years to move into the

enterprise are doing it in months. This

speed creates a new problem. Enterprise

requirements, authentication, security,

access controls show up almost

immediately. This is where Work OS, our

season sponsor, comes in. Work OS is the

infrastructure layer that helps AI

companies handle that complexity without

slowing down. SSO for enterprise buyers,

MCP offer agendic workflows, even

protection against free trial abuse with

radar. Teams like OpenAI, Cursor,

Perplexity, and Versell rely on work to

power identity and security as they

scale. If you're building AI software

and want to move fast and meet

enterprise expectations, check out

worker.com. With this, let's get back to

Andre and how Cotlin was standing on the

shoulders of giants. So the slogan for

Cotlin was pragmatic language for

industry and the pragmatic bit which I

mean is a nice uh sort of nice rhyme

with with your podcast. Uh the pragmatic

bit was kind of coming from the

experience with Scala being called an

academic language and a lot of people

having trouble getting their heads

around a lot of the very smart tricks in

the design. And so so our idea was like

we're not doing academic research here.

We're not trying to invent anything.

like if we don't get to invent anything

it's a good thing not a bad thing and I

think from the engineering perspective

it's generally a good idea to to do this

usually you end up making something new

but the most of what you're doing

shouldn't be very new because you want

familiarity you want people to easily

grasp what you're doing and this has to

be familiar from other languages and

also if you're taking you know building

on top of the ideas of other languages

you have the benefit of them having

tried it and you can look at their

designs and their community's reactions

and and all that and the implications

all over the place and that gives you a

huge benefit. So we did a lot of that

and I think the language that influenced

cotlin the most is of course Java

because you know we the entire runtime

of cotlin is the JVM and we depend on

that but apart from that Scala had a

huge influence and and we used so many

ideas from Scala from you know primary

constructors and data classes and uh

valves and varss and and all these

things and to some interesting tricks

about how generics work for example you

know var Ians declarations

is a great idea of Martians and it's a

huge pity that it didn't uh make it into

Java design. It was flipped at the very

end of the design process to what Java

has now and it's definitely the the

Mart's idea was much better. We had to

sort of on the boundary model Java

boundary we had to fix the problem of

Java having it different and figure that

out. There were like many many ideas we

took from Scala and that was very

helpful and we usually we transformed

those ideas a little bit to adapt to to

our setting and to build on the

knowledge of how it actually works in

practice and we left some things out. We

simplified some things. For example,

Scala had traits and traits are a very

powerful construct where it's it's it's

like an interface

and you can have method implementations

uh in traits but also in Scala traits

you could have fields as well properties

that what what you couldn't have was um

constructor arguments like you have

always have a default constructor and

can initialize all your fields and it's

not as bad as multiple inheritance in ++

uh but it's still a little complicated

when it comes to in what order you're

calling the constructors that we decided

we we don't want to deal with that it's

a complex algorithm it's hard to explain

let's just get rid of the state and

interfaces and only have method bodies

and I think it was a good compromise

especially given that Java ended up in

the same place it was easier to

integrate yeah so Scala was a big

influence uh C was a very big influence

uh extensions

of course and we learned quite a lot

from how C# compilers do things. Uh

there there was also one particular

trick that makes uh Cotlin syntax a lot

nicer, nicer than Javas and nicer than

Scalas that we learned from C#. It was

actually my colleague uh who worked on

the C# ID who told me about this which

is basically a super programmatic thing

they do in C#. There is like when you

call generic functions,

you use uh angle brackets.

>> Yeah.

>> Uh 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 and the parser can easily get

conf confused and think that this

expression since we're not in a type

context, it's an expression context.

This expression is a comparison. It's

not uh an inequality, right? It's it's

not a call. And this is mathematically

unresolvable. It's it's an ambiguous

grammar. Yeah, look, you can't do

anything about it. And uh the way other

languages handle this is Java, for

example, when you're passing uh type

arguments to a call, it has to be after

a dot. So you say collections dot angle

brackets. Yeah. The

>> function name.

>> Really awkward.

>> Kind of weird.

>> Yeah.

>> Uh and the way Scala deals with that,

they use square brackets for types. And

then arrays can't use square brackets,

so they use round brackets,

which is unfamiliar. Like it's not the

end of the world. Scala is doing fine,

but still like and C uses angle brackets

because there's a hack in the parser

that basically disambiguates ad hoc and

we did the same or something very

similar and it just works and the syntax

is very familiar and very intuitive and

we're very happy about when you read it.

I as a as a person I never get confused

like this is not a smaller sign like I

know it's a yeah so most of the time

it's not a practical problem um yeah and

it's then there is a way to dismbiguate

if if you like so C# was a big influence

groovy was a big influence as well jet

brains used um groovy for uh build

scripts and there were incredibly useful

patterns in in the groovy syntax that

they call builders which is not about

building programs but you know building

objects and Uh this is what inspired

something fairly novel that we did in

Cotlin which was types builders where we

had the same syntactic flexibility or

almost the same syntactic flexibility as

Groovy but it was all typed and we could

make sure that all the arguments matched

and so on so forth. So all that side

basically was inspired by how groovy

people did this and reworked into a

typed setting. And this is why we have

for example extension function types and

this is why we have um dangling lambdas

and other things that are actually very

nice syntactic constructs. So yeah many

many things uh came from different

languages. A less known language called

gou I think uh it was what inspired us

to do smartcasts.

>> What are smart casts?

>> Oh yeah. So

I I think smart costs are one of the

nicest things a compiler can do to a

developer because it's a very common

situation when you say if x is string so

you do an instance of check basically

then do something with x. The annoying

thing is that in a lot of languages you

have to cast x to string again like

you've after you've done the the if you

you know it's a string but then

>> you need to write it out again.

>> Yeah. So you've just done the check but

you have to say string again

>> to make the compiler happy. So smart

cast basically get rid of that. So that

cast gets figured out automatically.

>> So if string and then inside the bracket

you can now use it because it's a

string. Yeah, you can use it as a

string. And isn't it an easy thing,

right?

>> So nice.

>> Yeah, it's it's a very nice thing. Yeah,

it's a pretty complicated algorithm

because you know variables can change

values and the check that you've just

made can go stale and you know there's a

bunch of u algorithmic trickery around

this and you can't do a smart guess on

any expression has to be a certain type

of expression that can be stable enough

and so on so forth. But you know it's a

very nice thing and you can get rid of

so much noise in the code because like

all the code in the world is riddled

with this instance of cast instance of

cast. So we wanted to get rid of that

and it worked and it was fun to

implement.

>> What were things that you looked at

other languages

you considered maybe we should bring it

in but you after debate you're like no

let's just let's just leave this out

like not all of them obviously but some

of the big ones that kind of came close.

We had a design for pattern match in

Cotlin uh that was inspired by

functional languages like like Scal and

Haskell and and others. Uh but at some

point it was early on when I was still

working on the parser I just realized

that this is a huge feature. So when

when I was sketching it out on on a

piece of paper it looked like a very

useful thing you know and just another

feature in the language. But then when I

started working on the parts I realized

it's an entire language in size like you

have to create a parallel universe in

syntax for pattern matching I was like

okay this will be a lot of work let's

postpone it and then later on uh when we

were doing review for 1.0 Oh, or maybe a

little earlier than that. I just

realized that smart casts plus we have

something called the structuring

together they give us like 80% of all

the good things pattern matching can do

to normal developers. And then there is

another

group of developers that can be very

vocal which are mostly compiler

developers and people super into

functional programming. uh and they have

a point but that point is only relevant

to them when there are not very many

that we decided to not have pattern

matching back then and you know maybe

there comes a day that pattern matching

gets added to cotlin

>> and pattern matching is is it in in the

case

>> yeah it's

>> statement so you can have like a lot

nicer case statements a lot more

expressive ones right

>> yeah so generally uh so con has this

compromise where you have our version of

switch case which is called when and you

can have smart costs there. So you can

say like when my expression is a string

and then use it as a string or it is a

pair and then you can use it as a pair.

So that kind of gives you a lot of the

nicities of pattern matching but some

things you can't express like and you

know that was I think it was a good

compromise because it's a really big

feature. It's hard to design well that

will would be a lot of work on the

tooling side. So, you know, but maybe it

gets in the road map one day. I'm not

sure. Java is trying to get towards

pattern matching. So, we'll see. Maybe

they kind of make it more mainstream.

>> Why did you omit the infamous turnary

operator which is when you write out

something a question mark and a dot and

it confuses new developers every single

time if you've not seen it before.

>> Yeah.

>> Was it for readable reasons?

>> This is the saddest story I think the

design of Cotlin. I didn't realize how

much people liked it and yeah so so the

reason was uh so cotlin used this

principle from functional languages that

everything we can make an expression is

an expression. So if is not a statement

and cotlin is an expression and the

turnary operator is the sort of a patch

on the design on on C and other C like

languages that makes an if expression

basically and the logic was okay we have

if as an expression already can we just

get rid of this extra syntax construct

especially given that it's uh using very

precious characters like there is a

question mark and a colon and we might

find some other use for that. So we

decided to not have it. We used question

marks for nullable things and colons for

types and so forth. But it turned out

that if uh as an expression is pretty

verbose people don't like it and and

like I I resisted for some time and then

by the time I agreed it was too late

because you can't retrofit the turnary

operator and the current syntax in

Cotlin because it just doesn't agree

with how other operators are done. So

you're actually sad about it not being

there a little bit.

>> Yeah, it's I think in retrospect it was

a mistake because you know pragmatically

it's more use than harm to have it but

we just can't retrofit it.

>> What are some other interesting uh

features that you like about the

language that that you added that we

could just explain for those who are not

familiar?

>> Okay, so the the good ones there's quite

a lot of them. So one feature that

you know not is not a traditional kind

of language feature is Java

interperability. That's probably

the single thing we spend the most time

on. And I always say that you know if if

someone offers you a job to create a

system that interoperates transparently

with another huge system you don't

control, ask for a lot of money. It's a

very tricky deal to to to figure this

out.

>> Interpreter means that from cotlin you

can invoke Java and from Java you can

invoke cotlin and I mean you do a bunch

of work there but it just works in the

end as a developer you don't need to

think about it.

>> Yeah. So the idea is whenever you have a

Java library somewhere in the world you

can always use it from cotlin and it was

it was a big selling point uh because

you know if if you start as just a

language in a vacuum and you don't have

any libraries that's not a good start in

this direction definitely uh it was an

absolute requirement for cotlin but also

we had the requirement to go the other

direction in an existing project you

could just

uh rewrite what parts of your code from

Java to Cotlin and everything keeps

working and some libraries actually did

that and many projects started using

Cotlin bit by bit uh you know a lot of

people started with just writing tests

but then you know you you start adding

things uh in cotlin new things for

example and all the Java code around

that has to transparently use uh the

cotlin code so we put a lot of effort

into that and that was fun can you expl

explain to us as as engineers like you

know sounds like it was a freaking big

project

>> what what is the work right cuz from the

outside again I'm just being your

average developer where like all right

I'm invoking okay I I'm invoking a Java

class and things I can think of like

well maybe you know Cotlin or Java

doesn't support things in a certain way

or or maybe but I mean is it really that

hard what is hard tell me tell me I I'm

dying to know

>> so one thing to note here is that We

don't control the Java compiler.

So we somehow need to make it work so

that you in in your Java code you make a

call into something that only exists in

the Cotlin source and the Java compiler

somehow agrees to call it to begin with.

It's not a Java file. It doesn't know it

exists. So the way it actually works is

when we build a mixed project what we do

is we first compile all the cotlin code

and uh that can depend on the java

sources in the in the project. So we

have a java front end baked into the

cotlin compiler so we can resolve

everything in the java code and then we

produce class files so binaries for the

jvm that the java compiler can read. So

when Java compiles it takes Cotlin

sources as binaries and this is how it

works. So you know the we would have to

implement a Java compiler otherwise

fortunately Java has separate

compilation. So this works. So this

trick means that you know whenever you

have in your tooling like in in your ID

for example when you navigate from Java

sources to Cotlin sources has to be a

special trick. So someone needs to go

and teach the Java world to know about

cotlin world. Of course the ID doesn't

do the compilation to navigate. But in

in the compilation time we don't control

the compiler. So we we did our own ID.

So we could do something about the uh

Java tooling. But we couldn't do

anything about the Java compiler. So

that's trick number one. And then you

know when it comes to incremental

compilation it becomes even funnier

because Java incremental compilation is

a complex algorithm on its own. And now

we're incrementally compiling two

languages at once and that's fun. And

you know incremental compilation

algorithms are generally a very messy

very complicated heristic that you have.

So you know there are tons of corner

cases and stuff. So that's that's like

one example but then you know you start

making interesting new things in cotlin.

You need to expose them to Java. You

need to make sure that whatever fancy

thing you have, Java can actually

interoperate with that. And one example

there would be Cotlin. We figured out

how to make Java collections nicer in

Cotlin without rewriting the collections

using the same library. So Java

collections are what's called invariant

because they're all readwrite. So if you

have a list, it always has a set method.

>> Yep. And that's a little bit of a

problem because whenever you have a list

of object you cannot assign a list of

string to that and that's a little

annoying because you know you want to be

able to represent a list of anything and

that you need to play with

question marks wild cards and stuff like

that. It would be very nice if we had a

readonly list interface that doesn't

have a set methods and then there is no

problem in assigning a subclass a list

of subasses to a list of super classes

but this interface doesn't exist at

runtime right we can't just invented or

can we so we we actually can

>> no

>> and so in the cotlin compiler we have

this layer of trickery specifically for

Java collections where cotlin always

sees Java collection s like if they come

from the Java world they are read write

mutable collections we call them but

>> mutable right

>> yeah yeah yeah so so the Java

collections are always mutable or

>> platform mutable I I'll talk about that

later

>> uh but when you do it in cotlin you can

actually distinguish between readonly

mutable collections

>> and it's all very nice on the cotlin

side but then when java sees the cotlin

collections they are normal again like

when we expose them through binaries the

Java world always sees them as normal

collections. They're mutable for Java

and it's it's all right.

>> Okay. I'm I'm starting to see why it's

you said like you need a lot of money

for this because this is just one one of

many things but this itself sounds like

uh I don't know how you solve that.

>> Yeah. So so ju just to add a little bit

of detail to this. So the nice thing

about uh those predom collections is

that you can pass a list of string for a

list of object right wouldn't it be nice

if a cotlin method that takes a list of

list of any uh could accept a list of

string in Java but aren't we erasing all

the cotlin nice stuff we are but we know

that this list is actually what's called

covariant

so we can expose it to Java as a list of

question mark extends and not just list

of object. So you know it becomes

coariant for the Java Java world as well

and that's like one hack that makes it a

little more transparent and there's a

bunch of that. uh so you know so that's

another thing that we had to play with

but the biggest uh thing is of course

nullable types and actually we we handle

nullable types and these things with

collections kind of similarly which

makes the whole in typing layer of the

interop quite interesting

but basically so Java doesn't know

anything about nulls right and uh

>> well it knows about nulls but not not

about nullable types it does not exist

>> 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

Cotlin types can be not null and it's

very convenient. And when you have a

notnull type, you can just call a method

on it normally, right? But if something

is nullable, you can't just dreference

it. You have to first check for null and

then use it, right? Or there is a safe

call operator question mark. Well, just

propagate null if null is on the left

hand side. So we started with saying

okay all Java types are nullable which

is a conservative like very mathematical

way of treating this is correct right

>> yeah you you're not going to be wrong

with that

>> yeah and we we implemented that and we

started using it inside Jet Brains and

the feedback was horrible like your code

is plagued with those null checks and

you know that there shouldn't be there

because you can't express anything on

the Java side the right way and there

were like we had some annotations for

the Java side wasn't it was also brittle

not always worked because you know there

can be long chains and stuff and some

some libraries just don't have the

annotations and we struggled with that

for a long time and basically we

realized that this assumption that

everything in Java has to be treated as

nullable just doesn't work this this was

a turning point where we sat down and re

reimagined the whole thing and we worked

with uh great uh type theory type

practice I would say guy from I think it

was back then he was in in Pernell Ross

state. So Ross helped me figure out the

sort of mathematical side of uh how you

can represent those types that come from

Java and should be like we should be

aware of the that they they are from

Java and can possibly be nullable but we

shouldn't treat them as nullable because

it was very inconvenient and Ross put

together a very nice sort of calculus

about those and when we started

implementing it like all the nice things

are gone.

the the actual yeah the mathematical

beauty is completely gone from from from

all that and I think we took the general

idea of sort of splitting a type in two

and everything else is just very messy

industrial kind of thing that's not

sound but it works well

>> okay and interpretably sounds like it

was a journey but a necessary one how

long did it take and can you give me

just just a sense of of like how many

people working on it how much cuz I

think In traditional project we can get

a sense but I have no idea with a

language how does this work and how long

did you think it would take versus how

much it took.

>> Yeah. So so let's let's start with that.

So every time I was asked when we were

going to release cotton I would say one

year from now.

>> Yep.

>> And you know this is this is not a plan.

I had no idea. Had no idea. I also had

the illusion that the initial version I

was building was a prototype and we

would write everything. And I I'm sure a

lot of people out there have been there.

I think that prototype has been

rewritten more or less completely now,

but it took

six years, something like that. Yeah. So

maybe longer actually.

Uh yeah. So so I had no idea and I

always said like, okay, a year from

now's far enough. We'll probably be done

by then. Uh in practice, we we started

in 2010. Yeah. autumn of 2010 basically.

And we released in 2016, February 2016.

So, you know, it was a long time,

fiveish years.

And that uh you know, and in part it was

just because I didn't know how to manage

projects. And my initial team, the

people who worked full-time on the

project, I I looked up on GitHub to to

to verify that everybody who

almost everybody who joined Jet Brains

to work on Cotlin was a fresh graduate

because I used to teach and I had some

good students and I knew how to work

with students. And so basically

everybody on the team was a student

apart from a few veterans from Jet

Brains who were were helping not all of

them even full-time. So we started

getting experienced engineers on the

team a bit later. And you know to be

fair a lot of those people you know

people who are following Cotlin know

those names. people who are core

contributors who built out like

absolutely foundational parts of cotlin

joined as fresh graduates and they they

became great engineers but I think I've

I overdid it a little bit so it's great

to have you know younger people

have no fear and that's wonderful but

you know the balance was not right

>> and how big was the team initially and

then towards the release

>> so we started we started out basically

with four four people part part-time and

yeah we we went like that for maybe a

year or something so the initial

prototype was built like that and then

people started joining in by the time we

released I think it was around 25 people

or something and the team grew quite a

bit so by the time I left in 2020 it was

about 100 people on the team 70 of them

engineers

so it became a pretty big undertaking

>> can you tell us about the development

process inside a language I I I think a

lot of us are used to building you know

like services backend services or or

products or mobile apps etc. They

typically have a release process. How

does this work inside a language like

what is your release process and what is

the I guess best practices like do you

even do code reviews or or

you know like how can we imagine because

again it feels such a rare project.

There are people building languages but

not many of them.

>> 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, you know, to compile

your code, you need a previous version

of your compiler and you better agree

with your colleagues which version it

is. It can be really tricky, especially

when you do things about the binary

format. And there is like quite a lot of

bootstrapping magic going on. And I

don't think it can reproduce the cotlin

uh builds from scratch because you know

if you just take a snapshot of the

cotlin repo you can only build that with

the cotlin compiler and I don't think we

kept all the bootstrap versions.

Now I it might not be really possible

without a lot of manual intervention to

rebuild all the sources from the very

beginning and reproduce all the versions

because sometimes you know we we had to

like commit a hack into a branch and use

that branch as a bootstrap compiler for

the next build and then throw the branch

away. So that was like a oneoff compiler

used to facilitate some change in in the

binary format or syntax or something. Uh

so that's a separate kind of fun but

generally I mean many many practices are

very similar like had code code reviews

pretty early on. It's my personal quirk

again that I like to talk to people. So

in code reviews I often just sat

together with someone and either they

reviewed my code or I reviewed theirs.

But this is you know I can't argue that

it's much better or or worse. It's just

how I prefer because I like talking to

people. So code reviews. Yes. And of

course we we had an you know an issue

tracker like everybody else. Ours was

always open so everybody can submit bugs

to the cause and bug tracker which was

very helpful. Uh it's hard to manage

because there will be like with usage

there will be a lot of bugs and a lot of

like feature requests and and all all

kinds of stuff but it's worth it. You

you have a communication channel. uh

release cadence is a very difficult

thing to figure out for such projects

because one big consideration you have

for languages is backwards

compatibility. In part, this is what

delayed 1.0

because we wanted to be reasonably sure

we can maintain compatibility as soon as

we call it 1.0. in part because it was

the expectation especially Java is

incredibly stable and very good with

that until Java 9 came about and also

Scala had a lot of trouble because they

were breaking compatibility a lot and

the community was struggling really so

we really didn't want to repeat that but

you know there turns out you can even

break compatibility Python 2 to Python 3

and survive so you know

>> barely barely survive

They're doing very well

>> now. They're doing well. Yes.

>> Yeah. So we we were really serious about

that. Uh but basically what it means is

you start doing interesting things like

deprecation cycles and so we we actually

invented an entire tool set for

compatibility management.

>> So before 1.0 we tried to help people

migrate. So we we had those milestone

builds. Embarrassingly, we had 13 of

those

and uh you know when we broke the

language in major ways we tried to

provide tools for automatic migration.

>> That's nice of you.

>> Which was I don't think it was a

standard practice in industry back then.

Now people are doing it more. So I'm

like very happy to have sort of

popularized this idea. And then when we

were preparing for 1.0,

We did a major review of everything and

took a year to sort of review all the

design and what we're doing is basically

trying to anticipate what changes we

might want to make or what new features

will require and to basically prohibit

things that might block that. So we

tried to make sure that the changes that

we were planning were guarded well by

compiler errors to make sure that users

don't accidentally write anything that

likes that looks like a new feature and

that was fun like we had design meetings

I think every day at some point

basically working on that like okay

let's outlaw this let's prohibit that

and we prohibited a lot of stuff

correctly and some stuff incorrectly uh

but you know generally really worked

out. So, so this compatibility thing was

was a big deal, but there's also a lot

of stuff that we didn't anticipate. So,

we had to figure out ways to manage

this. And there is something in Cotlin

um in the Cotlin compiler called message

from the future.

>> Mhm.

>> 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 in is completely unreadable

for the old compiler. So the version is

higher. I don't read it. That's it. I

bail. But it's a little hard for people

uh then to to manage their versions

because new libraries new versions of

libraries come with the new compiler

expectations and you have to migrate

your entire project to do that. It's a

little annoying. And if what you're

adding is like one method that basically

invalidates the whole library for an old

compiler, that's not great. So what

we're doing, a newer compiler can write

something into the binary that tells the

old compiler, okay, this method is what

you can't understand, but everything

else is fine.

>> Oh, that's smart.

>> Yeah. So we call this a message from the

future and like it can provide some

details. So there's that and there's

also um the discipline of experimental

features which is incredibly helpful and

I am very happy to see other languages

doing it now and even Java does

experimental features now which is

wonderful.

>> Andre just talked about experimental

features in programming languages and

how that used to be rare back in the

2010s. What this reminded me is that

running experiments in production used

to also be rare. Not because teams did

not want to do it, but because doing it

meant building a lot of internal tooling

around it. Assignment, rollouts,

measurements, dashboard, debugging, the

whole thing. For a long time, only a

handful of companies really pulled this

off at scale. Companies like Meta and

Uber, which brings me to Static. Static

is our presenting partner for the

season. Stata gives engineering teams

the tooling for experimentation and

feature flagging that used to require

years of internal work to build. Here's

what it looks in practice. You ship a

change behind a feature gate and roll it

out gradually. Say to 1% or 10% of users

at first. You watch what happens. Not

just did it crash, but what did it do to

the metrics you care about? Conversion,

retention, error rates, latency. If

something looks off, you turn it off

quickly. If it's trending the right way,

you keep rolling it forward. And the key

is that the measurement is part of the

workflow. You're not switching between

three different tools and trying to

match up segments and dashboards after

the fact. Feature flags, experiments,

and analytics are in one place using the

same underlying user assignments and

data. This is why teams and companies

like Notion, Brex, and Atlassian use

StatSik. Static has a generous free tier

to get started and pro pricricing for

Teams starts at $150 per month. To learn

more and get a 30-day enterprise trial,

go to stats.com/pragmatic.

And with this let's get back to Andre

and experimental features in cotlin.

>> So we did quite a lot of work you know

when when you're doing something

experimental this is something that's

supposed to break and you want to

emphasize this to make sure that the

user is aware

that you know this is something we are

not promising to keep compatible. This

is something we're going to break. And

you know we we used to put the word

experimental and package names for

people to understand that this will

going to is going to be renamed and you

know warnings when you use language

features and we require like compiler

keys to enable language features and

stuff like that and kind kind of helps.

So we did quite a lot of that. So, so

all of this is an extra layer. Unlike a

SAS system for example, a compiler

leaves behind not behind but creates a

lot of artifacts that pin down its

history in the wild. There is source out

there and there are binaries out there

and you're guaranteed to encounter them.

Every time anyone hopes that no, this is

an obscure case. Nobody will ever hit

that. With enough users, you hit every

freaking case.

And this is so surprising and I I

discovered this fairly early on. I think

before 1.0 when we had a few thousand

users, I realized that if something's

possible, some person out there will

actually do it.

>> Now you you got 1.0 out. Can you tell me

how Cotlin grew in popularity when you

released it? What was your target

audience? And then how did Android

happen? Okay, so that's that's a

complicated story. Let's let's try to

not get off track because this is like

has a lot of side s side tracks to it.

So when we started Cotlin, we were not

really very aware of Android and I mean

we knew that there was a thing called

Android.

>> Kind of ironic.

>> Yeah.

>> From from now message from the future,

>> right? Yeah. So basically in 2010 we

were focused on the majority of Java

developers that was all about the server

side.

>> Yep. I can clear.

>> Yeah. So the the most money Intelligj

was making was on Spring users and you

know everybody knew that this was what

the Java platform was about by then. So

we were targeting

serverside developers basically and also

desktop developers because Jet Brains uh

had the the probably the last desktop

application written in Java or in at

least in swing. So and that that was the

target. It was initially not even a plan

to do Android

and codlin like got some usage for the

server side um and you know it's still

there and it's growing there not as fast

as on Android but still has some quite

some representation on the server side

but then a few years in

some person on the internet asked us

like whether cotlin works in Android and

I was like I heard Android uses Java the

cotlin should work. We never tried. Go

and try. And I think it was the either

the same user or a different user came

back and said like the tool chain

crashes. And it wasn't even the cousin

to tool chain. It was the Android tool

chain that crashed.

And you know, we looked into it and it

turns out that it's some um some some

tool in the Android tool chain that's

written in C that just fails with the

core dump and it's not very clear what's

going on. And we later figured it out

and it turned out that you know the

Android developers and the people who

built the Android platform, they

actually read the spec of the JVM unlike

the people who implemented the hotspot

VM because the hotspot VM I suspect came

before the spec. So it was the reference

implementation but it was actually

specified after it was built. So the

hotspot VM was super lenient to weird

things like that there would be like if

we put a flag on a class file that was

not allowed for classes hotspot wouldn't

care and would we ran everything on

hotspot and so we we thought everything

was fine but then the Android side those

were the people who actually read the

spec

>> and they actually implemented it. Yeah,

they would complain about everything and

this is why we used Android tool chain

as a testing uh environment basically

because you know this is how we could

get rid of stupid things in in our bite

code and they helped us a lot with

validating everything. But you know

there were some gotchas there and some

some legacy stuff nobody cares about in

the mainstream Java just you know were

faithfully implemented on the Android

Android platform that that was fun. So

you know and at some point pretty early

on I think I had this realization that

Android was a growing platform which to

me then I I don't think I had a much of

of understanding of you know dynamics of

markets then but to me it meant that

there will be a lot of new applications

and it's much easier to start completely

a new with a new language.

So I made sure at some point that we

worked well in Android. It was already

after the lawsuit. So you know the big

context to all this was that when Oracle

acquired Sun Micros they sued Google for

billions of dollars for using Java and I

think that is settled.

>> It it it was settled in some way. Yeah.

And then everyone could go on their own

way,

>> right? But uh it took years and years to

settle. Yeah.

>> So back then it was very much a thing

and you know so that dispute was

somewhere in the background.

>> Uh but yeah so so basically we we saw

that a lot of people on Android really

liked cotlin

>> they they loved it.

>> Yeah as soon as it was stable pretty

much. I mean I think for all the things

that you mentioned right like it was

just so much nicer than Java. Easier to

write easier to read lots of nice

features. So you know you use Android as

as a way to actually you know make sure

that Cotlin compiled correctly and then

why did it take off on Android? Yeah. So

the situation in Android was pretty

interesting because unlike Java uh

server side that you know is kind of

under control of the teams that develop

on it. uh in the case of Android there

are devices in the pockets of people

right and when you have and billions of

those devices and those devices don't

always update the virtual machine so

people in Android were basically stuck

with old Java

and even when Java started progressing

and for example Java 8 came out in 2014

it was very difficult to roll out this

new version of Java across the entire

Android ecosystem because it required

updates to the virtual machine and there

were workarounds and retro lambda really

helped and so on so forth but you know

there was still a lot of people stuck

with really old Java so Java wasn't you

know on par with cotlin or C# uh in 2014

uh but it still was much better like and

solved the major problem uh but it was

not available to the Android people So

there was a lot more frustration

with Java in the Android community and

also there was Swift on iOS.

>> Oh yeah.

>> Where you know it was a real example of

a big ecosystem transitioning from a

really dated language to something

>> really nice.

>> Yep.

>> And I think compounding these two things

were uh like the major factors. And also

I mean we we made sure that cotlin

worked well on Android. Also very

fortunately

at some point Google switched the

developer tooling from the Eclipse

platform to the Intelligj platform when

Intelligj was open sourced back in I

don't remember 2014 2013 I think or

something like that. So, you know, it

was we we had a nice plugin because uh

everything worked on the Intelligj

platform and the same plug-in worked for

Android and many other things like were

just very smooth. Well, very smooth.

There were a lot of bugs but um

reasonably smooth. So it felt like uh a

very good match and a lot of people

appreciated that and we really wanted to

somehow draw the attention of the team

at Google to you know maybe talk about

it or something and it just didn't

happen when so we released in 2016 and

there was you know we we had some

communication with Google in general but

there was no interest in that side

they're like okay we I guess we'll just

keep going as we do and some people were

already building Android applications

And well some people were building

production applications in cotlin before

we released 1.0 and you know uh kudos to

the brave people because they gave us

invaluable feedback but you guys are too

brave. Yeah. So, you know, it just grew

organically and when when we started in

the very beginning. Uh I set this

internal goal to myself uh that if we

get to 100,000 users, it's a success.

Like I've done well enough if it gets to

100,000. And of course, it's hard to

tell how many users a language has, but

you know, you can kind of estimate that.

And I think we were on track to get to a

100 thousand users during

2016 because it it was growing. It was

in the tens of thousands, you know, it

looked good. But then uh some people

from Google reached out and said they

wanted to chat and it turned out they

wanted to chat about announcing official

support for Cotlin at Google IO 2017.

that would be in like 3 months from the

time of that conversation. We were like,

"Yeah, sure. Let's do it. What do we

need to do?" And it turned out we we had

to figure out quite a few things, but we

managed. And I think it was a heroic

effort on the side of the Google team.

They did amazing things, impossible

things there. And uh I have good friends

um among them uh now. And it was like it

was really really close like we we could

have missed the deadline but we figured

it out and yeah on our side also we had

to make many things work and you know

figure out how we now interoperate with

Android Studio better and then you know

how do we set up processes and and

everything but there was like a big

legal thing around it. uh this is when

the column foundation was invented and

we had to design the protocols for

decision-m the cot foundation and uh you