Tech Over Tea - Ladybird Browser Is In For A Rusty Future | Andreas Kling

Episode Date: March 13, 2026

Today we have Andreas Kling back on the podcast to talk about the Ladybird browser but this time to talk about the porting of the project from C++ over to Rust after abandoning the goal of porting to Swift==========Support The Channel==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson==========Guest Links==========Website: https://ladybird.org/Twitter: https://x.com/ladybirdbrowserPersonal Twitter: https://x.com/awesomekling==========Support The Show==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson=========Video Platforms==========🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg=========Audio Release=========🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw==🎵 Anchor: https://anchor.fm/tech-over-tea==========Social Media==========🎤 Discord:https://discord.gg/PkMRVn9🐦 Twitter: https://twitter.com/TechOverTeaShow📷 Instagram: https://www.instagram.com/techovertea/🌐 Mastodon:https://mastodon.social/web/accounts/1093345==========Credits==========🎨 Channel Art:All my art has was created by Supercozmanhttps://twitter.com/Supercozmanhttps://www.instagram.com/supercozman_draws/DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. I'm as well as your host, Brodie Robertson, and today we have a returning guest. I think you came on like maybe about a year or so ago, something like that. Welcome back to the story, Andrew's Kling, the lead developer creator of the Lady Bird browser. How about you just, for anyone who's unaware, introduce yourself, and introduce the project. Sure. Hello. Nice to be back. Yeah, we started building Lady Bird. Well, it was originally an operating system called Serenity OS.

People might have heard of that, which started back in 2018 as a personal project of mine. Very long story short, we eventually spun out a browser from that project and created a nonprofit to fund it and try to build a new browser for people to use for free. and it's an entirely new browser, not a fork of Chrome or Firefox, like new browsers tend to be these days. And we have no connections or loyalties to the advertising industry, which we hope will appeal to some people. Yeah, and we're gearing up to do an alpha version sometime this year.

That's what we're currently working towards. And our, I guess, most recent piece of news was that we adopted Rust as a second language in our codebase. So we've been using C++s since the beginning because that's just what I knew when I started as running the OS. And we've been aware that we need a migration path towards a safer language for a long time. but it was just always one of those things that, you know, it was easy to put on the back burner, right? Because you have more pressing issues in the moment. But we finally have a path forward here.

And obviously people have a lot of opinions after we announced that. But I think it's the right choice. But I suppose I'm here to talk a little bit about that. Yeah, there's a million different directions we can approach this from. One thing I don't want to sort of go back a little bit. You said it's an independent browser. My understanding is there's still some libraries that are being used that also happen to be used in other browsers as well, though.

The engine itself is independent, though. Right. So the engine is independent. The JavaScript, CSS, HTML implementations are our own things. But we use third-party libraries for stuff like 2D and 3D graphics, audio. video codex, stuff like that, stuff that isn't our wheelhouse, let's say. And the boundary or like where the borderline is, it's a little unclear sometimes. We do currently share libraries with other browsers, but we maintain a fairly nice abstraction,

let's say so that if in the future we decide, hey, we want to be different. We're going to do our own version of 3D graphics or whatever. It's not terribly difficult to switch it up or something else. But, yeah, all the web technology, we strive to do ourselves. So, as I said, there's a million different ways we can approach this from. Do we jump right into the AI question? Do we start from Swift? You know what, here's where we start.

Why, Russ? Like, what was the appeal of Rust out of any of the other language you could have chosen from? Why not just stay, if you're going to move away from Swift, why not just stay C++? Right. So, in very practical terms, so, like, people talk about memory safety

as this sort of great goal to aim for by itself. and I don't disagree that it has a lot of great properties, but I think it's good to frame it in terms of really practical benefits as well, not just theoretical benefits. So one thing that I've always wanted to do with Lady Bird, which has been challenging with C++ is do more stuff in parallel. Nobody's sitting out there with a unit processor system anymore. Like everybody has multiple CPU cores,

and we've historically been terrible at taking advantage of that. Lady Bird is a very single-threaded browser, which is not great in 2026 to be single-threaded, especially given the incredibly huge workloads browsers tend to receive. So we've parallelized some things in Lady Bird, but it's always been a very uphill thing because, you know, we have accumulated a lot of single-threaded assumptions, let's say, over the last six, seven years.

And single-threadedness is just kind of deeply embedded in our codebase. And so a break with a safe language that sits sort of on the other side of a boundary where you're forced to be very intentional about what you communicate across the boundary. and like assumptions in our C++ code don't just automatically transfer over the boundary. Like everything is explicit. And so that gives us a great opportunity to finally re-architect some things in a way that allows for parallelism, let's say. And Rust or Swift or any other safe language would have been, I would say, would have been like an equally great opportunity to do this. It's just, we need some kind of safe language that gives us the confidence to program in a multi-threaded way. The C++ guys are going to argue that you can write safe.

There are subsets of C++ which are safe, right? And obviously, if you can write safe code in the language. Just, I want to play devil's advocate for the C++ people. Yes, of course. And, you know, I've been a C++. person my whole life, I suppose, or ever since I learned C++, I've loved the language. I've used it extensively for decades. And I still screw up regularly. And I don't trust myself to write multi-threaded code in C++. And I don't think I'm the best in the world at C++ by any means.

But you know, you would think that somebody with decades of experience should have some level of confidence that they can do a thing without screwing up. But I have no confidence that I can do it without screwing up when it comes to like writing production quality browser code that is meant for people to use every day, right? Right, right. So that's something that I found we've adopted Rust now. And the first thing that I did with it was just port our JavaScript compilers. to Rust. And after that was finished and we had Rust in the codebase, it took me like a couple of hours to make JavaScript parsing multi-threaded, which would have been a huge hassle before and very buggy. And now it's like the trivial almost to just put it on background threads. Parse multiple scripts in parallel. Super cool. And It felt like a great taste of something that there's a lot more opportunities like that waiting for us. But yeah, obviously, we don't, I think a lot of people here that we're starting to use Rust

and they assume that we now want to pause what we've been doing and go and rewrite everything. And that's not at all what we're doing. We're in this for the long haul, so this is a very, very long-term project. And Lady Bird is a long-term project, using Rust is a long-time project. It's going to take a long time to make more use of Rust. But we're trying to be strategic and identifying areas that are the most valuable. So JavaScript parsing felt like an important one because that's like. Like, that's where we receive code from the internet that somebody else wrote and then we have to interpret it.

Very potent area for sneaky behaviors. So it seemed like a reasonable starting point for safety for adopting a safe language. And then, yeah, there are various other points where we receive and parse data, right, CSS, HTML and so on. So we'll be focusing on areas like that. I think not just like, oh, well, we should rewrite this part in Rust because we can. That would slow us down quite a bit. Maybe we can get a little bit more basic for the people who aren't programmers. When we talk about parallelism,

why is having single-thread assumptions in the code complicated in that context? Just for anyone who might not have any programming background. Oh, sure, of course. We wrote most of our code, assuming that it runs on one core. And when you are only running on one core, you can have global state, for example, that is accessed by different parts of the program. And you never have to worry that, like, one part of the program is sort of trampling all over your global state while you're looking at it, because everything runs sequentially rather than in parallel. And so you know that if you're looking at a piece of state in the program, you're the only one looking at it right now. And that simplifies programming a great deal, and it's a much easier mental model, but it also completely fails to take advantage of modern computers, which have multiple cores.

And so C++ has multi-core, multi-processing faculties. but they rely on the programmer to do everything correctly to a large extent. And as I previously mentioned, I don't trust myself to do everything correctly. And I like it when somebody prevents me from shooting my foot with the gun, essentially. And yeah, so that's something that I really like about Rust is that it just makes it that much easier to write this kind of code because it doesn't allow you to express these bugs as easily as C++ allows you to do it, if that makes sense. You say don't trust yourself a couple of, and you're probably going to keep saying that

throughout the rest of this. That's obviously one of the, one of the core criticisms you often hear whenever the adoption of a language like Rust is brought in. It's like, oh, well, you're just using it because, you know, skill issue, whatever, whatever reason they want to use. And yeah. Yeah. Like, yeah, actually. Sure. Yeah, skill issue. I'll take that. Like, I for sure have a skill issue. Like, I can't, I don't think I can reliably write bug-free, multi-threaded code in C++. And I'm happy to admit that, because that allows me to take the next logical step, which is to use tools,

