Transcript
Intro
0:00 · I'm going to throw away a large subset of my engineers and I'm going to offload all of that work onto an LLM.
0:08 · What do you think about this shift?
0:10 · The whole LLM industry is propped up on VC money, subsidize usage, addict users, switch to value extraction. Like that is the playbook. Coinbase CEO cut 14% of stuff and referred to AI.
0:25 · Not that bad. After I left cash, they got rid of 70% of engineers.
0:29 · Is Scotland a career advantage?
0:31 · I'm not so sure it's an advantage anymore. I like Rust. I think code with AI agents.
0:40 · Never. What's your plan B if AI writes better code than you in 6 months?
0:45 · Probably we'll just keep Jake Wharton. In 2010, Java was the number one programming language in the world. Android run on Java. Did brains build Scotland to compete with it? Why even try?
Why Kotlin Was Created
1:00 · Cotlin really came in at a time when the Java language it was a little stagnant.
1:06 · Oracle was transitioning into stewardship of the language. The release times were still 2 years in between and um the team at Google was sort of stuck relying on you know what the Java language provided. And so there was this opportunity for someone to come in. And at the time the community was looking at alternative languages. There were people using Scala or people trying to use Groovy. Uh and Colin really came in at a time when there was this thirst for just something that was more modern.
1:39 · As these other languages were evolving outside of the Java ecosystem, you saw a bunch of things that were desirable. And then obviously um you know being a tooling company being able to deliver a new language with the the IDE and all the infrastructure around it um just really made it an easy cell or an easier cell than something that had to you know bootstrap itself from nothing. Uh and also being able to leverage the existing ecosystem.
2:08 · You didn't have to throw away that existing you know Java library or even your entire Java codebase that you already had. you were able to gradually introduce it and migrate, use the libraries you already knew and then over time sort of adopt incrementally.
Who Is Jake Wharton?
2:24 · Jake Wharton, Android developer and author of Retrofit and OKH HTTP, brought Cotlin to Android, quit his big tech job in 2025 during massive tech layoffs publicly against AI.
2:38 · In 2017, Google announced Scotland as one of the official Android languages.
Google's First Kotlin Engineer
2:44 · you became the first engineer on the cotlin team at Google. How did that happen?
2:50 · So at the time I had worked at square for five or six years and we had adopted cotlin about 3 years prior. Uh and I had written a document that basically justified why we should use cotlin at the company in order to get it approved.
3:08 · Uh and I made that doc public because there was you know nothing specific to our use case about it. it was sort of a general argument for the language and that really bolstered a bunch of um interest I would say in the Android community and I I sort of just became uh
3:28 · this person that was really involved in the the ongoings of the language and sort of evangelizing its use and as the interest grew and as the members that were at Google also you know realized that Cotlin was this thing that could be potentially really beneficial.
3:46 · The people that I knew were sort of hinting to me that, you know, this was potentially going to be a thing and would it be something that that I was interested in. And I mean, I can think of no sort of greater recognition of, you know, the idea of introducing Cotlin than going to the company that's, you know, providing the tooling for all of Android and and turning that language into the thing that's, you know, now the first party, you know, official thing.
4:12 · So it was an opportunity that was impossible to pass up.
4:17 · But uh was there any push back from the Android team about adopting Cotlin?
4:23 · There was certainly a hesitancy I would say from the Android team to you know go from something that you've been built on for you know 10ish 12ish years at that time that you sort of really know and have uh integrations with throughout the whole stack to adopting something that's new relatively unproven. Uh I mean it it had only really stabilized maybe a year or two prior.
Pushback Against Kotlin (at Google)
4:47 · Um, so yeah, there there were risks and apprehensions and I think you know as a company as you know Google they're not entirely riskaverse but they wanted to make sure that their bases covered and so like the way that it was introduced was very thoughtful. Um it wasn't a hard switch. It wasn't this is the new thing overnight.
5:07 · It was incrementally adopted. um the the libraries and stuff that they published you know we built sibling libraries for cotlin initially long before rewriting any of the Java based ones in cotlin and um the same with the you know it's almost again a testament to the language how it really honors its Java legacy that the people integrating it into their code bases didn't have to flip overnight where is Scotland used beyond Android
5:36 · the first uh couple years I think because of the the ground swell of support for cotlin in the Android community. There was this false association that this is like uh you know a language just for Android. There there were even articles at the time that it was a language built by Google for Android just you know which is obviously not true.
5:56 · Thankfully in the time since um there's been a lot more adoption for you know where you would see like backend services you know that otherwise would be written in Java now or cotlin you have companies like spring and all of their offerings are now you know much of it is cotlin first other than that yeah I mean jet brains is really pushing on the multiplatform story so you can see it a little bit on iOS and um you know there's applications nowadays that are built for desktop for
6:27 · Cotlin the the Jet Brains toolbox probably being one of the most used the the way that you get your your idees. I feel like um while the Android thing was really early uh it sort of helped seed it in these other you know just a
6:44 · concrete example at you at Square all of our backend services were in Java and when we got Cotlin approved for Android it was it was only for Android. we had this excitement using it and our Java you know companions on the back end would see us being excited about this and and want to start using it and over time yeah it became approved for them and they you know were able to use it as well and I feel like the Android thing has sort of just been a catalyst for some of these other other ecosystems to start start using it now I have a task for you pitch Kotlin
Pitch Kotlin to a Java Dev in 60 Sec
7:17 · to a Java developer in 60 seconds I Colin is really what Java wants to be in maybe 10 years but because they because Java has doesn't have the ability to break existing code uh there takes them a really long time to evolve the language and so all of the things that eventually will likely end up in in Java are are already available today in cotlin and uh you don't have to be using the latest and greatest.
7:48 · So, you know, as much as we like people on the newest versions of the JVM, um there's certainly code bases out there that are still Java 8 and Java 11, and Colin honors that. Uh it gives you all these modern features while still targeting, you know, potentially older older versions of the JVM.
8:06 · What are the biggest companies using in production right now?
Who Uses Kotlin in Production in 2026?
8:10 · Facebook, Google, Amazon. um the certainly on the mobile side first, but definitely now on the the backend services and stuff they're building. You see them working on a lot of tooling, you know, uh just this week as we're recording this, Facebook is contributing their Cotlin formatter to the Cotlin Foundation to eventually be the first party cotlin formatter.
8:32 · So yeah, I mean those are the biggest code bases in the world probably and uh you know the fact that you can transition them from another language to to have in cotlin is uh yeah it's you know it's really a testament to the to the language and their investment in it long term. Google the dream job for many engineers and one of the biggest adopters of what you left after two years and nine months. Why?
Why Jake Left Google
9:02 · I was at Cash App at the time. We we we did this whole thing with Cotlin where we we got it adopted. We wrote a bunch of open source libraries in Cotlin and you know the the Google adopting Cotlin for Android happened and it was it was too good of an opportunity to pass up to to go to Google to do that.
9:19 · But when I left I I basically said that I'm going to be out of the office for about 2 years because I planned to go to do this thing make make Cotlin you know the first first party language on Android and then as much as I like working on
9:38 · tools and libraries I don't only want to work on tools and like I want to use the things that I build and so the idea was to go you know do as much as I can in two years get get the language to be successful get it to be the first party thing so that you know I know I can rely on it in the future and then flip back and use use the things that you know that I built at Google. And so yeah, when two years came around, I was planning on leaving and switching back.
10:05 · And um right at the very end when I was going to actually put in my my notice to leave, I they approved another project that I really wanted to do. And so I stayed I stayed an extra 9 months and and worked on that. And but yeah, ultimately I just um I want to build things with the tools and libraries, [snorts] not just build tools and libraries. So I had I had to go back to working on something where I got to, you know, reap the benefits of of that investment. So yeah, there's there's a lot to like about working at Google.
10:33 · There's also things to dislike. Um, but I feel like I accomplished my goal and then yeah, had to had to go back and and use the thing that I built.
What Jake Dislikes About Google
10:42 · Sorry, but things to dislike. What do you mean?
10:45 · You know, it's a very big company. Um, Android is thankfully relatively isolated from, you know, the the products of Google. And so I feel like um and I worked with really great people there. That that stuff was all great.
10:58 · Um, I have lots of issues with Google as a company, the way that they can lock you into their products and services and but yeah, um, I mean the Android team is fantastic. I I do miss working on that stuff. After 5 years at Kashop, November 2025, in the middle of massive layoffs, crisis of tech industry, you left. How hard was it to find a new job?
Quitting Cash App: Today's Job Market
11:24 · So, it wasn't the easiest thing. There certainly are jobs out there. I was a little picky. I would say I had some requirements of, you know, the place that I wanted to end up. I was fortunate enough to leave voluntarily, you know, on my own terms. And so there wasn't an intense urgency. Uh I wasn't I wasn't immediately desperate.
11:49 · There definitely are jobs out there still, but um yeah, it's not uh it's certainly not like it was five years ago when, you know, anyone walking off the street could get snatched up and make a ridiculous amount of money as a as an Android developer. So, um it required a little more effort on my part and I absolutely sympathize with the people who were, you know, forced into this situation of having to look for a new job. But I mean I don't think like the the bottom has completely fallen out.
12:20 · So there the jobs are still there and you know it takes a little more time and you have to find ways to differentiate yourself but um yeah they're they're there.
12:29 · What's the realistic salary range for a senior cotland engineer in the US right now?
200K Salary
12:35 · Generally what I see is um you know a 200,000 sort of and up range. Uh and then that's usually offset with some amount of equity. Um maybe a h 100,000 a year in equity. Uh you know spread over four years with the whole vesting thing. Um there's definitely a lot under that.
12:59 · Um, I think also because just in general companies are a little more mindful about, you know, where where their money is going and uh they're not paying exorbitant rates anymore. Or otherwise, if you really want those numbers to be higher, you have to go to something that's a little more, you know, lucrative where where the potential is very high, but the risk is also very high.
Who Pays More?
13:25 · So, you know, obviously right now we're in a particular time when there's a very specific technology that has everyone's focus and you can find those kind of jobs that will probably pay you much more than that. Um, probably, you know, in cash and in equity. Um, but that equity could go to zero. Um, or it could, you know, 10 it could 10x.
13:48 · Uh so yeah it becomes uh it really becomes an individual choice about what where you are in your life. You know what's the level of risk that you can tolerate. So uh I I'm at the point in my life where I don't want to make those bets. I'd rather just have the the consistent you know steady cashbased salary. And it was the complete opposite when I was younger. I was perfectly happy to take you know take that risk.
14:18 · Uh, and you win some, you lose some. Um, but then yeah, you know, as you as your life circumstances change, I guess it's really what what you value as the thing that's that's more important for you.
Is Kotlin a Career Advantage in 2026?
14:30 · In 2026, is Scotland a career advantage for software engineers?
14:36 · I'm not so sure it's an advantage anymore. um which is almost you know the success of the language reflecting on it's sort of like just an expectation at this point it's it's not a differentiator uh it's not a thing that is is is rare
14:54 · or all that hard to find uh and that really is because Google adopted it and made it the first party language and so it's the thing that the thing that you learn if you're going into Android uh you you just learn cotlin and then it's it's a thing you're expected to already have as you know someone that's coming into that that market because that's now what what everyone is doing in the same way that you know compose UI is the thing that maybe four years ago was a little more rare and nowadays is sort of it's just the default requirement so
15:26 · yeah I unless you're using a little more of the language so like the multiplatform features or something that that then becomes an advantage a differentiator uh thing that might set you apart from you know all the other Cotlin developers that are that are out there but um I don't think it's that big of a it's it's more like a
15:49 · a ubiquity you know thing at this point it's it's everywhere when you were looking for a job you published nine values for your future employer I'll read them and you tell me what they mean and why they are important to you know AI no AI companies AI based products or forced AI usage for development.
Why Jake Refuses to Use AI
16:13 · Yeah.
16:13 · Uh it's first for a reason. It was probably the thing that I was looking for most. We're in this time where [sighs] things are changing rapidly.
16:27 · um both from a development perspective, but then also the way that these companies are just really forcing AI, you know, LLMs basically, uh into places where they otherwise probably shouldn't exist. Um, you know, I don't think anyone really feels like software quality is going up uh over the last couple years and I don't feel like this is a tool that's going to contribute to software quality over time.
17:00 · Um it sort of looks that way to certain executives, you know, higher ups in these companies where they think this will be a thing that allows our engineers to work faster, produce higher quality code, etc. Um I think it's actually the opposite. And so then there's this whole other thing about the the ethics behind the tools. Um they're basically built on the largest copyright infringement in history.
17:31 · Um you can pretty much draw a straight line from Aaron Schwarz who ex you know downloaded all this scientific data like 30 gigs of scientific data um and was facing decades of jail time for this uh 2013 or something. and I can't remember exactly when it was and he ultimately took his own life from that copyright infringement, you know, claim that they were bringing against him.
18:00 · And you fast forward to now the way that these models are being trained is they're essentially ignoring artist copyright. They're ignoring the licenses of code that exists. Just because you can get access to something doesn't mean you have the rights to be able to, you know, remix it and reimagine and in some cases, you know, spit back out verbatim these things that you've ingested.
18:21 · And you try and take, you know, we've seen like the news that Facebook was using like Bit Torrent to download millions of books and, you know, terabytes of of data. Uh and you know in 15 years we've gone from from that from the Aaron Schwarz incident to to these companies who ethics just seem to not even be remotely in the the realm of what they consider as something that you know is valuable to them.
18:51 · And so I don't want to be associated with with those things. And it's hard like it's becoming harder and harder to find ways to avoid that. And [snorts] so yeah, that was first for a reason and it immediately rejected a lot of uh a lot of places and it's also a direct reflection of where I left Square
19:14 · and Cash App where [snorts] in the weirdest way, you know, you think of like um the tools that we use day-to-day uh it's often like another engineer is excited about, you know, this new language cotlin or this new IDE Intelligj or this new build system and it's this very engineer-led thing where
19:37 · you just get excited about something and it becomes infectious and then you go and you like beg your you know your engineering leaders to allow you to use cotlin or to switch to you know buy your Intelligj license or whatever. Why is this technology being done the opposite way? Why why should the CEO of a company be telling you how to do your day-to-day job and saying use this tool, right?
20:03 · like they don't come to you and say you should use a statically typed language because that allows us to model our business requirements in a way that the compiler can check. No, like you choose that uh that it's an engine that's an engineering decision. Why do you model null in the optionality in the language?
20:23 · Why do you you know all these things we as engineers lead that because we know what the business requirements are going to be then we choose tools that allow us to effectively produce the thing that the business wants. If Jack Dorsey came to me and said you have to use Eclipse I probably also would have quit.
20:44 · Uh but yeah, when you're when the leadership of your company is forcing these tools upon you like and also of you know that in and of itself by by itself would be would be one thing but then when you couple that with recurring layoffs um it just doesn't look it doesn't look good.
21:06 · And so yeah, it's a thing that you know I can make a personal choice and say that I'm I'm not going to use these things. And in general, a a company that's going to be building those things, I think they're doing it as, you know, it's a it's a land grab, a cash grab. Like they're striking while the iron's hot. And like I can respect that as an approach. You you go where the money is. You go where the users are.
21:29 · And right now that that's where it is.
21:33 · And this goes back to the salary thing where I'm in a fortuitous position. I have, you know, worked hard for a long period of time and I've earned the ability to choose where I want to go. A lot of people don't have that. And so, yeah, it's, you know, that list is is me. And AI was at the top because that's the thing that right now I value the most. And it immediately disqualified 80% of the potential places I probably could have gone.
22:01 · But yeah, I'm in the position thankfully that I can basically apply my values that that most important thing to that selection. Uh and yeah, it's it's harder and harder, but that's the one that I feel like um you know, draw drew the most attention. Uh it's immediately it's the most relevant thing in our in our industry right now. So yeah, that's why it's number one, too.
Crypto Is "Basically a Ponzi Scheme”
22:30 · No, crypto. Cryptography is good, but cryptocurrencies are bad. As we go on this list, you can really draw parallels to where I came from. Uh, so before LLMs, it was cryptocurrencies.
22:44 · Uh, and at Square and at Cash, we, you know, again, we leaned very heavily into that. And it just, it's basically a Ponzi scheme, right? There's no real value. And I am it's almost the opposite of what you would expect from a lot of my other values about like ownership and not allowing other people to control you know the things that you earn like which I am totally on board with that. It's just the execution that's wrong.
23:14 · Um and it's a it has essentially turned into a predatory you know system where the only people making money are either the people who are suffering in others or the building businesses on top of it and then you know essentially extracting value from from their customers.
Remote Work
23:37 · Remote work. I work remotely but happy to visit offices a couple of times each year. I've been remote since 2015. Uh, and it's one of those things where it's hard to go back.
23:54 · Um, I really like hanging out in person where we're recording this while there's a a conference going on where I get to see, you know, 50 people that I know and usually see maybe once or twice a year at best, if not multiple years in between. And so I still value the in person, the human interaction and building that, you know, empathy with people, but I don't want to sit in a car every day anymore.
24:24 · Uh the flexibility now that I have children, the flexibility to just come and go as you please and be able to adapt to your work to to, you know, what's going on in everyone else's lives. It's it's just it's so nice and I can't go back.
“Every Company Is Built on Someone Else's Work”
24:37 · Open source. you use open-source software and you publish your own open source projects or want to start.
24:46 · I never really knew anything but open source because when I was trying to become a better developer, I turned to open source uh and to learn new technologies and all that. And so the default for me is if I'm trying something, I'm building something, I put it in the open. And then we had a lot of success ultimately when I ended up at Square. We had a lot of success pushing things into the open.
25:12 · I think uh almost every company is built on a foundation of work that other people do and if you can if you open source things or you contribute in open source to to even if it's stuff that you know you didn't build that's the reciprocity. You're you're paying that forward.
25:34 · you're you're lifting up, you know, the next business or whatever that is going to start based on the thing that you helped build the same way that you, you know, got started on reusing Linux or Android or SQLite or the JVM or, you know, all of these things that you don't have to build yourself.
Customers Over Shareholders
25:54 · Customers over shareholders. Your product focuses on providing value to customers, not enriching shareholders.
26:02 · There's very few products that I feel like are every time there's an update I get excited. It's more I feel dread because it's what did they break? You know, what did they change? What has moved behind the payw wall? Um it it's the you know the term which was the word of the year a couple years ago, the initification of of these products where there's not unlimited money.
Ensh*ttification of Software
26:26 · A lot of these places are, you know, they're venture capital funded and that's great at the beginning and you get as a user of the products that come out of a lot of those companies, you can get a lot of value. Um, but then you know there's this inevitable switch where these companies that don't have the sustainable model from the the get-go where they have to essentially remake themselves into something that's sustainable.
26:56 · Uh, it just ends up it it ends up being bad for the user. I want to try and choose a place that basically already has a sustainable mechanism where they're not going to be, you know, looking to extract value from their users in order to either pay back, you know, venture capital money or even just look at the interests of Wall Street investors over the actual users of the product. people over profits.
The Gig Economy Trap
27:28 · No geek workers or exploitative practices to squeeze every cent from customers. Not that dissimilar from the previous one, but uh you know these there's a subset of these companies that come in and they undercut some market basically through VC funding. uh the the the Ubers of the world, the Airbnbs, you know, the the Ubers were cheaper than taxis for the first couple years because some venture capitalist is covering the other half of your ride.
27:59 · And then when that money goes away and they have to turn, now you take an Uber, it's the same, if not more expensive than a taxi.
28:09 · And you know, you can say what you want about unions. There's some good unions and there's some bad unions, but like taxi cab companies were regulated and the workers all you know had to essentially uh meet certain requirements. Uh as opposed to the now the you know gig worker economy where somebody thinks
28:31 · these companies essentially make you think that you can earn well I can earn a little extra money by you know delivering food on the side. uh and you don't take into account like the depreciation of your car, the you know gas mileage and uh you you just end up basically losing a bunch of rights as that individual as opposed to if you just you know went all in on becoming a taxi driver. Um you know there's systems in place to protect that industry that don't exist in these gig worker economies.
29:02 · So yeah, that's a whole subset of companies that I don't want to be involved in.
Why Big Companies Kill the Fun
29:09 · Small and focused. Doing one thing well is better than trying to be everything to everyone.
29:16 · So this it's really the you know the best days, my best days I think at the first time at Square and when we were building cash was when it was when it was small. Uh you knew everyone, you could execute on a vision rapidly.
29:32 · you were almost uh a little naive I guess in in what you could build as opposed to you know when I left uh Cash App or you know Square the the company was I think 12,000 people which is different than you I joined at 200 who knows what the number of employees at Google is right that's an order of magnitude even larger and so you get
29:59 · into these habits of like bureaucracy and the product slows down and you're you start getting a little desperate to find new things that can bring in uh new users
30:15 · and yeah it's you know when you're small I think there's a a little bit of a purity in that and you can really focus on finding some segment of something that you can just execute on really well and Uh, I also think it's I I'm a kind of person that likes to work on a lot of different things. When these companies get larger and larger, your responsibilities as an engineer tend to narrow.
30:40 · You know, you're there's I just remember hearing uh they're like someone who worked at Twitter, you know, 5 years ago was responsible for like the DM like interface, like just the the and at the time this was before they even had a bunch of like chat features in DM. It's like literally just the DMs of Twitter is all they worked on. And that's just like it's so narrow that you lose the flexibility to like enjoy the different things about the product.
31:08 · And I I just want to be able to have the flexibility to bounce around within a product and work on a bunch of different things. Um and that also provides a lot of opportunity for for learning. Um when when a thing's smaller and you have more responsibilities, you get pushed out of your comfort zone. You have to learn how to do a bunch of things because there aren't teams of 50 people, you know, managing something else that you can just throw a requirement over the wall and wait two months and have something delivered for you. You have to go get your hands dirty a little bit more.
Same Job, Half the Pay: The Geography Problem
31:40 · Diversity, equity, and inclusion.
31:43 · Distributing opportunity equally takes active work.
31:47 · You know, depending on where you live, depending on where you were born, uh previous jobs you had, right? There's all kinds of things in your life that put you at certain advantages and disadvantages and it's not even the things that like you know you could very simply think of like gender or skin color or whatever but
32:06 · you know again going back to my past experiences at cash like when I found out that um like that we talked about the salaries the salaries of my co-workers working in in different countries they're doing the same job as I am and getting paid you know market rate which is which is maybe half of what I was getting paid in the US that doesn't make sense to me uh and
32:32 · that's basically you know they just happen to live in that geographical region and so you see people moving you know to the US for the sole purpose of wanting a higher number on their paycheck but otherwise doing the exact same job that's like an an example that's not gender skin color or whatever you know where your geographic region can put you at a disadvantage uh where you you make less and might not you know potentially make enough to sustain you know the the lifestyle that you you know want to live.
33:04 · Um but yeah of course the obvious things as well like you know discriminating against people because of things they can't control is just it's a ridiculous concept. It's hard to believe that I have to write it actually as a value because a lot of these things I feel like I shouldn't have to write.
33:23 · They should just be, you know, the values like the these people that are against it need to have watched like more Star Trek or something as a kid where you know it's totally normal for people to look completely different or you know Alien whatever like uh or have women have equal roles as men. This like you know this shouldn't be a thing that we should have to even touch on anymore.
33:45 · and you know because of the larger political climate uh a lot of there's been just a lot of push against this uh and so yeah I feel it's important to call out that I think that's and this is still a very important thing to me work life balance I don't have work chat or code review on my phone first five or six years you know at square I had Slack on my phone GitHub on my phone I I felt totally fine hopping on reviewing a PR on Saturday night.
“No Work Apps on My Phone”
34:19 · While that's fine for me, um the thing I came to realize is uh you have somebody that's, you know, an intern or a junior or whatever coming in and they see you do that and they don't know why. They don't know that like even though I was in the office on Thursday, I didn't do any work on Thursday cuz I wasn't feeling it or I had to go to the doctor or, you know, whatever. And so what I'm doing is I'm balancing my books.
34:47 · I'm I'm working late one night to to, you know, make up for not working on Thursday. Uh or when I'm in the zone, I worked, you know, 12 hours straight and then I, you know, don't come in till I don't turn on my computer till 1 the next day. I do that to to even that out.
35:03 · But the if somebody that doesn't know that I'm doing that sees what I'm doing and they they see, oh, Jake's working till 8:00 p.m., you know, he's reviewing my PR at 11:00 p.m. on a Sunday. Then they might think, and it's it would be a totally reasonable thought that that's an expectation that the company has is
35:24 · that I should also have chat on my phone. you know, somebody asks a question that you can answer in 10 seconds, a work question on a weekend, like yeah, you know, that's not that big a deal, but you're starting to set a precedent, especially with the remote work and the fact that the apps on our phone are now so powerful. It's very easy to always be connected, but I think there's a ton of value in disconnecting.
35:48 · And I want to instill that in others. I want to show that like it's okay to not, you know, check your work email. You can close that at 5:00 p.m. on a Friday and not open it until 9:00 a.m. or whatever Monday. And that should be the norm, not this, you know, weird thing that you're doing.
36:08 · Which values cost you the most offers?
The Value That Eliminated 95% of Companies
36:11 · No AI, 80%, then then what? I would say the one that really restricted options was a around the VC funding and like how you know trying to find a place that's profitable, has a healthy business model, uh, you know, has a some sort of way of making money.
36:33 · Um, they're not tied to like some external system that they don't control. you know, they're not built on somebody else's technology that can price fluctuations or whole geopolitical stuff can happen where suddenly like, you know, they're unsustainable. That just categorically eliminated like uh I would say 95% of potential companies because that that's the model.
36:58 · And you can do like healthy VC funded places, but I would say they're more the exception um than than the norm. Uh and then it stands in direct conflict with the places that are that are small and healthily VC funded are they're also probably not like building things that I'm interested in as well. So, um yeah, that I would say that narrowed the field like 90 95%. Uh and it yeah, it's a hard one.
37:25 · It was a hard one to to stand by, especially since that usually means higher salary as well. And so, you know, I had to be comfortable with taking a pay cut if that was going to be a thing that, you know, was a value of mine.
Which Company Did Jake Join?
37:41 · In February 2026, after 3 months of job search, you joined Skylight. Why this company? they echo a lot of the values uh that that we covered and they had this bonus this you know cherry on top
37:59 · which was it was a product that I'm like the customer for I had the product uh I had the use case I have you know the family this is a product for families I've been really wanting to do hardware tinkering uh they're they're a hardware product um I really like that they're not in the Play Store. I don't have to deal with, you know, the the whole Google thing. It's where, you know, we distribute our own app and it's there's a bunch of stuff that is Android adjacent that I've never done before.
38:29 · I have not really other than when I was at Google and like you would build the Android operating system and build, you know, your own emulators as you're working on the framework. Um, I've never really worked with AOSP. you've never really worked with an actual hardware device and what you know what the requirements are there. The fact that you're an app that's not in the Play Store means you've sort of free reign of the operating system to make it, you know, do whatever you want. And so it, you know, they met a bunch of the values that we covered.
39:01 · Um they're they very, you know, they're funded, they have a a revenue stream. Um they're just all around really great people. Um I knew so Kevin Barry who um was the author of of Nova Launcher um he also joined about six months before me.
39:18 · So I I um I thought that was a big vote of confidence in the company that he would he would choose it and uh yeah it's just uh it was almost like and unfortunately for every other company it was the very first company that I had talked to and
39:36 · so it became the bar by which every other company was measured and you know it's it was it became very easy to make that choice because the more and more I looked around there were other great places but none of them just had that it's like the whole package of what I was looking for.
Did Jake Compromise His Values?
39:54 · Did you have to compromise any of your nine values to join Skylight?
39:59 · I don't think I don't think so. Yeah, the one of the things was like they did they haven't done any real open source.
40:05 · Um, but they were open to it and they certainly were, you know, open to the fact that, you know, I am a maintainer of a bunch of of open source projects still and so that's sort of like still part of my responsibility and and many of those are even still used in the product um, as well. And they have LM stuff uh, but it's not the whole product is not built around it. It's it's tastefully added. It's entirely optional. um you don't have to be using it.
40:35 · It's used effectively I think um it's not you know the whole the whole product hasn't pivoted to become you know a chatbot or something. um they they we I shouldn't say they we are hopefully you know using it tastefully and um they demonstrated that and hopefully now that I'm there I can also continue to you know instill these values I think as a positive thing for the company and uh so yeah it not not really it it was really a slam dunk.
41:09 · What are you actually building there?
Building a "Family Operating System"
41:12 · So it's a it's a product focused for families. It's a they're a wall-mounted or a um countertop essentially tablet um Android you know big tablet that runs a application that's centered around managing families or households really you know the structure of the family is is irrelevant but it's about getting things out of your brain um mostly focused on parents so you know keeping track of what kid has soccer or you know some recital or
41:44 · what you need to buy at the store this week or what meals are we going to have this week? Who's going to be home when when can I expect uh you know certain chores to be done for the kids? Keeping them accountable uh trying to teach them you know healthy habits and stuff. So they the the like catchy phrase that they like to use is it's a family operating system.
42:04 · But um yeah, the whole thing is like cognitively unbburdening yourself as the the head of the family and being able to put all that stuff into the device so it can manage it for you and you can, you know, just focus on being a good family member. Let's go back to AI.
Layoff "They Got Rid of 70% of Engineers"
42:22 · In May 2026, Coinbase CEO Brian Armstrong cut uh 14% of stuff and referred to AI. his quote, "Non-technical teams are now shipping production code." What do you think about this shift?
42:41 · Uh, I mean, [sighs] not exactly a company that I hold in high regard. Uh, they pretty much fail every one of my values. Uh, he's also not a great figure. I think he's one of the ones where there's no politics at the workplace, which is of course a very political thing to say. and then he is free to make political statements on Twitter as much as he wants. It seems shortsighted.
43:08 · Uh so again to echo a thing we talked about earlier, the whole LLM industry is propped up on VC money. Uh just this week as we record, there's a thing going around about GitHub copilot transitioning to usage space. I don't know what it's just like a month.
VC Money Behind the LLM Industry
43:26 · it was monthly based, you know, like $30 or something a month, and they're transitioning to to usage because the money that's propping it up in order to do the land grab to to get the market share is going away. And so it went from this person's GitHub went from GitHub Copilot went from $30 to like 1,400 or something, you know, two orders of magnitude in in growth. And that is not going to be unique. That's going to be the pattern. Now you're going to see these companies that are essentially hooked on AI.
43:57 · They've been addicted to it. They're unable to operate in ways without using these LLM products. Have their costs go up. I mean maybe by an order of magnitude but two orders of magnitude will be like game over for uh a lot of a lot of these ideas where you can replace the engineers with the LLM.
44:23 · Uh I do see a lot of talk where like uh as these costs rise it ends up costing just just looking at pure salary it's it ends up costing more than the engineer that you thought you were replacing. And so you know I don't have a huge problem with the concept of like lowering barriers to entry for people you know wanting to contribute to code bases and stuff like I I am totally on board with that. one of the best designers I ever worked with
44:55 · took a weekend, he learned how to do Android and he wrote this like insanely complex animation in the Android codebase and just sent a pull request for it. Um, which is like stellar. Um, and so yeah, getting people who aren't dedicated engineers able to contribute in ways that are more tangible, um, like actually affecting, you know, the things that are being built in some way. I'm totally on board with that. I think there's a responsible way to do it and there's an irresponsible way.
Throw Away Engineers, Offload to an LLM
45:25 · And the irresponsible way is to just say, I'm going to throw away a large subset of my engineers and I'm going to offload all of that work onto an LLM. Uh 14% is not that not that bad. At after I left cash, they got rid of 70% of engineers.
45:47 · Um, and they think that they can offset that with, you know, being more lean, which you can definitely just be more lean, but then also with putting it all through LLMs and having them do, you know, having each engineer do the work of four people and having the product
46:06 · people, you know, be able to through the chat system be able to, you know, craft pull requests and not actually have that full understanding of what it is. the output is I think it will work for a very short period of time and I think it will ultimately lead to a long-term decline in software quality.
46:27 · Whether that happens before or after costs increase by an order of magnitude or two um I don't know but both of them I think are inevitable. Uh I don't think the cost one is a matter of opinion. That's just how that works. like they're not
46:46 · that whole industry is just doing the same thing that all of these other companies that use VC money to subsidize usage to you know addict users to get that and then switch to value extraction like that is the playbook and so that will happen and something like that is relatively shortsighted I think because it's just going to end up turning around and biting them. Have you tried writing code with AI agents?
Have You Coded With AI Agents? "Never”
47:17 · Never. I choose to take an extremist stance because I want to make sure that people are thinking about the thing that's behind, you know, what they're working with. If you there's so many so many problems, too, like you're basically like tech workers in general. Um, you know, we rarely unionize because the money was there, the money was good, everything was great.
47:45 · You know, why would we need why would we need to have, you know, this this extra power? Uh, and now that that's drying up, you know, you see you see these layoffs, you see these people just being thrown away. We're in Germany right now.
47:59 · Germany has excellent worker protections. In the US, you just your you probably get your account turned off before you even find out. your just mail stops refreshing or something. Um, I feel like by relying on these systems, you're essentially transferring power away from yourself. You're turning yourself into a replaceable cog that the these companies can then throw away and pull in the cheaper version of you so that they can save save money. I also think you're really putting yourself at risk.
48:32 · Um, I think there's sort of two axes. There's like the ethical axes of using LLMs. Um, but I also think there's like a responsibility axis. There's like a responsible way to use it and there's an irresponsible way.
48:46 · The responsible way is you use it as a a tailwind. You use it to augment your existing capabilities as an engineer. Uh, use it to, you know, allow to express yourself at your capability more quickly or, you know, whatever. And then the irresponsible way is to use it to write code beyond your capability. Whereas if the LLM wasn't there, you wouldn't have been able to pull off the thing that you did. And that's a risky thing to do considering the whole pricing thing.
49:17 · If you can't afford the if the LM price goes up by let's say 20x and you can only afford you know 4% of the tokens that you previously were using in the past.
49:33 · Do you then become like a basically uncapable to, you know, do work dayto-day because you become so reliant on the tool or do you just go back to doing it the oldfashioned way or use it, you know, in fewer places to to do the tasks that are mundane or repetitive or widespread or, you know, the the effective usage of it. And so that's the thing, you know, I feel like I can take the extremist stance for now. I don't know how long it'll last.
50:05 · Hopefully I last past when the bubble bursts and then, you know, we sort of have a collective reset. It's never going to go away, I don't think. Um, but yeah, it's uh I just want people to think a little bit before they use it too much. uh and don't become so reliant on it that you know it's it becomes the foundation on which your entire you know ability to engineer code is built.
50:35 · Have it just be a tool in the toolbox like you know the myriad of others we have.
50:42 · What's your plan B if uh AI writes better code than you in 6 months?
Jake's Plan B If AI Wins
50:49 · I probably will just keep working at smaller and smaller companies and making less and less money uh while retaining my happiness. Um because I'm not at the beginning of my career.
51:05 · I'm not I'm not fighting, you know, to to level up. I am very fortunate in the choices that I made. Um and it has given me a lot of opportunity to and has put me in this position where I have the ability to to take this hardline stance. Uh a lot of people aren't in that.
51:25 · Ultimately though, I have a hard time believing that that will be the case. Um I mean the there's constantly studies being going on about um you know how like how the LLMs basically are going to grow over time right so they're based on what is essentially the collective work of humanity let's say from prior to 2022
51:52 · um there's a study from oh I probably should have looked this up before but I want to say Harvard but um it's basically a uh it's certainty that when models are fed the data that they output back into themselves for training, um it's a certainty that that that will cause collapse. The model will will collapse and it'll be unsustainable. And so it's an impossib it's either we just say that we're never going to get better as developers.
52:21 · This is the level of quality that software will always be at and the code that comes out of LMS will just be what we accept. or someone has to like build new things by themselves. Um, LLM are also not thinking. They're not intelligent. They can't they can't reason. They don't know why they make the choices that they do.
52:45 · It's uh it's all bottoms out in, you know, statistics essentially. I don't think I'm worried about it. It it's already at a scary good place. Um, but it's also it's like deterministically indeterminate where like um it's always going to write bugs because statistically, you know, since it's a statistics-based solution, then the things that it output will not 100% be perfect every single time.
53:13 · I mean, we've all copied code from Stack Overflow uh that has contained bugs. Some of the most upvoted answers on Stack Overflow have very subtle bugs in them. uh and yeah you the code you get out ultimately still is going to need you know debugged and yeah I don't
53:30 · believe that it will ever be the case where there's not a place that will have someone that just programs cotlin originated as a Java boilerplate killer and we know that AI is good at writing boiler plate humans don't need to suffer anymore so hasn't AI killed
Has AI Killed Kotlin's Advantage?
53:50 · Cotlin's main advantage over Java Brian Gats, who's the um I think he's now the lead language designer of Java, basically reiterates this over and over that code is read 10 times more than it's written. Um I don't really think that the like act of writing the code is was was ever really the hardest part. Um you have the part before that which is the thinking, you know, the deciding what's the right way to solve this problem.
54:21 · Where do we draw boundaries in things? How do we model this complex uh you know this complex thing that's part of our our business? Uh and then there's the part after there's maintaining that code over time, right? Bugs will be found. requirements change over time because either from an externality, you know, humanity evolves, politics, things change.
54:46 · You have to go in and update your code to reflect that or you know, you just your business changes and you they focus on different aspects of the product. They build new products uh and that code lives for a long period of time and gets changed. I don't think the the initial thing of like writing the boilerplate um is not the thing that's interesting to me. uh because
55:13 · we do I mean even early on in cotlin we like really latched on to that as you it's fewer characters to type you know we don't have to write getters and setters and and fields you just write the property you get the trailing lambda syntax you make these nice DSLs and I think all that is a vehicle into the language um because it's it's you know it's an easy thing to throw up on a slide or on a web page but ultimately the the languages and the libraries I think lives or die as to how they
55:45 · how they allow your codebase to be effective over a long a long period of time and that's not just writing the boilerplate that's that's maintaining things over time which means you need to have really good tooling uh you need to have things things like strong type system and stuff only only aid that over time and I don't think the boilerplate thing is so much the problem um it can be a great way to like overcome the the like writer's block, you know, moment or
56:13 · um certainly there's no shortage of um like relatively mundane or arduous tasks that we have to do. go update these thousand call sites to you know point to the new thing that offloading that I think is is can be great but that's not really where the problems over time I think lie and where the uh the language itself actually shines.
56:40 · It's not so much the boilerplate thing, but but um yeah, type system tooling and all that stuff around it. Um because yeah, it enables the codebase to to evolve and grow.
Is the Golden Age of Kotlin Over?
56:53 · Java now has records, sealed classes. It seems that the gap between Java and Cotlin is shrinking. Is the golden age of Cotlin over?
57:02 · To their credit, you know, Java hasn't sat on their laurels. They haven't they haven't admitted defeat or anything. And I think since some of the changes that they've made, moving to a six-month release window and focusing on having new language features be experimental and be able to be tested by the community and um certainly all the infrastructure work that they've done behind the scenes to allow them to revise the language more easily.
57:26 · I actually think that a lot of the language features that they have introduced are somewhat more thoughtfully done than Cotlin where Cotlin had to sort of shim it into you know ultimately if we're just focusing on the JVM Java byte code is what it compiles to and so when Cotlin you know
57:49 · really hit the scene Java 1.6 6 was the version of bite code that it compiled to and so the language features that Cotlin implemented had to be turned into compatible Java 16 bite code. The Java language doesn't have that problem. They can introduce things like records and introduce new bite codes. They can modify the virtual machine to suit you know the language's needs.
58:11 · All all of those things evolve in tandem and they can build this really cohesive execution of something like records. in contrast to data classes that have you know the only thing that they can do is emit regular Java classes with regular methods and maybe a little bit of metadata. Yeah, one of the things that I really hope to see from Cotlin moving forward and over time in order to to stay relevant is to look at those features and you know find ways to integrate them.
58:43 · What does Scotland do better than Java today? I would say it's really hard to beat the nullability story. I mean, not modeling null in your type system. You know, people just that the billiond dollar sort of mistake is like the null null pointer exception, but it it actually is not the fact that their nulls exist because, you know, you always need the concept of absence. it's that you're not modeling it properly in the type system so that you're forced to
Swift vs Kotlin
59:15 · reconcile with the fact that something may be optional when everything's optional and then you have the opportunity to ignore it and then get those failures at runtime. Cotlin modeling null and elevating null into the type system or or the concept of absence.
59:31 · It just eliminates an entire class of bugs from your program. To have a category of bugs completely eliminated from what is otherwise, you know, a relatively simple change as a programmer to just putting that question mark at the end of your type when something's optional. Uh it's just still one of those it's just such a powerful concept.
59:53 · Cotlin and swift run mobile world today.
59:57 · Cotlin on Android, Swift on iOS. What does swift do better than cotlin?
1:00:03 · Yeah, swift I really like swift as a programming language. I feel like um in contrast to cotlin they one of the things that cotlin had to do was to have interoperability with both your existing Java code and targeting JVM bte code.
1:00:21 · Swift does have interoperability with Objective C, but I feel like they had a clean slate where they got to decide the the language features and capabilities that they wanted and they but they also got to decide how it was compiled because they didn't have they didn't have this like existing representation that they they had to to target and so
1:00:41 · all kinds of stuff around like the error handling in Swift is much more of a first class thing in the language. it it forces you to handle functions that potentially throw or don't throw. you can um it's forced upon you in a similar way that like nullability is forced upon you in cotlin whereas contrast that to
1:01:01 · cotlin's way that it handles exceptions is basically that it it doesn't uh it you know it the JVM has its exception concept the Java language has the checked and unchecked exception concept and cotlin essentially said well you know we essentially have to use exceptions because it's the mechanism of the underlying virtual machine, but we're just going to take everything and make it unchecked.
1:01:26 · And so I'd say that's one of the pain points of the language actually is that you don't know the failure modes of any function that you're calling. And so the that that's like an ongoing thing in the Cotlin language evolution is how how can we model the failures of the potential failures of a function, right? you're parsing a string into a number that might fail because you know there's letters in the string or whatever.
1:01:52 · How do you model that in a way that every time you call that function, you're forced to reconcile with the fact that it might fail as opposed to just leaving a landmine in your codebase. In Swift, that function would would be marked as throwing and you would have to either put the bang at the call site or do like a safe safe version of of calling that.
1:02:14 · And then the other thing that really stands out to me with swift is um because it's targeting you know native code they have like proper strrus proper like really dense memory representation whereas again cotlin you know every they basically built on the the JVM which everything's a class everything has fields all of those are are pointer indirections in the VM and so the memory
1:02:42 · gets sort of the memory representation of your objects gets spled out over the heap and you do these these pointer dreferences constantly as opposed to having these really packed dense data structures that you know can fit in the CPU cache lines and and so yeah the the struggle with like performance uh because of the underlying representation of of data I think um is another one that really stands out to me in contrast of the two languages and the other way around Cotlin do better than Swift.
What Kotlin does better than Swift?
1:03:15 · That's tough. Um I feel like um I actually think Swift is a better designed language than Cotlin. Um there's not too many things that Cotlin has over Swift. Um I think the benefits are secondary. It's not necessarily the language itself, it's the ecosystem around it, the library ecosystem, the open source ecosystem. Certainly the tooling, right?
1:03:37 · The tooling in Cotlin with Intelligj and even just the build systems are miles better than when you're doing anything like the having to refactor things in large iOS code bases is just not fun. I mean when Xcode got like rename refactoring after how many years like the one of the literally like the first feature that Intelligj had 20 years ago and like the iOS you know developers are celebrating it's like I'm happy for you but like you could have had this 20 years ago.
1:04:08 · Specifically the language itself I don't think there's too many things that are like really heads and tails above Swift. it's everything else around the language that really makes it such an enjoyable experience. Uh because if you design the best language, but you have no story for tooling, for libraries, for you know, for static analysis, for all all the things you need to productionize a language.
1:04:36 · If you don't have a good story around that, then you know it could be the best language in the world, but you're just not going to get you're not going to get the adoption. And so don't get me wrong, Cotlin is a fantastic language and Swift also is a fantastic language. But having all that stuff around Cotlin I think is what really elevates it to the to make it such an enjoyable thing. Error handling, you mentioned it failure models. Uh which language does the best job in terms of error handling in your opinion?
Best Error Handling? Rust
1:05:04 · I like Rust. I think uh a lot of the design decisions in the Rust language feel very intuitive to my brain. It's like of course you have represent that in the type system and of course you have to like think about ownership and borrowing and who's responsible for closing that file descriptor and uh that that in my brain and that and that's from just pain, right?
1:05:30 · That's from years of pain of of not having that in a language of of leaking things, leaking memory, leaking file descriptors, of getting your null pointer exceptions, having your unchecked exceptions, you know, thrown from a function you didn't expect to fail. Um, I you you feel that pain over and over again, you start to wonder, is there a better way?
1:05:49 · And when you look at other languages, yeah, I re I there's certainly a lot of languages doing different things, but um I think Rust really, it's a hard language. there's like a hump that you get over where the language itself starts to become intuitive. And I'm not there yet. I I'm not great at Rust, but the concepts of Rust I I want I they they align with my thinking.
1:06:13 · And so I think that um I'm not sure it's the best execution in terms of a language because it is such a hard language to learn, but the way that they model and represent that stuff I think is is the best.
Where Jake Would NOT Use Kotlin
1:06:26 · Thank you for saying that.
1:06:29 · Um but we get back to cotlin where would you not use cotlin I do a lot of cotlin in my day job and that means when I do hobby things I want to do something very different and so uh a thing I've been doing lately is u microcontroller things uh which are very very low memory
1:06:50 · so you can use cotlin to target them um but it's just it's a little outside the comfort zone of the language anguage the language wants a little bit more um of like a full operating system around around it and so yeah for like an embedded a real low-level sort of under the hood thing um I think there's just a little too much the language is a little too big to fit in that space I'm not really a fan of using cotlin on the web
1:07:19 · um I think if you already have a code base that has cotlin and you want to re you want to you know reuse all of that without having to reimplement or you want to go for this I want a single source of truth for this business logic or something and you know you choose cotlin the fact that it can compile to the web is a huge advantage but if I'm sitting down and I'm trying I'm saying I'm going to build this you know web application I don't think it's the first language I would choose uh I don't think
1:07:50 · the the way compose UI works on the web is is really respects how the web works Um I think if you're going to target that as a platform the if you're going to target the web as a platform and that's your only platform you probably wouldn't choose compose UI or cotlin first. Um but of course if you already have those things you know basically being able to flip a switch uh and take something you already have and and put it in those different places. It's the same for um like iOS.
1:08:17 · It's really the same for everything but the JVM honestly. Uh the fact that you can take something you already have and get it working on iOS is a huge huge benefit.
1:08:31 · When we were doing these things at Cash App, the idea was not to replace our iOS engineers. It was to free them up so that they could work on the like really really interesting parts that make the iOS experience, you know, good, which was the the user interface, the the dynamism, the animation, the interaction, the things that were specific to that platform and free them up from, you know, the writing the same
1:08:58 · code that syncs data from the server or uh, you know, implements basically the the back end um of an application. in it. So while cotlin ultimately works in all those places it can work in all those places if you're choosing um you know if you're building an iOS application I don't know and only an iOS
1:09:19 · application I don't know that you choose cotlin right you make the safe bet and you you do something like swift and so um it's funny that cotlin does run almost everywhere and so it can the fact that it [clears throat] can be a choice I think is a big advantage But yeah, those I mean those platforms are different for a reason, right? They wouldn't exist unless they had something different about them.
1:09:40 · And so if you're if you're targeting them from scratch, embedded web, iOS, um or or other things like that and that's the only thing you're targeting, honoring what makes that that
1:09:55 · platform unique and different. either the you know the web is the web or the the constraints of the microcontroller thing or you know iOS with its its really rich sort of user interface interaction modes uh it's not the first choice I would make is it the application domain for you which actually defines the programming language like you mentioned like embedded programming
Why Rust for Hardware
1:10:21 · what language would you reach for there it's tough yeah it you know choosing it for a product you're building for a company is different than what I would choose for me playing around as a hobby.
1:10:33 · And so yeah, uh for that kind of stuff, uh I've been doing Rust. Um Rust is a really cool embedded story. Um there's a lot of libraries that make interesting hardware problems exposed um in the language in a in an interesting way. Um, so they basically use their their async concept uh and map that to map that to hardware.
1:10:56 · So you can essentially like await a button being pressed as opposed to having to do a polling thing yourself or setting up some sort of, you know, interrupt mechanism that wakes you up. Uh, you can essentially model that in in one line of code. And since I don't get to use Rust in my day-to-day and like I said, the language really speaks to me in in the concepts and its values, I I choose it both so that I can, you know, do the thing that I want to do, but also because I want to excuse to to play with the language.
How Cash App Used Kotlin Multiplatform
1:11:29 · In 2020, you went back to Kashab and spent 5 years there. What did you build?
1:11:36 · Yeah, the primary thing that I built over that time was a multiplatform solution for uh our business logic. And so we had this problem where we needed to update the app faster than essentially through the app stores. Um, and this was usually around like uh some sort of legal requirement like a a state in the US would come and say you have to change your wording of this, you know, cuz we're dealing with money.
1:12:04 · There's a whole bunch of legal stuff in place, the regulations that you have to follow. and they, you know, they would come and say, "You have to change change this wording or change how this renders in order to come into compliance and you have 3 days or, you know, we're going to prevent you from sending money in our state or, you know, whatever, fine you or all kinds of reasons." And so we had this need to tweak the app's behavior faster than we could.
1:12:31 · It's not impossible to do app store releases that fast, but having to do that all the time, having to sort of break your release cadence was a burden.
1:12:40 · And so what we were building was a way to update parts of the business logic and user interface in the app without requiring uh an app store update. And so we evaluated a bunch of different technologies and ultimately settled on Cotlin Cotlin multiplatform. uh we were targeting uh JavaScript as the the primary sort of engine. So our Android and iOS apps shipped a JavaScript engine. We were using Compose but not Compose UI. So all of this logic was still written in Compose.
1:13:11 · It was running in the JavaScript engine. It would essentially reach out into the native application and like marionette the user interface to you know change how things were being rendered. And so what we could essentially do is when these you know requirements changed or even just iterating on the features week to week
1:13:31 · we could ship that as an update that downloaded by the clients and then the next time you know the the app restarted the new logic would run and you would get it's still all native views you know it felt intrinsic to the platform the user otherwise was hopefully unaware that this change was happening behind the scenes. Um, but yeah, we had this sort of indirection between the the UI and the business logic that could be updated out of band.
1:13:58 · We focused on JavaScript because that's all there really was at the time and we were going to switch to web assembly at some point as that ecosystem is is spinning up and becoming more mature and becoming a a real option.
1:14:11 · uh and yeah the certainly the the from a technological perspective there were limitations but ultimately was very functional. A lot of the problems we ran into were people problems uh getting getting buy in from you know different parts of the product having churn on the
1:14:30 · the management of the project um and ultimately that you know it was very successful in terms of execution. we like got it done and was able we were able to ship this uh and it actually did it held a bunch of load like really loadbearing screens in our apps that you know millions of people would be interacting with every day.
1:14:49 · But as the company was changing around um they basically wanted to figure out a different approach and so that project got wound down but thankfully all because there was nothing specific to the product in it. It's all open source and so the libraries that we built are all open source the tools that kind of stuff and there were even spin-off libraries that that came out and um yeah
1:15:14 · they're still there and it was a really reward it was a really rewarding experience and because it it took you out of uh the sort of normal comfort zone of of cotlin it's this thing that you know you you know really well but then you're putting it in a place that's very foreign inside the the JavaScript ecosystem and using compose without compos O UI and so um yeah it was a fantastic sort of learning experience and I feel like a lot of the stuff that I do today is somehow heavily is is
1:15:44 · really heavily influenced by a lot of the technology choices that we made and the um the libraries and stuff that we open sourced.
Kotlin Multiplatform vs Flutter vs React Native
1:15:51 · Let's give an overview. So we are talking about Kotlin multiplatform KMP here. Uh what is what is it solving that maybe flatten and react native don't?
1:16:03 · Cotlin multiplatform is I would say it's relatively unique in the way that it decides how to target each of the platforms and so on the JVM and on Android Cotlin compiles to Java byte code on native so either iOS or like your your PC or um the microcontroller thing it uses LVM to compile to like proper native code and on the web.
1:16:31 · It compiles to JavaScript and then now also the web assembly stuff is is another target. Uh and so it can live in each of these ecosystems using sort of the the like native way that code gets executed on them in contrast to something like Flutter which is it's it's written in one language but it only compiles to native code. It's essentially like what a game is, right? A game has its own entire rendering stack.
1:17:01 · It's this native thing and you run it on any any platform. It has its own UI toolkit. It looks like the game no matter where you run it. That's essentially what Flutter is doing. But for for applications, it's not really honoring the what makes each of these platforms unique because it's it's removing it's removing that sort of that intrinsic UI toolkit element uh and and recreating it all recreating the entire rendering stack.
1:17:28 · And so if you're going to do that like why do we have why like why do we even have you know why do we have two platforms why or even with the web why wouldn't you just make you know a website and a website runs everywhere um so I think that that for me is a when you look at all these alternatives for sharing code um some of the largest
1:17:55 · libraries in the world that we rely on like SQLite written in C runs absolutely everywhere but when you want to use it somewhere on Android we take it for granted that somebody has already done the work to like reach out into native code and bind to the C library and deal with marshalling objects across that boundary the same thing's true for something like flutter and you you don't get that with cotlin when you run cotlin on iOS you can talk to the same objects in the same
1:18:24 · memory space you can you can link directly against you know libraries and that's all going to get compiled together in a single binary for the web. You can talk to JavaScript. You can expose a JavaScript API and it all ultimately gets compiled into a single bundle and you know has the same essentially the same performance characteristics.
1:18:43 · You're not running something that's essentially like a foreign body um on each of these platforms. uh whereas yeah with flutter and uh but that's also right so that's that's cotlin multiplatform cotlin makes that choice they did the hard work to do that you know in flutter you're like in the dart ecosystem you build this giant thing and that goes that that giant blob goes everywhere with cotlin you can pick and
1:19:10 · choose how much you you want to share you don't have to share everything you can share just the things that are annoying to write three times or errorprone or you know whatever you take that as a smaller reusable piece and then do the native thing the you know so-called native thing on each platform to to give the best user experience for
1:19:31 · the people that happen to be on the web or happen to be on iOS where your app feels like any other app and you otherwise don't know that you know there's this this shared colon under the hood I watched some of your talks and it looks like you you like making jokes about React Native I like React Native a lot more than I like Flutter. I think Flutter is sort of offensive in the decisions that it makes.
Wharton: ”Flutter is sort of offensive”
1:19:56 · And there's like a really your company has to be really dysfunctional when you build the most popular operating system in the history of the world which is Android and the most popular platform which would be Chrome and the web. you control both of those things and yet you build a third platform because of essentially dysfunctions of your company that that you know you would never see that from Apple in contrast.
1:20:23 · They would never build a competitor to Safari and iOS and and release that. React Native at least tries really hard to you know render using the native UI of each of these platforms. You can run your React business logic on the web and get your DOM elements. You run it on iOS, you get your UI views. You run it on Android, you get Android views.
1:20:48 · That's a hard thing to do. Uh, and it takes a lot of work. And I think the reason that we we as Android developers don't like it [snorts] is because, you know, you're it's goes back to the thing where you're like taking away a lot of the things that we enjoy about working on the platform. But ultimately like at least the technology choices that that React Native makes honors the platforms in a way that it it tries really hard to give you that that native feeling experience. And you can do really good React Native apps.
1:21:21 · You can do really good Flutter apps, too. But at least with the React Native app, with a Flutter app, I mean, I can tell and like my mom probably couldn't tell, but I can tell. With React Native, you can absolutely fool someone because it's just the normal UI toolkit. You can't otherwise know just from playing with it that it's being powered by, you know, JavaScript. And ultimately, the thing we built at Cache App is not that far from React Native. We looked at React Native.
1:21:50 · There's a lot of things we liked.
1:21:52 · There's a lot of things that we thought were the wrong decision to make. With React Native, you get a ton of control over the UI on each platform. you can set all these different properties to really tune how it renders. Uh, and for us, we like already had this design system, you know, the the all this was in place on all the code bases. And so what we ultimately chose to do was to really restrict how you could render from the um the shared codebase.
1:22:19 · So you would just say like this is a primary button. You don't know what color the button is. You don't know what the corner radius is. you don't know what the click or you know how the ripple on Android or whatever you don't get to set any of that you just say it's a button whereas on React Native you can you can go and you can set you know the corner radiuses and that kind of stuff so it gives you a lot of power um and so yeah you know they get we just ated them in the Android ecosystem because they're essentially
1:22:50 · compete they're competitors right and so you know you it's a friendly competition hopefully uh I mean it's the most serious thing, right? It's your your livelihood essentially. But um yeah, I do think I would much rather my be using a React Native app than using a Flutter app. That's for sure.
Why Native UI Is the Best UI
1:23:09 · I think you're referring to Redwood, right? The multiplatform UI library and it is focused on native rendering. So you said what what it is, but uh what was the main reasoning for you behind this decision like being native rendering stuff? Yeah, it went back to like we still at the time and and with my values is I still really think that you know native UI is the best UI.
1:23:31 · Like I don't want I I understand why like a product person wants the app to look the same on every platform because to them it's like you know I want the user to just always know my product and be in my
1:23:51 · product and feel comfortable with how my product looks but nobody is jump not nobody plenty of people are jumping between platforms but in general most people are not jumping from Android to iOS to web what they're doing is they're on one platform and they're using, you know, 20 apps on that platform and they're jumping between apps within that platform. So, they're going from one iOS app to another iOS app to another iOS app or one Android to Android to Android. And so, consistency within the platform becomes the thing that really gives them comfort.
1:24:22 · When a thing when a button or when you know a list dragging behaves the same way across apps that gives them that comfort, that intuition that they know the behavior that's going to happen, what they can expect when they, you know, put their finger down on a button, how it's going to react, how it's going to look, what the controls even mean, what the icons are, like all that stuff. When you're living on the same platform, you want to be consistent app to app.
1:24:49 · And so yeah, that was sort of the underlying motivation is we still want the UI of each of these platforms to be the native UI so that things can look different. But then from the perspective of like the the business logic that's behind it, we just we just want to say like put a button on the screen, put a put a toggle switch and on Android the toggle switch is you know a horizontal thing and on iOS maybe it's a vertical thing and uh the details of how
1:25:18 · something is rendered on each platform are not important to the business logic which is the thing that is shared the thing that nobody wants to reimplement three times. the thing that you know you go to your iOS counterpart and say well how do you handle this case and it turns out they handle it differently like that's the thing that we wanted to eliminate and ideally we free up the
1:25:41 · whole thing was we want to free people up to to really make the native the UI experience the best that it could be it's a big ask right it's very different than like a a React Native where you can just sit down and and put pixels on the screen for something like this you really had to of like this design system concept already built.
1:25:59 · You already had to have what what are the reusable components of our app, the you know the the sections or whatever that appear on multiple screens, the the highle concepts and how do you model those in the way that that you want to expose the reusable code. It's very much not turnkey.
1:26:18 · It's not it wasn't a turnkey thing. it it we already had that upfront initial investment in building those things and this was there to um you know realize that to make to to hopefully improve on it but it's not necessarily a
1:26:34 · path I think you would pick if you were building something new because there's so much that you would have to do to even get that initial you know first button or whatever on the screen because you have to build up this whole design system concept and model it and um so yeah it's uh That was really the idea behind it. Um, elevating the native UI of each platform and allowing them to be similar, provide the same functionality but not necessarily render in exactly the same way.
Library vs Framework: Why It Matters
1:27:06 · I saw it mentioned somewhere that Redwood is library but not a framework.
1:27:12 · So it seems like it's an important decide decision. Is it? I would say in general that's how we we think of the things that we build. We want them to be a brick that gets slotted in, not necessarily the foundation on which everything is built because things change, right? It the the I mean nowadays a lot of these apps are 10, 15 years old. Uh and so, you know, we've gone through different ways of modeling reactivity.
1:27:43 · We've gone through an entirely different language, right?
1:27:47 · We're in a different language now than we were 15 years ago when a lot of these code bases started. Different UI toolkit. And so when you build things in a way that's the library, not the framework, it does shift burden onto the the person consuming it because it's not, you know, drop a oneliner in your in your app or have all your classes extend from this base class kind of thing and you just get everything for free.
1:28:13 · You know, it's like you have to do a little bit of thinking about how this is going to fit into your into the rest of your codebase. And you probably have to write glue code that nobody really likes to to tie it in. And sometimes that doesn't feel well uh feel very good. But as your tastes change as a developer, as the product needs change over time, being a library gives you that flexibility to to slot in and slot out as as those things change.
1:28:42 · You know, maybe you have a different opinion in five years and you say we did the wrong thing. If you're a framework and you're you know you're really deep tied into everything that that you know the codebase has evolving that to something else is a huge undertaking.
1:28:58 · If you're a library and you have built things in somewhat of a you know modular way then it's still going to be effort to do the migration but hopefully it's in a way that you know is can be done incrementally or you know in that specific example with Redwood like we were able to build that part of it where the JavaScript part where the dynamic updating part was actually totally separate.
1:29:24 · So you could run Redwood by itself completely natively and just get the design system abstraction uh and then use Cotlin multiplatform to to take your business logic and compile it you know natively entirely on its own. But then the the underlying updatable mechanism this library called zipline was separate and you could just slot that in underneath because again that was just another brick. It knew nothing about Redwood. Redwood knew nothing about zipline.
1:29:53 · Um, but then there had to be that glue code, right, that you write to to take those two bricks and turn them into something that's ultimately, you know, of higher higher value than the individual pieces on their own.
Jake Wharton's Dev Setup
1:30:07 · What's your personal coding setup? ID, plugins, tools.
1:30:12 · Nowadays, it's pretty spartan. It's vanilla Intelligj uh or Android Studio, depending on what I'm working in.
1:30:20 · Plug-inwise, very, very few. Um I have a SQL delight plugin usually which is the you know one of the libraries that I worked on for for doing SQL stuff. Um other than that I have a ter I have a terminal ghosty that I use uh outside of the IDE. The new terminal in the IDE is re really really good though. I just have habit of using uh a separate terminal and then uh yeah I got my Firefox open with you know documentation and those are the three things I'm alt tabbing between all day.
Why Firefox, Not Chrome
1:30:52 · So Firefox not Google Chrome.
1:30:54 · Oh yeah that goes back to you know the the ethics of you know in reality the competition of the browser market is what made Chrome Chrome. But then you know they lived long enough to see themselves become the villain. they they have an disproportionate market share and they can now essentially strongarm the ecosystem as opposed to participating in it in a more healthy way.
"A Bug in the Compiler": Life as a Legend
1:31:19 · There is a quote in the cotling community when Jake Warden's code fails to compile it means there is a bug in the compiler. How do you live with that?
1:31:29 · So I have a funny story about stuff like that. Uh when I was at Google, there's a a subreddit that has the CSS changed so that everyone who comments, it's my name. Uh and what would happen is someone at Google who didn't know that this was what was happening would screenshot this comment that supposedly I made talking about, you know, Flutter.
1:31:52 · Well, there's plenty of comments where I'm talking about Flutter that were me, but it would be a comment that's like, you know, in incendiary or, you know, about Google products in a way that I should I wouldn't be speaking shouldn't be speaking about and they would report that to my manager. And I had had a conversation with my manager's manager about this thing called Reddit and how you can have CSS to change change these quotes. I've been very fortunate to be successful in you know a lot of these efforts for building these libraries and gain some recognition from that conference speaking as well.
1:32:22 · Um and so yeah I you know there's some people who like to have fun with that and I I certainly don't take issue with it.
Kotlin's Most Annoying Feature
1:32:31 · What cotland feature annoys you the most?
1:32:34 · Historically I would have said like public by default I don't really like. Um, I think it should be internal by default. Uh, I definitely miss that from from Java. I I get the arguments for it.
1:32:49 · Um, but I and this might also be my bias as someone who tends to work more in libraries, um, where you need to be very careful about the public API that you expose in a library. But that's my old answer. My new answer we actually already touched on which is um I don't feel like the exception and error handling um was a thoughtful choice.
1:33:13 · I think that was um it was a necessary choice because of being built on you know having to interface with Java and being built on the JVM targeting targeting JVM bite code. You really need to model stuff correctly and have tools in your tool belt to be able to model the fact that things lots of things are fallible. And those cases are actually the more important cases to handle. They are exceptional.
1:33:41 · But behavior when that happens is the difference between, you know, we've all been at a a product and like none of the buttons are responding. You know, you're like trying to buy a ticket for the train and none of your touches are registering because you accidentally like maybe touched twice and some invariant threw an exception and a background thread crashed or something and now the whole thing is unresponsive because they never thought that that could happen.
1:34:08 · And so you get this exception that has bubbled up from the middle of nowhere that has taken down, you know, your whole application. networks. There's like all of our these like mobile apps that we've historically built. Uh we're at our house or we're in an office. The Wi-Fi [snorts] access point is 20 ft away. Uh you're hooked up to your, you know, fiber internet.
1:34:28 · Uh and realistically, when I use your application on the train as it goes underground and I lose, you know, I have intermittent cell connectivity, your whole app starts grinding to a halt or failing and becomes unusable. you can just tell me that there's no network or um you know if the in the case of the ticket thing like if you knew that that if you were forced to handle the fact that that could happen then you would build in mechanisms such that you you know restarted yourself or something and so I
1:34:59 · really want the language to model the fallibility of things the the errors the exceptions in a way that forces you to think about it um and especially because those things happen far away from each other the the the code that you're calling, you know, far away that's doing some network request um that that might fail at the call site. You might not know that underneath the hood it's calling out to a database or calling a you know a remote service or whatever.
1:35:27 · And so being forced to either decide to handle that error somehow or propagate it up to the caller in the exact same way that we do with all the rest of the static typing uh for the happy path. I I want that to be in the language because I just keep you just keep getting burned by by exceptions and u the language hasn't done enough yet for it. But there is hope. So we'll we'll see here.
Why Everyone Hates Gradle
1:35:53 · I saw a popular Reddit post asking what was your most awful experience while using Kotlin and the top answer was Gradle. Why Gradel?
1:36:04 · Gradle is definitely a point of contention with people. I mean I feel like we've gotten great value out of it.
1:36:12 · Uh I have been doing Android since before there was Gradle and having a build system uh it was extremely welcome. Um, ultimately I think one of the problems with Gradel and why people get so frustrated from it was that they early on they focused on how easy it was to write the the build script and how sort of like cute it looked the syntax uh as opposed to correctness or performance.
1:36:42 · Uh, and they've had to like back their way into correctness and performance over the last 10 years. And that means that that TUR syntax that you wrote often was the inefficient syntax. And so there's been a lot of pain, a lot of churn where we've had to, you know, essentially rewrite these build files incrementally over 10 years to get ourselves into a place where we have fast, incremental, correct, reliable, performant builds.
1:37:14 · And so that stands in stark contrast to, you know, a build system that focuses on like correctness and performance first, like a basil or something, but just has terrible UX is like a huge pain uh to write and deal with. And so I yeah, Gradle's pain is almost just like the churn, the necessary churn that they've had to to get into. You've been an Android developer for almost two decades. What keeps you from burning out?
How Jake Avoids Burnout After 20 Years
1:37:45 · I do feel like in the first half of that, Android itself was constantly and mobile in general was really evolving and and growing into sort of the thing we take maybe for granted today. So there was a lot of opportunity within Android itself to learn new things, try new things. The every year uh you know when when IIO would happen, you'd be excited for all the new capabilities of the of the platform.
1:38:12 · Uh, and so for a while that sustained me and then I feel like nobody told Apple or Google that like they were done with Android and iOS because in the past, you know, maybe 10ish years, everything new that's come out. It's almost the opposite where you the same thing with, you know, product updates.
1:38:34 · You you tend to feel dread like what are they going to take away from me and force me to do now? And so what I do is I turn to something else. Um I've been playing with hardware stuff. You know, I it's really nice. I think it's really powerful to be able to to code something up and throw it on your phone and and have somebody else interact with that and have that be fast and real.
1:38:57 · Um, but then like hardware is this other level of realism where it's it's physical uh, and you know it's it's tactile and it can interact with the world in ways other than just being a 6- in you know screen of pixels. That's been an avenue for me. Um, and then through that is also um, just looking at other languages, learning other languages.
1:39:24 · One of the things I tell people um who sort of ask me for you know general advice as to how they can grow and be better at Android or Cotlin or or whatever is to actually go learn a different language. Um so like when I learned Swift or Rust um Zigg C you don't get proficient at it. The goal is not to become, you know, as capable as a developer in that other language.
1:39:55 · It's to open your mind to different ways of doing things. Uh, and then certainly, you know, there's languages break your brain even more. Uh, we were talking about Haskell. That's another great example of just like really teaching you something different about how you model things. And then you don't realize that the things that you experience as part of doing that you bring back to the language that you know you work in day-to-day like you know you pattern match on a problem.
1:40:25 · You're like oh like this was a thing that I experienced when I tried out Swift or when I was doing Zigg or like when I did Zigg I saw that they made this decision about how to handle something and I didn't like that.
1:40:41 · So, let's make sure that we find something different. You you bring that experience in. Um, it's it's sort of the thing of, you know, you you're you're culturing yourself. It's the reason why they force you at university to take history classes and, you know, to to learn math and to learn science and all these different things. it um it sort of rounds you out as an engineer and allows you to hopefully have these moments where you get to pull from that that knowledge. It's uncomfortable but it's exciting.
1:41:12 · I find I find that you know looking into the unknown thing that I have it's going to be painful but I'm just going to you know there's thousands millions I don't know people of working in these other languages like they have done it so like you can do it too you just have to do the work um yeah and then just I like
1:41:35 · coupling that to something that is relevant for whatever I'm interested in right now so very concrete example we have a sprinkler system at our house and I absolutely hate the unit that controls it. Um, but it's literally just a microcontroller and like 20 relays and so that's like a piece of hardware that I can get and put my own software on it and write, you know, a thing and that's an excuse to learn a language that I can run on a microcontroller.
1:42:06 · It's an excuse to I I did a little bit of electronics when I was really really young. It's an excuse to get back and learn how to do like the most basic uh of like circuit design of just putting relays relays on a board essentially along next to a Raspberry Pi or something. But it's relevant to me like I have a reason I have a just a a motivation an intrinsic motivation to finish the task.
1:42:30 · And so [snorts] I might not push myself to learn a a Rust or a Zigg with no other reason to do it even though it would be beneficial I think. But by tying it to something that I have other motivation for, it's going to allow me to actually make progress. And then ultimately that, you know, becomes an entertain a source of entertainment for me, right?
1:42:55 · I it engages me and then I can take that back to what is the day-to-day job where I don't think Android is that interesting anymore. It's sort of a done operating system. Cotlin still holds my my interest. the the now that we're over um the K2 hump and the libraries and language team are really picking up the pace on what's being added to the language that that is still exciting finding something sort of tangentially
1:43:26 · related to my work because I ultimately like programming is the thing that was a hobby that became a job um and I'm fully supportive of people that do you know if you want to prevent burning out and you do wholly unrelated things to programming I wholeheartedly support not being on, you know, the computer uh when you're not working. But for me, um yeah, the it's still it's still a source of like delight for me.
1:43:53 · I feel like there's there's a lot that I have left to learn and but now it's going outside of uh you know, the things that I work on day-to-day to find that source of inspiration. You've mentioned many programming languages here. Do you think that it's useful for every developer to learn more than one programming language?
Why Learn More Than One Language
1:44:12 · Definitely more than one. Uh I don't think you necessarily have to go crazy and learn five or six or something, but not being entrenched in, you know, not being just having the single programming language that you become an expert in, whatever language that is, is a very useful thing to do. But there's different programming languages for a reason.
1:44:37 · And so just dipping your toes in and seeing the choices that the language designers have made uh and why and then like I said, you know, maybe bringing that thought back to the language that that you work in. Um it's certainly not going to hurt you.
1:44:59 · I think it will only benefit and then it's weird the times when it comes up when you suddenly realize you're like this is that exact same problem that that you know language was built to solve. I mean we talk about Rust a lot like Rust the language was very clearly built to solve a lot of problems that like you know come up in C and C++ but
1:45:22 · that's not to say that like when I learned Rush Rust and focused on um things like ownership like I bring the concept of ownership back to Cotlin and Java and in every other language because that is such a fundamental thing like who is responsible for this thing that I just allocated when I pass it to that function, can I still use it? Am I still responsible for cleaning up the resources or closing the connection or whatever? Or did I transfer ownership to that function? And a lot of these languages don't have ways to model that.
1:45:58 · uh and you can start identifying these situations where like oh this is a risky because we can't model this what we're how we're building this class or these functions or you know the parameter types is like risky because somebody could make this somebody who's not you because it's also usually not you it's the person who comes in 6 months later or 3 years later and refactors things and doesn't realize there's that implicit contract of I mean this is a
1:46:25 · very specific example but doesn't realize realize there's that implicit contract and they refactor the codebase, create a memory leak or, you know, close a connection too early or whatever. Um, and so you bring that back into how you model things in in Cotlin. You try and build them in a way that it's, you know, clear the ownership responsibilities, the transferring, who owns what. Uh, and so that that's one example. And I think almost any other language is going to teach you things about the things in your language.
1:46:55 · I you know you learn Java cotlin you don't really think about we talked about like the data layout stuff you don't really think about how data sort of gets to the code that's executing uh and then you go do something like a a C or zig or certainly
1:47:12 · rust or swift or any of these languages where you can have these really packed data structures where you're utilizing every single bit and that fits in you know you could fit multiple in a cache line and that's why that language is eight times faster than the language you're working in because you're all you're over there chasing pointers and having all these cache misses. Um, so yeah, there's there's like no shortage of things in other languages. And so again, that's why like tying it to something else that like motivates me to get out of that comfort zone.
1:47:43 · Like I need the reason to go play with Rusters or Swift or whatever. Uh, and it it doesn't it almost doesn't matter like if I wouldn't choose Java as a Cotlin developer. Obviously, you want to choose something that's at least going to challenge you a little bit and hopefully open up your mind to you know these new things that you otherwise wouldn't be exposed to.
Bringing Rust's Ownership to Kotlin
1:48:06 · So like do you have a small borrow checker in your head when you write Cotlin?
1:48:10 · So I have this like list of dream projects, you know, if I somehow still had a salary but had no work responsibilities that I would build. Um and one of them is yeah basically trying to bring ownership into uh which you know at Cotlin Conf this year um there's a researcher I guess that has um a very early
1:48:36 · uh it's not even a keep it's basically just notes on what it would look like to start uh bringing the semantics of like ownership to uh the Cotlin language. So cotlin with love lifetimes.
1:48:49 · Yeah.
1:48:49 · I mean it's it's one of those things that's um it feels like it should be a thing that is is explicit in the language once you once you see it and you have that moment where like it clicks or you can think back to like bugs that would be solved by having explicit ownership. In Java like there's this pattern where if you're given a list you do a defensive copy of it because all lists are mutable in Java.
1:49:13 · And so if somebody hands me a list, I don't know if they're immediately going to then append another element to it. And so when you receive a list, you do a defensive copy so that you avoid that. And that's like a whole class of problem that gets eliminated by by ownership.
1:49:28 · It's a little bit cotlin helps there with the mutable and readonly um list uh sort of split um but it's not quite there. um ownership like you know you give me that list and then you can't touch it anymore or you allow me to borrow the list and I know that you you know still have the ability to mutate it. So um yeah when you start seeing those things when your eyes are open to them then you start start seeing them everywhere. We've talked about your open-source work. How big is Cotlin in open source ecosystem today?
How Big Is Kotlin in Open Source?
1:50:01 · I think one of the really nice things about Cotlin is that we get to leverage the Java open source ecosystem and vice versa. And so there certainly were a subset of people that were upset when we took like OK.IO and OKHTP and rewrote them in Cotlin.
1:50:21 · They when we did that we maintained strict binary compatibility. So if somebody got the new version of OKHCP from a transitive dependency or you know somebody just bumped it or whatever your code should still function you know it will still compile and link and and work at runtime.
1:50:39 · But of course it has like the extra dependency the the Cotlin standard library dependency and so yeah there were some like purists that took issue with that and I think that so it's hard for me specifically to separate the like Java open source ecosystem and the Cotlin open source ecosystem too much.
1:51:00 · It starts really from like the culture of the the language right like the the language is entirely open source the process is entirely in the open. you can see how the language changes over time.
1:51:10 · Uh, and I, you know, the easy comparison is something like Swift where it's much more like a here's this golden thing from, you know, the Apple developers once a year. Here's the, you know, new which like a lot of Swift actually now has transition to being in the open. They're sort of course correcting that.
1:51:29 · But initially um there they were very like averse to sort of the idea of this open- source um community around the language. There just weren't there were some open source libraries in Objective C um and certainly in Swift but nothing like you would see in you know Cotlin. As soon as the language became available on Android there was this huge outpouring of of open source libraries written in Cotlin.
1:51:55 · As soon as Cotlin became a a really capable target at multiplatform, you started seeing, you know, just swaths of multiplatform libraries fulfilling, you know, these very basic needs that you would have writing multiplatform code.
1:52:12 · And I do I just think that starts from the definitely from Jet Brains and how the language is managed. Um, and also just how like the early days of the language, you know, the people who were there first kind of get to set the implicit rules that we all live by and if we start with a culture of putting things in the open, then that cycle sort of perpetuates itself.
1:52:34 · Um if you have a um a cult like a community culture where uh the language is only used in you know really serious business contexts where they're very protective about their interests and IP and um so nothing gets open source then you know that that then becomes reflected on the on the community but yeah because cotlin was used in these worlds that already had a ton of open- source practices and uh sort
1:53:06 · the Jet Brains decided to, you know, do everything in the open. Um, it just reinforces that and so yeah, it makes you know, I don't think it's the biggest um but it's definitely uh it's definitely one of the larger ones. It seems that for open source dependencies are very important. You mentioned dependencies here.
Dependencies: Trust or Fork?
1:53:24 · So you depend on some other library but then there are voices that this whole idea of being dependent on someone else's work is kind of scary like it can be there are safety issues and I think just recently ghosty offer that you mentioned uh he just wrote his he his take on like whenever he needs a dependency he just fks it.
1:53:51 · Yeah. and then never updates because that's what he needs.
1:53:56 · It's definitely a coin that has two sides, advantages and disadvantages. There's there's a lot to be gained by building on top of the work that that other people have done. Uh and I think it goes back and obviously and then the thing there's a lot to lose, right? You become you become essentially tied to, you know, that that library depending on how you integrate it.
1:54:16 · Um, yeah, it can feel like when they make a decision that doesn't align with how you think the library should go that it feels like a, you know, betrayal or they can have a rugpool moment where they switch to switch the license and, you know, try and for their for themselves try and make the project sustainable, but for you that was getting it for free, you know, you never even really considered that. Um, I think the problem goes back to the misperception of what it actually means to use an open source library. You need to feel responsible for it.
1:54:49 · You need to feel like you're um like your that code is exactly the same as the code you write day-to-day because ultimately all of that stuff gets bundled up and and shipped out and your your user, you know, the person who's consuming your your product or service or whatever. They don't care about what libraries and stuff you use. And so you need to be by you by using it effectively, you can deliver those things faster.
1:55:18 · But then if you feel responsible for that code, it starts to become a thing that you um treat the same way as the code you would write daytoday. There's this like notion where I need to get permission to like work to contribute to an open source library at work. Uh, and that's just such a, it seems like such a wrong concept because if you didn't use the open source library, you would write the code that does, you know, the same thing and then you would be responsible for it.
1:55:49 · You would you would have to, you know, if you had to change something in it, you would change something in it. And so if you want to change the open source library, like it ships in your app, you know, just go contribute to it. It should just be the norm that because it's your dependency, you feel a bit of ownership over it. you feel like you should pay attention to what goes on in the same way that you pay attention to what goes on in your codebase because of
1:56:14 · I guess the mechanism of distribution that can be challenging because you just put one line in your build file and suddenly all of these things get pulled down automatically and it it can feel like it's very far away. Um, and you definitely feel like you get a lot of advantage from doing that. And then when you get burned, like somehow it's the open- source project's fault that, you know, they didn't understand your needs.
1:56:39 · Um, whereas in reality, if you sort of took that on as more of a thing that you feel responsible for, for participating in, maintaining, keeping an eye on, ensuring it's going in the direction that you want, even if a project moves in a way that you don't agree with. and and um you know does something that doesn't meet your needs or changes something or whatever, you see it coming. You see it coming. You can sort of plan for it. You can uh deal with it over time.
1:57:06 · You can potentially stop or change or help the the open source version become a thing that works for both you and wherever the you know author is trying to get to. There's this other question I was asked um recently is uh do we even need libraries anymore if your LLM can just write you know can
1:57:28 · just spit out the uninteresting repetitive sort of you know foundational parts of your codebase and you work on you know the businessy bits um and I think that undersells that there's the value ad of just having that single code base that then lifts you know somebody fixes a weird bug that you may never hit currently or historically, but you then do a refactor, you know, two years later and you would have hit that bug, but it's already been fixed because you're using the open source version.
1:57:59 · Or somebody makes the thing 15% faster and then you're that part of your codebase is now 15% faster. It's the distribution uh of the contribution to all of these different code bases.
1:58:14 · Um so yeah you if you focus on the advantages uh and then treat them as if it's you know treat them as the same as as the code that you otherwise you know work on day-to-day I think it becomes much easier to sort of deal with how they evolve over time. Since you worked on open source professionally, uh what usually motivates companies to invest in OSS?
Why Companies Invest in Open Source
1:58:41 · It can be hard to quantify the things that you get out of open source in a way that um you know makes sense on a spreadsheet or something. Um because yeah, it's it's extra work. Um, and it's it's not a lot of extra work, but it's a non-trivial amount of extra work to take something that is already, you know, let's say the library already exists. It's relatively sort of self-contained with a boundary.
1:59:10 · But, you know, as we talked about, documentation is usually not always that great. Um, maybe the level of testing coverage. You certainly have to build like the infrastructure of publishing and all you know there's a little and then maintaining um contributions and issues as they come in like it is extra work but then other than the fact that you essentially get improvements for free in theory you know of people contributing to the codebase it certainly contributes to like the perception of your engineering culture.
1:59:41 · uh people can look at the open source code that's coming out of a company and say, "Wow, that's, you know, really high quality or really low quality depending on, you know, what the type of thing that you put out there." Uh hopefully high quality. Uh and that then can lead to maybe just leads.
1:59:57 · Um certainly, you know, Google and Facebook, a bunch of companies that had tons of open source got a ton of leads because people could see the cool things that was being built there. Uh not so much anymore depending on where you look. Um, I would say other than that, it feels good as an engineer to be able to show people what you're working on as opposed to just telling them what you're working on.
2:00:29 · Oh, I built like I built this amazing thing. It allows you to use this piece of technology in this new and interesting way and oh yeah, it's in our in our codebase that I have to, you know, two-factor off on my uh company owned laptop in order to to access or it's it's on GitHub. Like check out this stuff. Figure out how you can use it.
2:00:49 · see if you can do something else with it. There's a level of excitement around that. And ultimately like being able to do that as an engineer makes you it's not for everyone. That's the other thing is it's I don't think you should force it. One of the things when we talked about our values of of um you know wanting companies to wanting to work at a company that has open source does open source.
2:01:14 · I don't think you need to force it. It's like we don't we have to open source these things so we look good as an engineering or whatever like that that's the wrong way to go about it. It's going to look disingenuous. People are going to you know it's it might not be explicit but you can kind of get that feeling. You sort of just know when you hit something that's like this is a nice reusable thing that other people could benefit from. um maybe they couldn't benefit from it because it's so specific, but it's nice to have it in the open because it doesn't, you know, hurt you at all.
2:01:46 · And that way we can show the cool things we're working on.
2:01:50 · Um yeah, it just adds a level of like happiness to the people that find those that get excited about talking about what they work on. And there are certainly people that don't want to participate. They don't want to be seen publicly, you know, they don't want to have a GitHub presence to have the the responsibility and burden of like dealing with someone that comes and files an issue like, "Hey, you broke our app. You removed this feature. You did this thing and I don't like you for it."
2:02:18 · Uh, or here's a bunch of LLM slot PRs that you now have to deal with that you don't want. Or someone wants to take the library in a direction that you don't, you know, want to take it. Um, it's hard to have those conversations because that's the humanto human like figuring out how to talk to people. Um, there's a lot of language barrier things when you're in open source because you now opened yourself to the world as opposed to just people in your immediate vicinity. Um, that that can be hard.
2:02:44 · But yeah, there's a certain class of people for which that is enjoyable, entertaining, it motivates them. Um and ultimately selfishly uh when you leave the company if you open source a bunch of things you get to use it at the next company and yeah I have seen that as you
2:03:05 · know that's now my story uh all the things that I built and was able to put in the open I don't have to leave behind I get to use that all that work or you know some of that work at the next place I go a lot of people think that open source is mostly about unpaid volunteer work.
Getting Paid for Open Source
2:03:24 · How much of modern OSS is actually funded or contract based? There's definitely a couple categories. I think a lot of open source work now is implicitly company sponsored by the fact that they will just employ the person who works on the thing full-time. Um, that's sort of how basically all of the libraries that are were on company organiz orgs that I've worked for came to be, right? like I worked on them during my work hours and I even
2:03:54 · though you know somebody's sending me features uh requests or bugs that don't actually affect our codebase I still worked on them during work hours and I think that's fine. problematic cases start to get with when you know it's a personal project that that I have built on the side or doesn't make sense to put on the you know company or or isn't tied to whatever and that then becomes loadbearing in somebody else's codebase and for me I put it in the open for all
2:04:24 · the reasons we talked about it's I like showing what I worked on not not telling I like other people being able to riff on it and you know potentially use it to great effect but It comes with a license and if you read that license, it's just the standard Apache license and almost all licenses include something like this is that you don't have a contract with me. There's there's no guarantee implicit or explicit about, you know, this code.
2:04:50 · And we don't do a good job of differentiating the projects that are me doing a side project, you know, messing around and putting it in the open versus me at work building, you know, this whatever library that that gets published. And then when you have that problem in the personal repo, you are the single maintainer or become overwhelmed or whatever, you leave that company and then the project goes unmaintained.
2:05:17 · I don't think we have a good model for you know getting that back in a healthy state where you the companies who are using it who come to rely on it somehow contribute monetarily to it doesn't even have to be monetarily but it goes back to the thing I was saying about being able to contribute to open source libraries you know there's one it's one
2:05:40 · thing to go to a library that you use file an issue and say I I want the library to you know add this feature as an issue and it's a totally different thing to go and say I want to add this feature can I build it or will you accept contribution for it and then you do the work you know to build it or maybe they do the work but you still help out by fixing bugs triaging issues whatever that is a form of payment uh you're contributing time
2:06:12 · engineering effort uh you know you're unburdening the the person whose code you're relying on to work on the thing that you want them to work on by taking the base load that exists for open source projects, taking a little bit off their plate. Um, and then obviously like I'd love to have a solution to just finding ways to get people paid for open source.
2:06:35 · I mean, there's projects being used by these massive companies built by mostly one person because, you know, they're they're excited about it. And it's great to be excited about things like that and to build these projects. And it feels so good when you see your name and like the list of open source libraries that these apps use and people come up to you at conferences and talk about how they use, you know, the libraries you built.
2:06:57 · But then you don't you're not really getting anything from that. like, you know what else would feel good is the number in my bank account going up, you know, in response to that and and that being a sustainable thing that I can do as opposed to having to try and squeeze it in on the side as trying to like steal time from my day-to-day work to to have time to contribute to the thing that uh other people are relying on and excited about, but then I now feel obligated to as opposed to excited by.
2:07:27 · Andre Brislav the creator of Kotlin left J brains in 2020. Can a language evolve without its original creator? I think a language has to outlive its original creator and also I think it's totally okay for people to stop working on something and go work on something else.
Can Kotlin Outlive Its Creator?
2:07:50 · So if you build something that gets successful and you you know you're like I put 10 years of my life into it like like he did um and it's fantastic I want to go work on something else then you should do that and I think we're very fortunate that the language you know sur survived that incident not that it even was it was very much a non incident um which if anything is a testament to you know how everything was set up around the language but yeah Um, I I think that's a healthy thing for our language.
2:08:21 · And I think you'll find that almost every big successful language nowadays is not the benevolent dictator anymore. It's the, you know, this this shared sort of um organizational structure that that manages the language hopefully in in tandem with the community.
Andrew Kelley and Zig's Future
2:08:41 · I believe Zeke is the only example with the acting, but it's still very young, right? So, I think there's massive benefit to to Andrew Kelly being able to say, "Actually, we're going to break every single API in the entire codebase by introducing this new IO concept and and making that an explicit dependency rather than an implicit dependency." And you're going to have to rewrite 100% of your code, but it's what the language needs. And then what I would love to see, so Zigg, there's a foundation, I believe, that owns the language.
2:09:11 · What I would hope to see is as the language, he's talked about 1.0 when it reaches 1.0, I would love to see a little bit more of that responsibility become shared. If anything, just to unbburden him from what I assume is a herculean amount of effort to get, you know, to get to that 1.0.
2:09:28 · Um, and ultimately, he could still be involved uh and and be the, you know, the final decision maker, but by spreading that load out, um, it only serves to provide stability for the language in the future. um cuz you you just never know what's going to happen when people are going to want to come and come and go. So yeah.
How Jake Shaped Kotlin
2:09:48 · Have you personally shaped Cotlin? Maybe specific features or decisions.
2:09:54 · I like to think I've had uh a couple nudges on things. Um, one of the ones that really excited me that I thought was never going to happen was the switch from uh when for a when clause to be become exhausted by default. So you have to include all of the potential cases.
2:10:17 · Um we I mean that that's again a thing that you see in other languages and when you experience it you're like that kind of makes sense. you know, if I add a new clause, if I add a new um subclass to my sealed interface or my, you know, a new variant of my enum or whatever, then I want the compiler to tell me all the places where I'm not going to handle that correctly. Um either I'm going to fall into like a case where it does something unexpected or, you know, it just will throw an exception or something.
2:10:48 · And so yeah, we at when we were at Square um we built a compiler plugin and tool to to do to force exhaustive wens and I thought it would never make it into the the language proper and I um so this was when Roman uh Elizer was the um when I
2:11:11 · was at Google that was when the transition happened from from Andre and I remember talking to him about it and him just being like yeah that's That's I think that's a thing that we're going to do. I'm like that's excellent. Like please yes. There's certainly nothing that I've directly been uh attributed to. Um but yeah, one of the things and one of the reasons that keeps me in Cotlin is a lot of the decisions that they've been making over time about what goes in and what doesn't go in feels like they align with my my values that I want from a programming language.
2:11:42 · The things that I feel um it should do for me. and the things it shouldn't do for me, the things it should, you know, leave as responsibility to the programmer. So, there's an error and exception proposal that's now a year too old. Uh, just got re refreshed as we're recording this.
2:11:59 · And so, I'm hopefully hopefully that, you know, keeps moving and I can provide like useful feedback about my opinion on it as I would encourage other people to do. you know your especially since all you know our code bases can't be seen by you almost
2:12:17 · all of them are closed source right um the the ways you use cotlin the design patterns you come up with the things you build a lot of times there's a a a language tweak that could be made to make that easier but if you can't see it if you're not participating in that ecosystem of trying to tell the language what it should be for you then you know you're basically just letting go of the reins and letting other people control.
2:12:42 · And so that's, you know, that's that's really all I do and that's what I encourage other people to do is just look at the look at the proposals as they come in. Watch the talks about language evolution at at Cotlin Conf and stuff. There's channels on the Cotlin Lang Slack where they uh there's discussions about where the language is going to go with features and stuff. um you can have a little bit of involvement and every now and then you can just send a oneline comment like yes or no you
2:13:07 · know this is why I think this and yeah you're helping shape the language now who is actually steering cotlin in 2026 jet brains Google or the community it should be all three uh and that was part of the point of moving the language away from jet brains into the cotlin foundation uh and that it has the the structure such that no one party I mean
Who Controls Kotlin: JetBrains, Google or Community?
2:13:33 · the community doesn't really have explicit membership to the foundation um but certainly like we outnumber uh the people at Jet Brains and and at Google and so yeah they I mean if they're doing their jobs effectively they're listening to what's going on in the community as well as you know wrangling that what I'm
2:13:55 · sure is uh absolutely insane level of feedback into something that's digestible in order to move the language forward that was u born out of um you know one of the things we talked about about Google adopting Cotlin they already did the thing where they used the language that another company owned and there was a massive lawsuit about it and so if we're going to adopt this new language uh it can't be owned by some other company that can turn around and you know do something that would ultimately hurt Google.
2:14:25 · Yeah, I think if it's working correctly, which I think it is, it's it's all of the above. It's all three.
What If Kotlin Disappeared?
2:14:33 · What would the world lose if Cotlin disappeared?
2:14:35 · I think it would be a big loss, but I also think it's okay for programming languages to not live forever. Um, I don't think Cotlin should end anytime soon. Um, but yeah, it's okay to not
2:14:50 · grow to infinity to encapsulate every single potential use case. um we we have different programming languages for a reason and so if a time comes when programming somehow fundamentally changes where where cotlin doesn't fit I think that could be okay and you personally what would you lose I would definitely lose my ability to probably have a job anywhere I'm not skilled at any other language enough to really make money I've sort of put all my eggs in the the cotlin basket basket.
Please Don't Make It Go Away
2:15:26 · I very happy with putting all my efforts behind Cotlin and making that the the thing I tie myself to and um yeah, so please please don't make it go away.
2:15:46 · [music] Goat.
2:15:55 · [music] [music] [music] Heat.
2:16:18 · [music] [music] Heat.
2:16:34 · [music] Yeah.
2:16:42 · [music] [music] Heat.