that avoid or that make it much harder for me to make those same mistakes. I don't know. Maybe this is something that probably changed as I got older. I think when I was younger, I was probably maybe a bit more, I don't know, boisterous or more confident in my ability. Yeah, exactly. But, you know, I'm too old for that shit. Like, I'm happy to admit what I'm likely to screw up. and I'm happy to take the longer, more circuitous route around the problem to avoid it.

And as you said, this isn't a short-term project. This isn't something you're just writing for yourself. This is intended to be a long-term, large-scale project. And even if you trusted yourself to write the code, you're not the only person in the team. And as the project grows, the team's going to grow as well. And you want to be out of trust that the code is being brought into the code. code base is something that is good code. Yes.

I think, so, I mean, we're probably getting to AI as a broader subject, but like one of the things that I've definitely noticed in just a recent two months or so is that suddenly everybody has a code gun that they can shoot code at you with. and it's very difficult to manage people spraying lots and lots of C++ at you, especially if you don't know them. New people show up with like a thousand lines of C++, and there's like this incredible cognitive burden imposed by, okay, so now you have to understand this and you have to try to build a picture of

like this new contributor, like what's their skill level, what's their intent? Have they thought about sort of the side effects of this code and so on? And it really feels like a safe language like Rust is something that helps alleviate some of the concerns that I have with the new world where everybody has the code gun. And it's not, it doesn't solve the whole thing. I mean, it's still crazy to have so many people come at you with so much code, but, but it helps. And I think, and not just for other people, but like, when I, if I'm using AI myself to do, like, agentic coding, so far, at least as I've been using it, I'm definitely noticing the AI is happy to create some of the

classic C++ bugs, right? It'll make exactly the same kind of bugs that I've made a million times, you know, like you use memory after freeing it or forget to check a null pointer. It's like a child that watches their parents smoke and grows up to be a smoker. I feel like AI is trained on our code, so what are we expecting from it really? Right, right. Actually, I like metaphor. That's a good one. So, right? So, yeah. Safe language. Safe language helps a lot with, like, recovering, or covering up some of the sort of confidence gap that you have with new contributors, because you have some, you can

have some confidence that the code is not necessarily 100% correct. Right. And still have logic errors, sure. Yeah. You can still have logic errors, but, but some types of bugs are, much harder to create in Rust. And yeah, it's nice to not have to sweat about those bugs. So, right now the project is a dual-language code base. Is that the long-term plan, or is the plan to eventually migrate everything over to Rust? I don't know, to be honest.

It seems to me that on a long enough time horizon, maybe we would migrate. everything, but maybe that horizon is so far out that by the time we get there, there's an even better language. And there's also an AI agent that rewrites your C++ and Rust codebase to that new language in five minutes. So I don't know. But we try to take a very incremental approach to everything that we do. Starting over, starting from scratch is not interesting to us. full rewrites not interesting to us either so for the time being

it's a dual language project and I mean I say dual language but like we also have lots of Python and we have like I don't know probably million lines of JavaScript and tests and stuff like that sure sure sure

I don't know how many lines but there's a lot of there'll be a million eventually if there's not yeah exactly So, yeah, it'll be dual language in a compiled languages realm for a long time. But the ratio will skew over time, I imagine. You would want to move further towards the Rust side then.

Right. So if we're taking on like a new project to write some new component, we'll probably try to do that in Rust. and for the existing code, we'll try to identify high-value areas to migrate, where the value comes from some combination of safety and parallelism, basically. As it currently stands, what aspects of the code base are in Rust, and what are some of those sort of high-value areas? So right now, the JavaScript parser and bytecode compiler

are in Rust. So it's about like 25,000 lines in total, I think it was. And the rest of it is C++. Okay. What are some of those high-value areas that you would want to transfer over? Oh, other areas? Yeah. Yeah.

Yeah. So stuff like CSS parsing, HTML parsing, probably like, image and video codec stuff, maybe like GPU interaction, but also like mundane stuff, like converting from UTF8 to UTF 16 and stuff like that, that we currently do all over the place. Maybe there are ways to move that over to Rust. I don't know. But, yeah, I'm coming at it with a very simple framework, which is, would this thing benefit from safety?

Like, is this a high-risk area where we're handling untrusted data from the web? And is this like a serial implementation of something embarrassingly parallel? Like something that would be trivial to parallelize and would greatly benefit from running on all your course instead of one? those are the two key things very minor side tangent I did see that you spotted the x86 CSS emulator and you had some comments on that

for anyone who's unaware there is a crazy person who has just write some crazy CSS projects they made like a cookie clicker clone in CSS as well I also decided to make a x86 emulator

a ex86 emulator in CSS because why the joys of building a browser I guess

yeah I mean I love that I love that people do those kind of project because they kind of highlight the absurdity of the web platform

a little bit and what it has become but it's an impressive technical feat. I think and it's always nice to see that, like this old school hacker creativity kind of stuff.

I think I would like to see Doom running on that thing. I feel like that would be the ultimate hack project, but I don't know how far away that is. It's probably not fast enough for that right now. It is. But I suppose that's my problem.

Yeah. I don't know if it's ever going to be fast. to be honest. So, the big topic I didn't want to touch on as well was Swift. Whiff was like the big, hey, we're moving to Swift.

This was going to be the language that was in the place of Rust. This was going to solve the problems that Rust is now solving for you. So what happened with Swift was the, I don't know, I have no knowledge at all here.

Yeah, so So I guess the story is that it kind of didn't happen. So we set out to adopt Swift as a second language in our codebase after being impressed with just trying the language out, writing various little projects in it, myself and a bunch of people on the team, just doodling. And we thought, hey, this is really nice. And the Swift team had this big focus on like C++,

interoperability. So they wanted to make it very, very pleasant to interact between the two languages. And I think if I'm honest, I think a lot of what happened here is that I built up an idea in my mind of how freaking smooth the interop was going to be and that these things were just going to sit there seamlessly side by side and you wouldn't have to do any kind of build system hacks or anything. And like, it wasn't anybody like selling me this. It was like me building this idea up for myself, I think.

And then when it didn't materialize in that way, and it was, it turned into like this endless doodling with build systems and like integration code and like trying to get the languages to talk to each other. It's just, we just never made any substantial progress on it. And it became this thing that nobody wanted to touch because it was just, you could make such a much bigger contribution to the project by actually improving our web standard support, for example. So it's like, why would you spend a week battling the Swift Build system when you could implement a CSS feature? Right, right.

And, yeah, but we attempted. a bunch of things. And we had some very positive interactions with the SWIFT team. They helped us out with a bunch of stuff. But I think ultimately, it just kind of never took off. It never gained that

excitement and energy behind it that you need for something to actually happen, especially in a project like ours, which is like a lot of people working on it are very driven by like wanting to build a browser and they're kind of motivated by hey, I want to make this website work.

They don't want to sit and screw around with this. So we were a little bit going nowhere with it for a long time. And I think the idea behind Swift is great still. And I hope that they achieve everything they want with C++ interop because I think it will be a great language for that one day. and a lot of code bases are going to benefit from having that. But for us, we need to be making tangible progress towards what we actually care about, which is building our browser.

And Rust is, let's say, it's a very mature solution to this. And it works on all the platforms we care about. It has a great ecosystem full of cool stuff. And I think it got to a point where we just needed to make sort of a pragmatic choice rather than an idealistic choice about the future. And when we were looking at languages originally, Swift was one of them that we ended up sort of choosing. And Rust was the second one, which we also tried out a bunch. but people found it a little bit frustrating.

I actually was going to direct you in that. Directly it will live that. Keep going. That's going to be my next follow-up. Yeah. So it was frustrating to work with. And I had that experience as well. I also found it frustrating. But now, I think in the last six months or so,

especially, like programming has changed a lot. At least it has if, if you've been actively, using AI in programming. So suddenly you have like this tireless tutor that can help you with anything, teach you anything, walk you through anything. And if you get stuck on something, he'll bang his head against it for you. And having that suddenly made dealing with those frustrations like much, much easier because

you could then, instead of having to like sit and dig through the manuals or Google on stack overflow and whatever, you know, all the usual things that people say about LLM as programming assistants. They all work in the favor of like Rust is actually now suddenly a kind of nice candidate because it actually has all the properties that we want. And the annoyances are much easier to deal with. Right. With our AI assistant friends. And one thing, by the way, that I'm kind of. kind of forgetting to talk about here.

So our browser is garbage collected because the web platform is garbage collected. JavaScript is garbage collected, so you have to have a garbage collector. Swift didn't have a garbage collector. Rust doesn't have a garbage collector either. Sure would have been nice if they did, but they don't. And we accept this as a sort of downside. Like, we can't have everything we want, but I think that's okay. If that is a require...

I've never built a browser myself. It's not something I've ever thought of doing. If the web is garbage collected, how do you deal with that problem with Rust? Do you implement your own garbage collector, or what do you do here? So, right now, we have our own garbage collector in C++. And the Rust code doesn't directly interact. with it. So if we need to allocate some garbage

collected memory from Rust, then we just call into C++. And that's kind of how that probably is going to work for the foreseeable future. Rust there are some garbage collectors

in Rust, but it's not necessarily an area where we feel like, oh, that's where we should go in and try to innovate. But we're pretty okay with maintaining our own C++ garbage collector for now. You talked a couple of times about Swift and C++ Interop and how this was going to be so nice.

What is the experience like they're working with Rust? So the thing that is different now is that we kind of lowered our expectations for Interop and instead... That's a good way to solve the problem. Yes. I think it turns out to be a really good way to solve the problem. because as I was saying, like I had unreasonable expectations that I created for myself.

And then I kind of try to sell them to everybody else. But now we use interop very, very super basic interrupt. Like we're just using a C interface basically. So we're not doing any kind of C++ object marshalling or serialization or anything like that. Anything fancy. We're not using any of the C++. bindings crates from Rust. We are just defining simple C API and then calling across the language boundary. And for now, that solves all of the stuff that we want to do. In the future,

you know, as we use Rust in more places, it might turn out, hey, this would be really nice to bring in one of these C++ bindings crates or whatever. There's a couple of those. But for the time being, like just having a simple C-function interface seems to do the trick for us. And I think, I guess the way I would like to frame this is that a lowering of expectations that were unreasonable to begin with and just like trying to make the most pragmatic decision that gives us real benefits. And then, of course, if we look around at the rest of the industry around us, everybody's kind of finding the same thing, just taking different paths to get there.

But, you know, Firefox obviously uses lots of Rust. That's where it even originated. So that makes sense. But Chromium has started using Rust as well in their codebase. And lots of projects are. I think Linux started using it as well, right? It was already in Android before it entered the Linux code as well. Okay, yeah.

Yeah, I mean, we see where the winds are blowing. And I think some people, when I first announced the Rust thing, then some people were saying, like, oh, you're just buying into the hype of Rust. Like, I think at this point, is it really hype? If this had been like six years ago, maybe, I don't know. I was in university when the Rust, maybe like just after Rust beta, something like that, people were hyping Rust as like the future of everything back then. That was the, it was new, exciting, wow, Rust is going to change everything.

It's not really, like, yeah, you can call it hype, but it's at the point where it has industry adoption. I think, I think we're well past that point. Like, you can have a career as a Ross developer. I think, if you want to talk about hype, go hang out with the Zig developers. They'll talk to you about hype. Sure, yeah. No shame to the Zigg people. Pretty accurate.

But, like, Rust is at this point a very mature language. Exactly. And it also feels like you mentioned Zieg. I do feel like the same type of person who would previously talk your ear off about Rust is now the type of person who talks your ear off about Zieg, right? So the energy is still there. It's just moved to another language. And there's probably always, like at any point in time,

there's like a language that is the current hype language. Yeah. But yeah, as you say, the industry has clearly spoken. This is like an accepted good solution to a bunch of these problems. And that's where things are headed. At this point, it's a little bit silly to try to pretend that it's this hype thing that's going away or something like that. Yeah, but I will say it is nice that these hype beasts have disappeared from Rust or calm down. Because it was very difficult to talk about.

Even two years ago when we were talking about Swift, it was still difficult to have that kind of conversation in public because some people are so extremely enthusiastic, let's say, about their favorite languages. Yes. They just feel really strongly that their favorite language is really good and that everybody should use it. No, I definitely have noticed a sort of like a,

bit of a I guess mellowing out of that and I guess now that now that the people who were hyping it up sort of they were proven right

right you know it has that industry adoption it is serving a purpose there's no reason to sort of keep putting that excitement behind it because people are kind of realizing hey there actually

a Samarit here now this language could have been you know if you know if again going back to Zieg if Zip was five years earlier. It very well could have been

that language instead. It's just Rust was at the right time and the right place. It filled a role that a lot of projects really wanted to fill. But... Yeah. Yeah, I...

I have definitely noticed that myself... There's sort of like a different thing now where there's like the anti-Rust sort of hype where it's like I don't want anything to do with Rust. And I know that when you announce this there was some of that as well

where it's like how could you possibly use Russ? Because I think there was this idea, especially from early interviews you'd done, that you were this crusader against Rust. So I've watched the interviews. That's not at all what you sounded like. But it is kind of,

a lot of clips you speak and you at Rust were often shared around amongst that crowd. So when you were like, oh, we're now going to use Rust, I guess some people felt like this was a betrayal, I guess, a sudden change. I don't know. But the way I understand, and correct me if I'm wrong, you've always kind of just looked at the language you're using as a tool, right?

And you're going to use whatever the best tool for the job is. It could have been, you know, in another world, it could have been objective C. Who knows? Yeah, I'd say that's, I mean, I'm a human being. Right. That would have been. Nice, actually. I mean, I'm a human being, so I obviously sometimes have personal biases and I make silly

mistakes or I get too excited about something. But I try to work in the way that you describe where languages are tools and whatever tool is best is the one that we should try to use. And then there's a tremendous cost to switching tools that just keeps going to. growing as you invest more and more in those tools. At least that was the sort of the calculus for the like history of programming until very recently, where we have started getting these tools that can do language translations for us to a pretty, pretty satisfying degree, in my opinion. And that changes a lot of the assumptions that we have been

tie to for a long time. But yeah, I mean, languages are tools. Same thing with like text editors and IDs or whatever. Like everything is just a tool. And I see recently on social media, there's a lot of debating around, like people feel like they're losing their identity as programmers because of these clankers that come and program for you. And I don't find that.

that's so easy to relate to because I've never really identified with like the act of typing the code myself. That wasn't necessarily what it was about for me, but it was about like making something happen with the computer. And now we have new ways of doing that and I want to master those things. So yeah, it's just more tools, I guess. And I'm not married to the new tools. either. If somebody comes up with an even better tool tomorrow, then I'll be happy to mess with that. If I look back, though, I think it's fair to say that I probably allowed some of the hype around Rust to keep me away from it longer than I should have. It probably did become a factor that the community was a bit overly enthusiastic, let's say.

they were not really helping with getting people to adopt, even though I suppose that's what they were hoping to do. But ultimately, like, I'm the one who has to look back and say, like, this would have been nice to do two years ago. So, yeah, unfortunate, but we have to make progress where we are. So the pragmatic choice is to adopt the language that the industry is moving towards and gives us a bunch of things that we want and lets us build towards a better future with a better browser.

Yeah. And like you say, like a lot of people are reflexively anti-Rust and I think those people are now disappointed. feel like there's a grand betrayal. But I'm not super concerned about that. I don't think that matters. I think what matters is that we build the best browser that we can build so that people have another browser to choose from. And we believe that we can do a better job with better tools.

And we're basing our decisions on that, basically. Fair enough. I do want to move to the AI question just a moment. I want to touch on the two things about Rust before we move on. Firstly, platform support. So what platforms are supported by the browser? Because this... Russ... Oh my God.

Every time I bring up Rust, Rust Platform Support always comes up as a topic. I'm so sick of talking about it. What platforms have been to be supported by the browser? Well, so far, we have officially committed to MacOS and Linux. But we also have a community effort to... support Windows, and we have continuous testing on Windows. So Windows will happen. It's just that we can't spread ourselves too thin with commitments at the stage. So yeah, it's the major trio, basically, like Linux, MacOS, and Windows are going to be the main systems in the future. And then I guess

what you're getting at is that then somebody's going to come up. up and be like, hey, what about... What about my sparks server some nonsense? Yeah, what about my alpha station? Come on. And I get it in the conversation about the Linux kernel. But that's just not a relevant discussion here. Right.

Yeah. I mean, we are building a browser for the contemporary web, which kind of pre-supporting a browser. kind of presupposes that you have a reasonably modern computer. Something the last 30 years is generally good plan, yeah. Yeah, I would even say something from the last 10 years, ideally. And I kind of think of it as one of the luxuries that we have, is that we know that our browser doesn't have to come out today. and we don't have like a public 1.0 or whatever for another two years.

And so we can sort of try to build for the computer that people will have then and not worry so much about people with their 2005 computers. Who we do hear from? They are also very enthusiastic about their, you know, Pentium-Fours or whatever they have. And it is unfortunate that we can't support every PC that ever existed, but I don't think that that's the right investment for us to worry about that. And also, yeah, I also want to mention people are going to, if I don't mention people are going to bring it up, Russ compile time, Russ compile time.

Is the browser going to take forever to compile now? Is this ruined all development effort? So far it has added, I think, four or five seconds or something like that. So at least on my machine, I'm not super worried about it. But our C++ codebase was already a big, thick monster to compile. So that's just the nature of browsers, I think. How big is the browser at this point? How many lines ago, do you reckon?

It's about half a million lines. Yeah. Something like that. And you know where they're done, so... Yeah, indeed. I mean, it'll never be done. Do you have like a sort of estimation? Maybe it's hard to make that estimation, like, how big 1.0 would be, like how many lines of code the project would be at that point?

I would love it if we can stay under a mill. But it's unclear to me at this stage how that will work out. And it also depends a little bit on how you count. So there are some APIs that are just gigantic, like the WebGL stuff, WebRTC, those kind of things. Do you want to count those lines of code, even though it's like all very, very repetitive boilerplate stuff? But we're hoping to stay at a – I hope that we can stay at a scale that's like a tenth of the size of any of the other browsers. that would make me happy if we can prove that you can build a usable browser in like a tiny fraction of the size. It is crazy that a million lines of code is still getting to the tiny fractions, how big browsers are at this point.

Yes, well, without that, how are you going to get X-86 emulators in CSS? That's true. You make a solid argument. Exactly. Yeah. Speaking of solid arguments and arguing, I don't know how to segue. First controversy was Russ. The second controversy was doing this with AI.

So, when, I guess, where do we start from here? Like, where do you want to go from here? Because you did the porting with AI and, do we now have a vibe-coded browser? Is everything ruined? Is this just security night? It may impossible to use. Where are we? I guess that's a... I don't know. It depends on where you draw the line for vibe coding, I suppose.

I've been using AI to assist in programming since 2022, I think. I'm going pretty early on. Yeah. Like a GitHub co-pilot I got when that was relatively newish. And, you know, before that, I was using chaty BT for stuff. So myself and many people on the team have been like fairly aggressive users of AI to help out in programming for many years already. So this was not like suddenly we'd decide to use AI. Right, right. You've been using it for years.

So you kind of knew the capabilities it already had? Yes, exactly. And didn't have until just recently when they, I would say they made a very seriously poop. in capabilities over the last three months or so. And, yeah, obviously some people feel strongly about this. And it's funny, like, when we announced this, when I announced this Rust JavaScript thing, then like, either people either got mad about the Rust thing

or they got mad about the AI, but like everybody found something to be mad about. Yeah, that was fun. I enjoyed that. Yeah, I enjoy that too. It's funny when you find something that makes everyone upset. But anyway, so it wasn't like a new thing to anybody on the team. Like we've already been using AI, most of us, in various capacities for a long time. But this was the biggest project where we sort of, I guess I felt like it would be silly to say,

I did this in two weeks. Whereas if I've been using it to assist me, then it was still me doing it, I felt like. But here, it seemed important to call out, no, no, it wasn't just me. I had help here. And I think it also felt important to talk about it because I want people to understand

that these tools are becoming more capable and they can now assist with these kind of stuff. And that it changes the assumptions that we've had for a long time about the cost and feasibility of language translations. Because, you know, as we talked about, like, we wanted to do a translation to Swift of parts of the codebase. And that always, in my mind, and I guess in everyone's mind, just seemed like this gigantic undertaking that would cost us, you know, weeks or months of time to do various little things once we got that going. Whereas this rust port of our JavaScript pipeline was like something I could do while working on other stuff, like just doing it in the background sort of over the course of two weeks,

which was, I don't know, amazing to me that this is possible. But I think people, I've noticed with people who are upset about this kind of thing that many of them have, let's say, an outdated mental model of what AI-assisted programming is like. People who have, you know, tried asking chat GPT to generate a game, or they tried this like auto-complete AI that were popular some years ago. And I think it's, it would be very healthy for a lot of people to go and play with these agentic coding things a little bit and try to make some silly little apps or something, make a little I don't know, Space Invaders game, like just to doodle around and build intuition about what this

is and what it can do because it's like, I keep having this conversation with people that it's a little bit tiresome where they just, it becomes clear that they haven't tried this stuff for themselves. And they're just kind of regurgitating the same thing you've heard a million times. Sure, sure, sure, sure. Yeah. I think there's all sort of distinction

with what you're trying to get out of programming, right? If you're the kind of, like, what's a good sort of metaphor? Like, I guess building, actually here's a good one,

building a table, a chair, using hair, only hand tools as opposed to using like electrolyte sores and drills and other things. It's going to be considerably easy to do it if you use a bandsaw to cut the wood rather than actually cutting it with a hand saw, right? But both of these are approaches to doing the same thing. And in the same way with AI and programming here, sorry, it's 1am here,

it's 1.30 a.m. If I jump around a little bit, that's going to be why. When we're talking about programming, a lot of people enjoy purely the act of programming, this sort of... For some people, it's this artistic experience, not just an engineering experience, right? I think that's where I'm trying to get at. Yeah, and I can relate to that a little bit. Like, I mean, I've been doing this my whole life since I was a kid. some of my earliest memories is like typing basic programs into IBM or Toshiba laptop in the late 80s.

And it was enjoyable and it remains enjoyable to me to do these things. But it also feels a bit like ultimately carpentry like what you talk about became an artisanal craft. It sort of, there was a, at some point it bifurcated or whatever you say, like into like artisanal carpentry and, you know, an IKEA table. Furniture production, let's say. Yeah, exactly. Yeah, yeah, yeah. And when the artisanal craft, crafted thing is like visibly better than I think, then there's a clear argument for that. And I think AI-assisted programming has been like kind of obviously worse up until now.

And I feel that the quality gap between what I would produce, at least, if I'm honest about my own abilities and my own sort of tendency for programming quality, the gap between what I would produce and what an agent can produce has shrunk to the point. point where I really feel like I can be more efficient at what I want to achieve by directing the agent and then going over the stuff it produces and cleaning that up and so on. And it brings me towards my goals sooner and then I get to do my other goals sooner, which is more fun for me. But if my goal would be to sit and type the keys and watch the program appear character by character, I'd probably be sad about that, yeah. But I'm trying to build a browser. So, so, yeah, I guess it's probably a very different experience depending on, as you say,

sort of what your goals are, what you're trying to get out of programming. Yeah. So what was the, I guess, process you took to actually do this porting? And if you're willing to say, how much did it cost? Oh, sure, yeah. So I think I used Claude and Codex. So the OpenAI and the Anthropic offerings and I have like these

maxed out accounts. So it cost less than $500, I think, because it took about two weeks. And yeah. And the process was to basically make a little plan that we're going to try to port just started with a little part,

started with just Alexa, which would like a loop over the JavaScript source code and create tokens. So like this is a slash, this is a string, this is a number, whatever. So I just did that first and then plug that into the existing C++ things. And then once that just worked,

then I thought, hey, okay, well, what if the next step in the pipeline would also be Rust? And then I made a parser. So the Lexer creates tokens, goes into the parser. Parcer turns them into an abstract syntax tree. And that was initially C++. And then I thought, okay, well, this works now. I can create the C++ syntax tree.

Why don't I port the syntax tree to Rust? And then it's sort of just iteratively going through the pipeline like that, porting one piece at a time, having it seamlessly integrate with the, existing code. And that's kind of how I built the whole thing until I reached the end of the pipeline, which is where we generate the code that eventually gets executed by our virtual machine. And then the virtual machine remains in C++. But all the way from from JavaScript source code to bytecode programs is now in Rust. And it was an incremental process

like that. And I just kept adding more and more tests along the way as I discovered things that were sort of not covered by our tests. And I had some, I mean, I think there were probably like more than a thousand prompts that went into this. So it wasn't like one big master prompt that. Yeah, it's just like, convert everything. Pork. Make no mistakes, right? Yeah. Right good code. Make no mistakes. Yeah, yeah, okay. Exactly. No, so it was a continuous like feedback loop type of process where I was just monitoring and babysitting. And I think that's still required.

There are these people who hype up these tools and they say, oh, you can just like give it some good instruction and then come back in a week and it will do great things. Right. there was the who was it Google that did the let the agentic system go and just

build a browser who was that did that recently oh I think that was cursor the cursor might be cursor yeah

um right so they and that thing banged out you know like I don't know two million lines of code or something

um for the record just so we clearly that code didn't actually compile oh they had to make some change yeah maybe they didn't compile

and it made heavy use of like servo, I think, like the browser engine. But you know, for some definition of browser, it was one, I suppose. Once it compiled, it was close to a browser. Yeah. And my feeling about all of those sort of showcases is that they're just kind of, I don't know, barking up the wrong tree a little bit with. unsupervised agentic programming. I think that's not where I'm interested in going. I don't want to, you know, tell my agent to do something and then leave it alone. I like to be part of the process

because as we talked about earlier, like I love programming. I enjoy it. I just, I also enjoy doing it in a different way where I don't have to be like caring about every little detail, like every little piece of punctuation, remembering every semicolon, that kind of stuff. But just getting hoisted up the abstraction stack, I don't know if I would say one level, I feel like we've been hoisted multiple levels here in one go, and it's a little jarring, a little shell-shocked perhaps, but even so, I still very much enjoy it. And I think the results that you get from supervised agentic programming are night and day with this, I suppose, what is fundamentally slop that you get if you just ask it to do something

and leave it to its own devices. So there was also a C compiler. I think somebody did. I forget who that was. Was that anthropic maybe? But yeah. Yes. What I would love to see is, like, what happens if they just put this thing in the hands of an expert

and have the expert guided to do something actively, sort of. And I think I am not an expert at many things, but I feel like I'm an expert at our JavaScript engine, at least, because I wrote much of it. So in this case, I had a very good experience sort of being the expert guiding the agent to do this translation to Rust. And the quality metrics that we have, had or that I had to work with were very, very helpful. So we have a ton of tests. There's an

official JavaScript correctness test suite that the working group that makes the language, they also maintain a test suite for the language. It has like 50,000 plus tests. And that we have our own tests as well that we've accumulated over the years of billing Ladybird, like another, I don't know, 10,000 plus tests. And so, It was very easy to validate that this thing has a reasonable chance of being correct by throwing all of these tests at it every step of the way. And then I also built this mode where it runs both the C++ compiler and the Rust compiler and then compares the results. and then if there's any difference in the result it will just stop and say hey wait a minute

the Rust version does not do exactly what the C++ version did and then I had to make it do exactly the same thing so a bunch of one criticism that you might hear for a project like this is that what you're just overfitting on the tests that you have right? Right yeah I've heard of it's like oh AI's in some cases will have hard code stuff or do things in a way that the test will pass but is that actually is that generally

applicable or is it applicable to the test yeah so i think in our case um we have enough tests that that strategy becomes um like not viable for the ai to to get out of having to implement stuff because everything is tested from like multiple angles and stuff. So if you were to hard code something, there's another test that will catch you. And then we also have this beautiful thing called the World Wide Web, where we can just go and people will throw just insane amounts of JavaScript at you and say, hey, this is an ad for something.

Or maybe it's a tracking cookie. I just want to know what you are doing. So I can send you an ad later. that's about two megabytes of JavaScript, whatever. Please run. And browsers do this all the time, and it was very easy to test the correctness of this thing by just running all that stuff,

all that lovely JavaScript, and verifying that it's identical between the C++ and Rust versions. So that gave me a huge amount of confidence that it's correct because the results were identical. Right. If it operates in real-world cases, then clearly there's something here. Right. Besides the bugs that were already there.

Of course, yes. But we end up with something that's like bug-for-bug compatible, let's say. Which is ultimately what was the right thing to aim for, I think, because at least it's something that we can prove. and so it's possible that there are still regressions in there but it's been a long time since I found any now

a long time I say but it's been several days since I found one but it's just a couple of days old so now obviously when you do a translation

like this you end up with something that doesn't look like Rust written from scratch right I did hear a lot of, oh, what was the point of doing this if you're not going to write the idiomatic

russ? Exactly. But I think that would have been unavoidable if a human did it without machine tools as well. You're taking a program and rewriting it in a new language. I think the sort of disciplined, the engineering approach to that is to stay true to the original version in the first pass so that you can compare them more easily. And then over time, as you continue working on it, it will sort of evolve into idiomatic rust. But right now, there are a bunch of things that we do in the Rust version that are silly, but we do them so that we match exactly the behavior of the C++ version. We have, for example, like a lot manual drop where C++ would have run a destructor.

But eventually we will no longer care about maintaining the C++ version. We can remove it and then we can clean up a lot of the silliness. And that day will come. But as far as like idiomatic versus non-idiomatic, I think the correct choice was to make it less than idiomatic so that we could have both things coexist and get all the value out of being able to compare them and contrast. You want to make it first and then make it good later, basically. That's sort of where you're going.

Yeah, exactly. This project is going to take forever. Building a browser will take forever. And by the time we had finished, then the CSS working group has invented new types of gradients and colors and somebody made a fricking PS5 emulator that uses the new properties and yeah, you know,

there's always going to be something to do. And so trying to make it perfect would have prevented it from happening, I think. And this allows us to make progress right now. And we already have the tangible benefit of now our JavaScript parsing is multi-threaded.

So we can parse, you know, very many websites have multiple JavaScripts on them. Now we can parse multiple at the same time. We don't have to do them serially. That's a great benefit. It makes us load pages faster. So the benefits are already like super obvious, which is nice. If you're loading some, I don't know, some big website like a YouTube, for example, Like, what sort of performance difference are you looking at here?

In terms of, like, loading speed? Yeah. Probably, like, shaving off a couple hundred milliseconds on the load. So it's not earth-shattering, but there's so many things that we have to do when we load websites. And there's very much, like, this death-by-a-thousand-thousand-thousand-thing happening where you have all these little inefficiencies and things that you have to do. And this has always been like a big chunk of them. And I think just as some example, like if you go to X and you load your home feed on X,

it takes us about a second and a half to parse all the JavaScript that they throw at us. But now, if we can do it in parallel, it takes maybe like half a second. So we save one second. And I think it's one of many things that we do when loading X, but one second less until you see the finished page. That's a big win in my book. Now we just have to do all the other things to get rid of all the other seconds. Yeah.

Well, that's where the CSS comes in and HTML loves all the fun stuff. Of course. And a lot of it is, it's like a little bit, it feels like a very tall mountain sometimes to be trying to build a browser for a web that the other browsers have spent like 30 years building their engines and optimizing them. And web developers got so used to having these like super optimized browsers. So they got real comfortable just throwing so much at the browser. It's not just web developers.

It's developers across everything. Game developers have this issue. You have this issue with just regular application developers. Right? Even just basic things. Taking for granted the fact that most people have an SSD, you can do really stupid things with caching files if everyone has an SSD.

Yeah. That's true. Yeah. I guess it's the broader thing. that everybody just rushes to take advantage of all the speed benefits and the net speed of everything stays neutral or actually gets worse over time. Yeah, a common thing over here will say is like software engineers have managed to optimize out all of the hardware gains over the past 30 years.

I believe it. And, you know, we are in a very serious catch-up position here. We're missing so many of the all the optimizations that other browsers have and you can take for granted should exist. So right now, we're just like trying to identify the most valuable things that would give us the biggest bang for buck in terms of like time investment, complexity investment and so on. And this one, so parallelizing JavaScript parsing, I would have, like, if you asked me six months ago, like, can we do that in parallel? I would have said, in theory, but like, it's so risky because everything, like, it has all these single-threaded assumptions that I don't want to deal with. And it's like, I don't know. It wouldn't have seemed worth it.

But now that we're using Rust and we can have some confidence that it doesn't have data races and things like that that would cause problems. multi-threaded context, suddenly it's super easy. And we can just do that. We can shave that second off of Twitter load time and so many other sites. So that's very cool. So sort of going back to the AI development stuff, before we start recording, you were like, I don't want to sort of like hype this up. Like, what is the experience like right now? what is the

I guess workflow like and how good is the code it's producing because as you said a lot of people have this idea sort of set sort of two or three years ago

and the exact same thing exists in the art community as well people have no idea what modern AI art looks like and people are getting completely tricked by it right yeah So I would say AI now, it's like having a fairly competent intern.

Like you're working in an office as a programmer and then your boss comes and says, hey, you're going to get an intern. And if you've ever worked in an office and you've been assigned an intern, you're familiar with the emotional roller coaster that this can be, because you don't know what kind of intern you're getting. But when you get a good intern, it's really awesome because it's somebody who's like eager and weirdly tireless and just kind of like interested in everything

and they just want to do stuff. That's a great intern. And I really feel like AI agents now are like good interns. And even better than real interns because AI agents don't get tired. they will bang their head against the most mundane bullshit task you give them and smile the whole time which can be very useful but

they also make dumb mistakes sometimes they can trick themselves into sort of thought loops and there's this horrible thing called context compaction which they all do which is when the conversation gets too long, then it has to sort of compact

it, so it just summarizes the conversation you've had thus far and then like starts over with summary at the top and that tends to lose a lot of detail in what you've been talking about. It can be very frustrating. But

a human being doesn't remember everything that you've talked about either. So, I don't know, I feel that there's a lot of parallels to some of the best interns that I've had. And it seems to me that this thing is not going to get any worse than this. It's just going to keep improving. This is like the worst it's going to be from now on. So I don't know. I find it exciting. I've always had these big ambitions to build big things. And I've been held back by my ability to produce the code. And by and I've been held back by, and

I had some breakthroughs in my life where I was able to get other people excited to work on the same project with me. And that felt like, wow, I'm really scaling what I want to do with this thing because I'm getting other people excited to work on it together. But this gives me a different way to do that again to increase the amount of work that goes into a project that I want to build. But yeah, so centering on AI and their capabilities, I think they are at the point where they are very, very useful if you put in the time to build intuition about what they can do, what kind of flaws they have, what they're bad at, especially, and how to steer them away from bad habits,

from getting into stupid loops or convincing themselves to spend a bunch of time on something that's going to be fruitless. But I think the big mistake that people are making is that they don't see that in order to build all this intuition, you have to play with it.

You have to go back to that person you were when you discovered programming, When you first made it say hello world or like, you know, 10 print fart, 20, go to 10 or whatever, when that kind of thing made you excited and come into it with that kind of energy, like, okay, what can I make this thing do? So just as an example, like something that I build just to understand it better was like this food logging app where I can log the food that I eat throughout the day. Because I've been using those kind of things for years, and they always make you, like, type in what you ate. And I thought, it would be nice if I could just say what I ate. And so I just sort of vibe-coded a mobile app that lets me say what I ate, and then it uses voice to text to figure out what I mean and then logs the calories and everything.

And PurePlay, like, no intention of trying to sell this to anybody or share. even shared with somebody. And that exercise taught me so much about, like, what can this thing do? What does it suck at? And I think everyone who hasn't gone through the exercise is just, like, spending a weekend building a dumb app, I strongly recommend spending a weekend building a dumb app. because if you can set aside your sort of prejudices about AI, what it is or what it should be or whatever, we're doomed,

we're not doomed, this is the future, whatever. All assumptions, just set them aside and just like mess around with it and play and like do something fun. Like maybe you always wanted to build a game. Like so many people got into programming because they wanted to make a game. and then they end up writing like crud web apps instead. And you totally forgot about that game you wanted to make. Like spend a weekend building that game.

Like the rate of progress you can make on something like that now is crazy. So yeah, anyway, that's my pitch. Just play with it. No, I think that's a, I think it's good. If you're going to be critical or something, I think you need to know the current state of things. That's not just the case with AI. That's the case with everything.

A lot of people tend to be, they tend to be, whether it be Rust or, you know, you want to talk about Wayland on Linux or any of these things. A lot of people don't necessarily know the current state of it. Or like, you know, Invidio drivers on Linux as well. It's another good example. I think it's important to know,

especially if you don't like something what it currently is capable of, what it is currently like, because otherwise, well, you're hating something that doesn't exist, you're hating a phantom, and there's nothing,

like, there's nothing productive there, right? You're just making yourself angry over something that's not even real at that point. Right, and you're not convincing anybody when you come from that kind of place. And it's so easy to go and test, right?

Right. And I will say I make this mistake sometimes, too. Just the other day, I caught myself talking shit about KDE, even though I haven't used KDE for like 20 years. I was like, God, they have too many settings for everything. In KDE. I don't know. I haven't used KD like an hour ago. Yeah, they kind of, look, they do.

Okay, okay, maybe it's still like that. I like KD. I like Haiti. But like I get it. I understand that sort of criticism. But anyway, go. I'm sorry. No, point being, though, like, I think we all make mistakes and we can be silly about things like this. But it's good to catch yourself, you know, and say like, oh, wait a minute. I don't know. I have these assumptions about this, but they're probably kind of outdated. I should update them. I should refresh them. Right, right. And I think if we are being intellectually honest, we can see where the industry is heading and we can see what is happening to the profession once known as computer programmer. Because whatever we would like it to be, the people who pay us to work on. code are going to make their calculations and they're going to make their decisions

based on new assumptions that are being updated and yeah things are changing and I don't make a value judgment on like is it for the better is it for the worse it's like everybody has their own sort of perspectives on that but I think we have to accept that they are changing and staying informed and aware of what the state of the art is is the bare minimum I think that we need to be

aiming for yeah I did want to sort of talk a bit about industry implications there because you said it's it's kind of like a good intern and if I'm a corporate manager what I hear there is why do I need the interns I can just give the senior developers these tools

and then I don't have to deal with the interns. And that's fine if one company does it. But if that becomes an industry trend, how do you then train up your new junior developers to become those seniors? And where does that go, right? Yeah, I wish I knew. Assuming things stay exactly where they are

and it doesn't improve anymore. Right. I don't know. it's a very interesting question. I've heard from people who work at various companies and they are basically having exactly this thought process that you just described. And I think we're definitely going to be seeing

a lot of quote-unquote AI layoffs in the future as companies, middle managers realize exactly what you describe. what do we do to train the next generation of programmers? I don't know. That's a little bit scary, a little bit sad. It feels like the bar for entry just got yoinked up along with our own abstraction level that we get to work at. But at the same time, you look at other fields. So I have like siblings who are doctors. And they spent some... many years in school to learn this.

Maybe that's what ends up happening to programming, is that you just have to spend a ton more time learning it and learning all kinds of fundamentals and studying them in new ways. I don't know. Or maybe it becomes like a thing where you just start using these tools very early in life and build intuition about how to use them. And maybe the kids will, kids who pick up AI programming today will like completely dominate in a couple of years.

And without any kind of formal training, I don't know. I know people who work in education and every, all their students are like using AI to some extent. And I don't know. Like if you're, let's say that you're just entering school, you're five, six years old. What are things going to be? like in 13 years when you're

graduating as like out of high school, right? No one really knows the like where... We can sort of like make these ideas but nobody four years ago would have thought we'd be where we're at now and

I don't, like, do things slow down? Possibly. Do they like do we hit a point where these tools become like maybe low level or competent senior developers. I don't know.

I don't know. I think it's sort of a disservice to a suit. I've seen this sort of floating around. Like, AI's never going to be at, it's always like a goalpost. It's never going to hit this point. It's never going to hit this point. And then it keeps hitting these points.

I don't think it is a good assumption to make that we are never going to cross any further arbitrary threshold. I think it is the, the safe assumption if you are critical to this tech is assume that your worst possible fears are going to happen or if you're a corporate manager your best possible dreams depending where you're coming from from and that's sort of where you need to analyze the future of this tech from because that seems to be the direction so how do you deal with that what do you do with that yeah indeed um i mean if

If I look at my childhood, which was mid-90s, going to elementary school and stuff in the early 90s, certainly couldn't have told you then what was going to happen in the next 10, 15 years. I was like the one kid in my class who had a computer at home. So times have changed, I think. Yeah, I mean, no, it's a scary and also very interesting time. And I like it. I like that stuff's really changing. It's happening.

New technology coming out all the time. To me, this is fun. It's chaotic. And who knows if anybody will pay us to do any of this five years from now. But I don't know, it's just, it's cool. I always thought new tech is cool. And it goes back to the thing I was saying. Like, when you're excited about Hello World coming up on your screen,

then I think you can take this kind of thing in better than if you just sort of shut yourself in and say like, oh, well, everything should stay the way it is because that's what I've learned. And this is the world that, as I understand it, and it should stay this way now because that's more comfortable for me. But that's also not very exciting. I guess that's a positive way to look at it, I guess. I admit I am slightly pathologically positive.

I can't help myself. Life is nice, you know, and it's fun to work with computers. Yeah, yeah. I find it hard to be negative. about the whole thing. Well, I think, like, at the end of the day, you're not changing the industry course, right?

Like, you're not going to, you by yourself are not going to revert everything that's happening. No matter how much you, like, cry about AI, like, it's not going to stop, right? We can talk about there being a bubble, and there is absolutely a bubble, but the dot-com bubble was also a bubble as well,

and Amazon lost, what, 99% of their value because nobody, knew what the web could do at the time. And people were doing stupid shit with the web. You just put dot com in your name, you just went up in value. And that was happening with AI for a while where, you know, Taco Bell AI drive-thrus

and then people started ordering 10,000 watercups and they realized, oh, that's a bad idea. So there is obviously you can call it a bubble, but also what it is, if you're just exploring with this tech, right?

It's what can we do with it? where does it make sense and people are just especially if you're in corporate and you are seeing this hype around it you're just injecting it into everything just to see what you can extract value from and if you're in corporate

that is sort of your entire objective sure yeah and you know if you're in the startup space then it's probably very easy or it was very easy for a time to just raise a bunch of money by saying we're doing this with AI It was a cat feeder with AI or whatever. Even just things like the rabbit R1 where they released a thing that just didn't have any...

They released it on the promise of the future that it was going to have, and they raised millions of dollars to do that. That was visionary tech. As I recall. There was definitely a vision. Yes. I forgot about the rabbit. That's just a notable example. I'm sure there's a bunch of other Silicon Valley companies that we'd never even heard of that

tried to do the exact same thing. Yeah, yeah. And like if we're like a little bit cynical, I think and look back on the dot-com boom and imagine is the same thing going to happen now where you have like this sort of explosion of innovation, if you want to call it that. That's the charitable thing to call it. Everybody's doing GPT rappers and stuff or everybody was doing a dot-com website back in the day. but over time all of the smaller things kind of die out

and then power and resources consolidate with like a couple of major players basically what happened at the end of the dot-com boom right was like a couple of companies came out on top and it already feels like that's where things are headed with AI that you have these major labs that are like swooping up all the talent all the researchers

and all of the funding and all the GPUs and all the RAM. And that's where power is going to consolidate. And then it will just be a thing that we look back on. It would be like the AI boom. And then we just go to chat GPT and ask, can you tell me the story of the AI boom again, GPT? You know? Just like you would go to Google to search for the dot-com boom,

which has probably happened a million times. Yeah. So outside of the sort of hoarding of this code, you said that you and members of the team have been sort of playing with this tech for a while now. How has it been getting used in the project like over this time? So I think one of the big things at least that I've been using it even like years ago was making tests.

So writing test cases like exhaustive, comprehensive test cases is notoriously boring as every programmer knows. That's why they don't do it. Yeah, basically. And I find that AI is excellent for being more rigorous with your tests. It can bang out super comprehensive

tests for things that you know that you should be testing, but you're not because it's boring to write the test. So that's been a big one. And it's also been just always helpful for like looking at performance analysis and things like that. For years, you've been able to copy a perf profile and paste it into chat GPT and ask like, hey, could you give me some theories on why this thing might. be slow. And just having somebody to like throw ideas around with, like that intern, even though

like a year ago, maybe GPT was not the smartest intern that you could get, but he was all right. And every now and then he had a really good idea. And it seemed worth it to keep talking to the guy, even though he was just like sometimes get real confused or start obsessing about something unimportant like a real intern. But there's been real value there for a long time. You just had to dig to find it. And

nowadays it's like you don't even have to dig that deep. You just get pretty good stuff pretty regularly. My own use of AI has evolved over time from conversational with GPT

and chat GPT. In the beginning, when that came out, and then like GitHub co-pilot, but then using Claude, when they started making nice models, especially in the last year, and trying to just find ways to, I guess, make my job easier

and make the browser better, make programming more efficient, faster, funner. I don't know. It's so ingrained in my daily workflow that I barely think of it as a separate thing anymore. It's actually hard to imagine going back to not having it. That would be very frustrating, actually. So it's kind of like... Which I guess... I guess kind of like going to an environment that doesn't have code completion to you. Right. Or more like going to an area that doesn't have internet. Which sometimes can be really fun for as a creative thing where you're like,

I'm going to disconnect for a week and make a game or something like that. Stuff I would do when I was younger, that was fun. But now it's, it would be very annoying to lose this thing now. And I think there isn't, there isn't interesting argument. that some people have, which is that these plans are heavily subsidized at the moment. So they are trying to win market share. And so they give away tokens for much cheaper than they really are. And they're just trying to lock you in to their ecosystem and whatnot.

And fair point that's definitely happening. That's also the classic Silicon Valley playbook, right? that's how Uber ran for years, just like subsidizing everyone's cab rides. Right, yeah. The Silicon Valley model is... Yeah, Silicon Valley model is basically burn as much money as possible until you get acquired. Yes. Or until you achieve total domination. Yes, yes. But acquired is probably the thing they actually aim for. Domination is accidental. But it does happen. And yeah, you can...

you can see that same classic playbook with the subsidized token plans and stuff. But even so, like if it turns out that tokens, you have to pay way more for the tokens in the future, I think people are probably going to pay. And it will just be an expense that the industry accepts. And the people who own shares of OpenAI and Anthropic. and so on, they're going to get very, very rich from this whole thing. Yeah.

Crazy prediction, I know. Yeah, I know. Next, you're going to say they're going to buy more RAM and GPUs. That's a... Oh, you don't think they have enough? No. Oh, I hope they have enough. I really do.

I had to buy a new drive recently, and it cost me like 200% of what it changed. should cost. Thankfully, thankfully I was, I upgrade a new system. I now have a DDR5 system, 9,800 X3D.

Thankfully, my housemate had some leftover RAM because AM5 is unstable with four sticks. So he had four sticks and he had two that he wasn't using. Because I did not want to pay, I think it would have been like

a thousand Australian dollars for what I have my system and I didn't, I did not want to pay that. I was not happy about that. That's pricey out there. Yeah. Yeah. Well, okay.

That sort of like related to the AI stuff. Like, what is your sort of thoughts on this sort of pricing out of PCs? Because this is, I think, directly related to, oh, it is kind of directly related to what's happening with AI. Hmm. I don't know that I have a nuanced opinion on that. I'm not familiar enough with the field. I very rarely buy parts or build computers.

But in general, I think it's interesting that you see the sort of second-order effects of these huge companies getting huge investments and then spending those investments on things that you and I want. It's curious. Didn't see it coming. And I guess this has probably happened with other things in the past. I'm sure there are some historic analogy that I can't think of, somebody buying up all the whatevers that people used to want.

But, yeah, I don't know. It feels like it's not temporary either. And probably at least as long as there is this massive arms race between the major labs, they're not going to slow down and they're going to be willing to pay more than consumers to get the stuff. So I think consumers might be in a little bit of a tight spot for the near future, as long as the labs need this stuff. Industry predictions are putting it somewhere at the earliest 2028 for things to sort of calm down.

But I've seen numbers out to 2030. And who knows? By that point, who knows what they're even working on, right? You might just have some other new project come along that pushes that even further. Yeah, I guess what I would hope for is that somebody would invent some specialized chip or something that is useful to large-scale AI development, but not useful in consumer products. And then that would relieve some of the pressure. But I think using commodity hardware is probably really smart and a really good solution to their scale. problems. So they probably are not super interested in developing specialized solutions,

unfortunately. Well, that's what made Google so successful early on. Like, everyone else was doing these big, large deployments, and they were just like, let's buy a lot of Greybox systems and then just run them together. Yeah, exactly. It's so smart, unfortunately. It just works so well, too. And like, let's throw Linux on all of them, right? And we don't have to deal with Sun or whatever was the company at the time. Yeah, I mean, that strategy clearly, clearly works. And so, yeah, unfortunate. And I think your RAM is probably going to be priced for a while.

Yeah. So back to the browser. What is the current state of things? Like, what does it feel like to use? Is it usable? I wouldn't use it if I wanted to just be a guy who uses a browser. If I wanted to be a guy who works on a browser, I'll be all over it. But if you try to use it as a user day to day, you'll be disappointed and you will have a bad first impression, so please don't do it.

I'm actually really happy that you've fully decided like no binaries until they're ready. Like that's such an important thing because so many projects sort of they get out there way too quickly and first impressions are hard to change. Exactly. And we still have people who come to Discord and ask like, how do I build this thing? Like, I just want to test it. And they're not a programmer and they don't know their way around the shell and they need some help. But they eventually like somebody helps them along and they get a build. And then they're like, oh, this is not very stable.

and, you know, surprised Pikachu. Wow, really? That's why we don't have binaries. But obviously, we want to become stable. It's just, it's not there yet. And providing binaries would give people the wrong idea and more people would have the bad impression. And at least in my experience, I find that

if you get people to jump through a couple of hoops and they have to build it themselves and they have to install the dependencies and so on, they tend to be more willing to accept the crappiness of it compared to like if they just download a binary and they double click on it, it launches and it doesn't do what they hoped quicker to be disappointed. It's sort of my theory of proof of work with open source projects is that you You prove that you built it yourself and there's some value that gets baked in there somehow. Bug reports from people like that also tend to be better, so that's good. But yeah, no, the state of it is unstable but rapidly improving.

So we shifted our focus from being heavily test-oriented. So we've been working on passing a lot of compliance tests and things like that. we finally got to a point where we feel like, okay, so we're scoring well enough on the test that we need to start thinking about real websites and focusing on just making sure that real websites work, like stuff that people want to use, like Instagram, Tumblr, Facebook, YouTube,

all these things that people browse every day. And it's going well. every major website has performance problems but we're working on those and trying to find... From outside of it being running single-threaded?

Sure, yeah, performance problems in the sense that they just take longer to load and there's sluggish when you scroll this frequent like micro hangs like you might hang for like half a second when you hover over something, stuff like that. And those are all things.

We know how to solve these problems. It's just it takes time to get all the architectural pieces in the right places so that we can get performance where it wants to be. But I think our focus historically has been on correctness. And we got to a point where we feel reasonably good about correctness. And performance is now becoming performance and competitive. are now the sort of main drivers of what we do. So we need to go fast and it needs to work with all the websites. So it's a bit of a shift. So is everything still on track for the alpha this

year? Yes. Yes. As much of a track there is, I mean, we say that we're going to put out an alpha this year, which means that if we run out a year, we have to put something out. Otherwise, we would be filthy liars. So if the end of the year comes and we don't have something, then look for a binary on New Year's Eve. What is the

assume we don't run out of days. What is the hope for the state you want it to be in when the alpha comes out? So this is something that we're always discussing. Like, what does it mean to be a good alpha? To me, it means that somebody can install it and not have a bad time for at least 10 minutes.

That would be super cool. And then if they run into a crash or something, that is going to happen. They're going to find some incompatibility, something like that. But if somebody just installs it, goes to their social media accounts on the major social media networks, they want to watch a YouTube video, stuff like that, we want that to be working reasonably well to fool somebody for 10 minutes. That's how I think about it. Now, everybody else has their own ideas of what they think a good alpha is

because everybody uses browsers differently. And I guess since I'm sort of leading the team, I'm taking on the responsibility of thinking of the people who are not computer programmers. Because we have to remember that not everybody is a computer programmer, Everybody cares about GitHub and these kind of things, but they instead care about Facebook and those kind of websites. So we're going through all of those.

And I have a dashboard here at home where I monitor like the most popular 100 websites, checking them out once a day, just seeing how they're progressing with our load times and memory usage and stuff like that. software development stuff. What do you sort of hope to achieve with the alpha? We hope to build something that people can use to help us understand what we need to do for beta. So we have been very isolated to our own browsing, obviously,

because the people who developed Lady Bird are the people using Lady Bird. There are no real users outside of the developer group. So we don't know very much about the browsing habits and the browsing needs of people who aren't us. Our hope with the Alpha is to learn about that group of people, which will be like early adopter, masochist tech enthusiast types.

And who are probably all? also going to be interested in GitHub and things like that. But hopefully there will be some overlap or lack of overlap with what we're doing. So we want to learn about stuff that doesn't work, all kinds of websites that we've never heard of. We want to find out what's wrong with them. And we want people to tell us and give us screenshots of things that don't look right and links to things that don't load and things like that. so that we can orient ourselves and have, I guess, like, build some understanding of what the gap really is between an alpha quality and a beta quality because currently we don't know.

And we don't want to put telemetry in this thing because, I mean, it's a big topic, but like I don't like telemetry. And I think that it has some upsides, but it's a very sensitive thing. And it's one of these things that people are very tired of, I think. So we have to figure out exactly what we're doing there. At the same time, if somebody really, really wants to give us automatic data about what they're doing, then maybe we should have a way for them to be able to do that. Maybe they could do a special build, but by default, I think we don't want to have these kind of things. Well, you brought up KDE before.

There's actually a good example here. In KDE, they have a built-in telemetry that's turned off by default, and there's just like a slider that you can be like, give this data. No one ever turns it on except maybe some developers, but it's just sort of there if you really, want to do so. Yeah. Yeah, it's unclear to me what the best strategy is there, but for the time being, we're not even developing any kind of features like that.

We are, I suppose, somewhat idealistically hoping that we will be able to manage the onslaught of bug reports that will come. Yes. The alpha will open the floodgates. and... Yeah. Because I think a lot of people are really...

They... They really want there to be an alternative, right? Because, you know, you have all of these browsers and, you know, you... Most things are just Chrome, right? And people... Mm-hmm. No matter how many posts Brave puts out, being like, we are the fork of Chrome, blah, blah, blah.

We are the different thing. at the end of the day people are kind of just looking for something that isn't chromium based and unless you're willing to use safari they're real and like yes there are some web kits things sure but there's not really there's not really a true independent browser that even exists at this point that's at least notable besides you know the big three. Sure. Yeah.

I mean, so we want to see more alternative browsers, obviously. That's something that's deeply driving for us. Sorry, I guess servo does exist, but also servos very early on as well, but sure. Sure. And I want them to succeed and thrive as well and to find their niche and so on and succeed at everything what their ambitions are. Because I think we'll all be better off with more choices. Lack of choice is a sad, terrible thing.

And if you're a browser choice enthusiast, the last decade has not been good. But I think there are good times ahead. We're going to be probably coming out first and asking people to actually test this. from the new batch of new browsers, which means that it's going to be harsh, and people are going to say bad things about us,

but we're going to try to take it all in as constructive feedback and try to build a good beta out of the feedback we get from the alpha and so on. But I don't know. I mean, what we're doing is, there isn't really a playbook established for getting a new browser up and going. So we're just figuring out as we go, I guess.

I guess it's as good of a memo note, point, whatever. A good point to end it, we'll say. Sure. Pleasure to have you back on. This was fun. Was there anything else that maybe you want to up that we hadn't touched on yet? I know it's been like two hours, because there's like a lot of things it's talked about. Oh man, I barely remember what we've talked about. Fair. Fair.

All over the place. No, I got nothing. I guess I will just reiterate my message to everybody to go and play with state-of-the-art AI tools if you're a computer programmer and try to set your prejudices aside and try to play. Remember that person that you were when you saw Hello World on your screen for the first time and how exhilarating that was and see if you can't find that experience again because it's there waiting for you. That's my feeling. Okay. So if you want to go check out Lady Bird, support the project, get involved in development, where can they go for that?

go to ladybird.org. It's our home on the World Wide Web. Everything can be found on there. The sponsors, all the good stuff. Oh, gosh, I hope so. Looks like it can be. Yeah, if you want to be a browser developer, you can come join us on Discord.

We have links on ladybird.org. If you want to sponsor browser development that we're doing, information on ladybird.org. If you want to read our newsletter, subscribe to the newsletter, or read a recent post. perhaps about my Rust port using AI. Go to ladyware.org. Yeah.

And I guess if people want to also follow you directly, you also are on X, Twitter, whatever you happen to want to call the website. Sure, yes. I'm on the website, formerly known as Twitter. I'm awesome cling on there if you want to follow me. I'm also on YouTube, although I don't recently post, but you can find me in all the places

that's awesome cling Okay Nothing else you want to mention No other links to some people are too No not really Thanks for having me Brody Nice to see you again Yeah you too

I'll do my outro and then we'll sign off Okay My main channel is Brody Robinson I do Linux videos there six-ish days a week Sometimes I stream I've been lazy on that for a couple of months So maybe not sometimes It has happened in the past

It was happening again in the future I've got the gaming channel Brodyon Games right now I'm playing through Shenmu and also I'll probably be done with DMC5 there'll be another game in that slot work it out maybe Metal Gas Sol or something I don't know check it out you still will be there

and if you're watching the video version you should find the audio version on basically every podcast platform that is Tech Over T there is an RSS feed for that as well if you like to use RSS feeds and we are on video YouTube if we have Spotify video for some if you want Spotify video I don't know. It's an option. It's there. It just does it automatically for me.

How do you want to sign us off? What do you want to say? I think that it's going to be sweet to have more browser choice in the future. And I really hope that the other new browsers succeed as well. I think sometimes people are not so aware that they're not so aware that they're There's multiple new browser projects going on. So shoutouts to Servo. And it's nice to now share a language with them as well a little bit. Yeah, all the best to the Servo team, I guess.

Sweet. And...