Ep. #13, Why Microsoft Chose Go: A Deep Dive with Thorsten Ball

John McBride: And we're back again with the Open Source Ready podcast. I'm here with Brian. How are you doing?

Brian Douglas: I am excellent. We've got a lot of rain in the Bay Area, and it's getting colder again.

So anybody enjoying your 70 degree weather, please don't talk about it.

John: Yeah, that's the 70 degree weather we have in Denver right now. I'm loving it.

But we're here to talk with Thorsten Ball, coming to us from Sourcegraph from Germany, right Thorsten? How are you doing?

Thorsten Ball: Yeah, I'm doing fine. How are you? Thanks for having me.

John: Doing good. Yeah, thanks for being here.

So I'm a huge fan of your writing and a bunch of the work and things that you've been doing.

You wrote two books that I loved, "Writing Compilers in Go" and "Writing Interpreters in Go."

Why don't you give our audience just kind of a quick intro to who you are, things you're interested in, and then yeah, we can dive into some very topical topics this week.

Thorsten: Sure. So yeah, you got my name. You know that I'm a programmer.

I started out as a web engineer, building web applications. Then I got more and more into systems programming.

So much so, that I ended up writing about it, self-publishing these two books.

And then I got into the developer tooling world. I worked at Sourcegraph for nearly five years, first US company that I worked for, first really scaling startup that I worked for.

Changed a lot of things for me in a good way. Then the last year I spent at Zed, the new text editor written in Rust.

So I switched from mainly using Go to using Rust as much as you can in a year in one of the most hardcore code bases I worked in. You know, hardcore in a good way.

And then now I'm back at Sourcegraph, working on AI agents and developer tooling for, you know, the world that's ahead of us.

Brian: Yeah, Microsoft has announced they're going to be rewriting their compiler in Go.

I had to think about that, 'cause there's been a lot of back and forth on what they're actually doing.

And I actually went and watched a video, the announcement and read the article as well 'cause this was actually a pick on our last episode.

So Thorsten, you know what they're doing, would love for you to comment. You seem to know Go.

Thorsten: I don't know too much about TypeScript. I have to admit, even though I was there at the first JS Conference in Berlin when they announced it.

I was in the audience where people were sending on Slack, "You know who that guy is on stage? He wrote C#." And you know, and they were talking about Anders Hejlsberg.

And so I was there, but I'm not a big TypeScript expert. But yeah, TypeScript is, you know, a compiler that compiles TypeScript into JavaScript and just type checking, and it was bootstrapped into TypeScript.

So TypeScript itself was written in TypeScript, and now they're rewriting this in Go, and I'm a huge Go fan and I think it's a pretty, you know, pragmatic language.

Which is also sometimes I think why it's looked down upon, as in its boring and people say lacks some of the modern things that other languages have, but I can, you know, talk about that.

But so now they're rewriting this in Go, and I think the justification for it is pretty balanced, calm, wise, with a practical, pragmatic, whatever you want to call it. It seems that a lot of thought has gone into this, and I find it interesting.

It's a good thing for Go. It's a good thing for TypeScript, I guess. And I'll stop here because I can talk for another 30 minutes just on this.

John: Yeah, I think the biggest thing that was surprising to me was sort of Microsoft doing this.

'Cause yeah, I mean like the more meta ecosystem things have been what's interesting to me about this, not so much the like, oh they picked Go.

You know, like, oh why wasn't it Rust? Like, some of those conversations don't end up being very interesting to me because again, Go is practical, Go scales really, really well with the big team.

But again, yeah, they, you know, they, being Microsoft, has kind of a huge developer community around these things like .Net and C#, obviously. I think that's what kind of surprised me.

Do you see this as kind of a, you know, and any meta play where Go was kind of a Google thing for a long time, or is this almost kind of bowing down to some of their competition in the programming developer space?

Thorsten: No, for me not at all. Like I read through the comms, and it took me a while to get why people were kind of shocked by this.

John: Yeah.

Thorsten: It wasn't even on my radar that it's a controversial thing that Microsoft uses Google's programming language. To me, it's, like it's open source, right?

And it has been the case for say 10, 15 years that it's now boring. It's, I don't know, I don't know what it is at Google, but I'm sure somebody has used Teams there or something or uses Office.

You know, the Microsoft world or the Windows world is not my world. I've been a Linux guy since I was a teenager and you know, macOS for the last 15 years.

And when somebody was like, "Why didn't they rewrite it in C#?" My first reaction was, oh yeah, C# right, right. I forgot about it, you know, wasn't even on my radar.

And that's not a dig at C# but it's just, I've been in the compiler, interpreter space in the sense that, you know, people tag me on Twitter.

You know, I read up on it. I try to keep up with it. I know different amateur implementations of different compilers, and C# just wasn't on my radar.

Like I think the next obvious choice would've been maybe Rust or...

John: OCaml or something.

Thorsten: Even OCaml or yeah, something else.

John: Yeah, I mentioned this book in the last episode where this came up as well, but I read a book called "Building a C Compiler from Scratch."

And it was really interesting because, and like definitely not as beginner as I was hoping it was going to be, but even just some of the like the beginning concepts are fascinating.

You're talking about how like important a good matcher is in the language that you're going to be using.

And I think the author recommended OCaml and that's kind of where I stopped.

You know, I was like, "I'm going to go learn OCaml and try this out."

And yeah, woof, very, very challenging.

Thorsten: People always say this, that you need all of this and match statements to, you know, write a compiler or something.

And I think there are moments when you write a parcel or something like an AST or some tree and you want to traverse it or you want to find out things about it.

Then it sure is nice if you have a match statement. And it sure is nice if, say, in Rust, you know, the compiler can check whether you have an exhaustive match statement and whatnot.

But that being said, I've also, in the last, this was started in pandemic and then it dragged on for three years.

I wrote an optimizing compiler in Rust, and this was implementing a really small language but it was, you know, the books that I wrote, they show you how to write an interpreter in Go and how to build a bytecode compiler in Go and a virtual machine.

And then this thing was me again trying to learn Rust for the third time in my life, not giving up.

And this time I'm going to build an optimizing compiler and that means taking the code, tokenizer lexer, parsing it into an AST and then turning it into an IR, like an intermediate representation that's in SSA form.

And then you do optimizations, which means you do like graph traversals and graph sorting and all of that.

And let me tell you one thing, what's not fun is traversing a graph in Rust and also trying to modify it at the same time.

John: Yeah.

Thorsten: And then you end up in this weird spot where you think, didn't everybody say that this is the perfect language for this?

And then people say, well you shouldn't do it like this. It's not really a graph. Use like a flat array and indices into the array and then you traverse this and blah blah blah.

And so what I'm trying to say is kind of similar to what Anders said about why they're using Go that it depends on what you're doing, and it depends on what your code wants to do.

It also depends on how experienced you are with the language, right?

And I think somebody on Lobsters commented, you know, kind of cutting through all of the noise, because I was, you know, I went through the comments just expecting people to lose it, you know, oh they're using Go for this.

And so one person was saying, look, it's pretty simple. Apparently 12 people or 10 people have already rewritten, I don't know, half or something of the types of compiler in Go.

And apparently they haven't had any Go experience before and apparently it works and apparently was enough for them to make the call that, yes, this is a valuable project, yes, we can make accurate estimates about the performance.

Right, that already tells you something about how good Go is, right.

It might not tell you about, oh what data structures does it have and the standard library this or that?

But 10, 12 people not knowing the language can be productive in it rewriting a compiler and you know, being confident that they can pull this off with the given performance benchmarks.

I don't know, that's a good argument, right?

And that comment cut through a lot of the noise and I think Anders was also saying that they want to translate the types of code base from TypeScript to Go to get performance gains.

What they're not interested in, I assume, is rethinking the whole architecture of the compiler right?

And he says the way the types of compiler is written is pretty similar to how you would do it in Go, meaning there's like simple struck slash objects, whatever.

There's no crazy patterns that they would have to translate.

And I think if somebody has translated a non-trivial program from say, whatever, JavaScript to Rust, right?

Then you've realized, oh you can do a normal translation, but that's not the Rusty way to do it because the Rusty way would be traits or something.

And then you have to rethink the ownership and how you know, stuff gets managed, and you could do this for very good reasons, and you get a lot of good payoffs, and it's, you know, result is good, but is this what you want to do right now?

Is this the timeframe you have in mind? Is this the resources you have? Can you get the team up to speed on doing this?

And I think what he's saying is just real world engineering. It's not, you know, internet comment engineering, where you compare feature lists.

It's, no, given a set of constraints. Meaning the people that I have on my team, the timeframe that's available to me, our goals, the history of this project, what is the choice that I make?

What are the tradeoffs that I make? And I think it sounds like a good, good trade off and a good decision.

John: Yeah, you mentioned something in there that really resonates with me, just how quickly you can ramp up some people on Go.

You know, I've maintained some big Go libraries out in the wild and stuff and just being able to get people from zero to hero in Go is pretty great.

But also reminded me of something you said kind of as we were chatting before we started recording, just around like kind of the current state of the industry and some of these kind of comments that, you know, end up gaining a lot of traction in things.

Just around like, you know, the expectation on learning and continuing to, I guess, improve or adopt as you know, the industry continues to change and adopt.

What are kind of your big ideas around that, and, you know, how things seem to be changing?

Thorsten: Yeah.

I feel like I signed this contract when I started as an engineer, and the contract says you'll need to always be learning. You know, you cannot rest on what you know now, and you need to keep up with this.

And to me, as somebody who switched careers from being a college dropout that studied philosophy into being an engineer, this was the reality.

Like I have to teach myself this stuff, and I have to keep up with this stuff, otherwise, I'm out of a job.

And I think when I started, I implicitly assumed that everybody has this same thought, and back then, everybody was learning new things or at least in my cohort, say, people of my age or the people that I talk to at conferences and whatnot.

And then I feel, you know, now 10, 15 years later, you can see people just dropped out in some sense.

Like they stopped caring about learning new things, or they became the grumpy old man that they didn't think they were going to be.

And as a concrete example, when I started out, I was in the Ruby community and the Ruby community's super nice. I like the language.

They're pretty pragmatic and super into product thinking, and I think a lot of people that I now work with or still meet, we're all doing different languages now, but we have a background in Ruby.

And you can recognize that, yes, you were also part of that, and you also have this product thinking, but the people that I just mentioned, we all now use Go, Rust, whatever it is, TypeScript, something, something.

But there's still people that I know who still use Ruby, which is also totally fine and totally valid.

But they still have the same thought as 10, 15 years ago that Ruby is still the hot new thing, or you know, there's no reason for me to learn something else.

They, oh, JavaScript on the server, that's not a good idea. Oh AI, that's not a, you know, like this is bad and I'm just thinking man, it kind of is starting to become like one of those Java developers that you made fun of back then.

I feel like, especially now with AI changing a lot of things, I think the last thing you want to do is kind of cross your arms and say that this is just a fad. This will blow over.

I mean you have to be measured in how you handle it and you don't necessarily have to go all in if you're in an industry that won't be touched by this or if you're, you know, others, job security something something or have other values that you bring to a business, then sure like you don't have to keep up every day with what's being posted somewhere.

But if you work in, for example, developer tooling, like I am or have been working for the last five years, is that this stuff is changing, and you need to keep up.

Like there's nobody else watching over you, saying, I'll pull you along. Like I think it's your responsibility to try to keep up with this stuff.

Brian: Yeah, I also come from the Ruby community as well. Like that was the first language I learned, Ruby on Rails.

Like first, you know, 15 minute blog, video that I watched and when you brought up the C# thing, 'cause I didn't know Anders was the creator of C# as well, also never crossed my mind.

I'm like, oh yeah they should use C# until I started reaching like the X comments, I saw it come up a few times.

Thorsten: Yeah, yeah. Yeah, yeah.

Brian: But there's other things like Zig I think also is a thing that has got some hype around it.

But when you talk about the practicality of Go and the practicality of the decision they made towards choosing this, to me it made a ton of sense 'cause I know what Go can do and I've crossed a chasm of a oh yeah, Go, there's reasons why I would use Go and I know where that comes in.

I wouldn't call myself like a prolific Go programmer but I can copy and paste pretty good from Stack Overflow I guess.

Thorsten: Yeah.

Brian: What you used to do, I could use AI to generate Go.

But yeah, I was going to ask a question of, 'cause like TypeScript you mentioned that really as in depth in TypeScript ecosystem but like there is a world now 'cause I came from the front end space where Typescript's kind of incepted everything.

So all tooling, all front end frameworks are all like TypeScript first.

Node is now I think it might have already shipped where the Node server already comes with TypeScript ready out of the box, forget what version that was.

But I guess the question I was going to ask is like, do you find it a problem that developers think in that sort of mindset of like, okay this is this JavaScript so it's going to be TypeScript through and through or rather...

I guess like what I'm getting at is like I don't hear a lot of people saying, oh I'm going to drop down to Go or drop down to C and solve this problem.

And do you think that's kind of the difference of folks who are going to be able to scale the future of this development tooling community?

Or I guess I'll stop at that and let you comment because that's a lot to ask.

Thorsten: Okay, so if I understand it correctly, the question is can you ride the wave of TypeScript without ever looking to your left and right because it's still the most popular thing?

Brian: Yeah, especially in the world of AI agents where like the tooling's now being built in JavaScript so it might be enough to be like, hey stop writing this in Python, write this now in JavaScript.

Thorsten: So.

My opinion is that you should learn more programming languages than just one or two. And that doesn't mean you have to use them full time, that doesn't mean you have to get a job in them. But I think there's value in seeing the world through a different lens, which is what a different program language gives you.

Meaning if you write Go, you look at, you know, how to manage dependencies a different way or the complexity or tooling, right?

And when I've been in my darkest moments when I've been ranting, I send a message to my friend on iMessage and I write, every front end engineer should use, you know, a different language for a year and only then is allowed to come back.

I think to make really good tooling, to write good software, you need to build up taste. And I think taste is important, and you don't build it up by only looking at the same thing for a long period of time.

There's some people who really manage to do it. And I'm not saying if you're a TypeScript superstar and have been for the last 10 years. It's a bad thing, it's not.

But in general, you know, accept that yes, you can be productive and ship stuff in Go.

Yes, you can do this in Rust, yes you can do this in OCaml, yes you can do it in PHP, yes you can do it in JavaScript, in TypeScript, in C, C#, whatever.

And it's really valuable to try and figure out what that looks like because those experiences help you then make other or better choices maybe in the language of, you know, your daily language.

For example, when I started using Go, you know, 2011, '12, I think back then, people made fun of Go because it didn't have a package manager and people would say, oh it doesn't have a package manager.

I said what happens? And a friend of mine, you know, we were in like discussions and somebody would bring up that argument, he would say, turns out, it's not an issue.

And that was of course like a funny way of saying this, but it turns out in practice, it wasn't as much of a deal as it was made out to be.

Like yes, you had to vendor dependencies, you had to do this, but it had disadvantages of course.

But it also gave you this view of things where maybe it changes my approach to software if it's just slightly harder to pull in a four line dependency than just typing in a command, right?

Maybe that changes my approach and maybe that approach also has something valuable to offer, something that I can carry over into other languages.

And I notice this with a lot of people who've only been exposed to one ecosystem, that they don't understand how things can be done a different way, right?

And the example I always use is my tax accountant, he's, I think he's about to retire or I don't know, maybe not, maybe in five years, but he's mid fifties I would say.

He's been doing taxes for the last 30 years, right? And when I go to him and I rant about, you know, oh I'm selling eBooks online, that's a crime.

Apparently I have to fill out all of, you know, whatever, that's really hard and you can imagine what the tax situation looks like.

And he goes, yes. And you know what, the rule book when he started in the seventies was this thick, right? But now it's this.

And he said, the problem is now if you talk to other tax accountants or lawyers that are younger, that I say 25 years old, they think that law book has to be this thick and if it's only half, then the world will go into chaos, right?

You cannot imagine that without all of the stuff that I have, stuff still works. You cannot imagine the absence of something that you always took for granted.

And I think with languages, you also have the same bias where you start to think, oh, it has to be done this way.

And if it's done any other way, that's insane. Like how would you even do this?

You know, how would you develop something in a language that doesn't have a standard lib?

Or how would you do something in a language that has a huge standard lib and no dependency management?

Right, and I think it's valuable to dive into this.

John: Yeah, when I first was getting into Rust when I was at AWS, I'd been doing Go for so long, that some of the cargo paradigms were like breaking my brain in a good way.

And I was like, wow, like I love that I can just cargo clippy and like get like a formatter and all this stuff that is sort of independent from the tool chain and all this.

But I want to shift gears a little bit to some of your ideas and you know, thoughts in this space around AI, specifically in AI agents.

So at Sourcegraph, you're working on, you know, new identic stuff and developer tooling and you've written about how AI agents are kind of going to be the part of the future of this, or at least, you know, it's part of this new way of thinking as kind of the industry continues to, you know, always be transforming.

Where do you see that going? Where do you see some of the AI agent tooling for devs going?

Thorsten: I don't know, I really don't know. I wish I would but it's, I think it's going to change.

I think in a few years, we will look back and say, yeah, oh yeah, it did change.

Like I truly believe this, and that doesn't mean oh, we'll all be out of a job or we are only going to write software by talking into our microphone.

I'm much more pragmatic than this, and I don't have the imagination.

But if you now have models that can predict where your cursor should go in a file while you're editing, and it can do this really fast, if you now have models that at the push of a button, can generate a 300 line perfectly working Go, Python, JavaScript, you name it, script...

If I just did this before this recording, you now have models that I can say to somebody sent me an email, that on my website I haven't updated my employment information. Can you fix this?

And my model goes and finds the file that mentions my employment information and updates it and creates a Git command and pushes it, sends me a screenshot and says, does this look okay to you?

Like in this world, if we have these tools available to us, I don't think we are going to keep typing the way we have been typing for the last 10 years.

In the same way that Ruby on Rails did something to development, Cloud did something to development, right?

And it's not that no one will ever again tweak the Emacs or Vim config and, you know, see this as a labor of love and write code for the love of the game.

But I'm talking about bigger trends and efficiencies in what's valuable to a business.

And if somebody comes to you today and says, oh yeah, for this little prototype website I'm going to go and I'm going to buy a server, and then I'm going to go and drive to the data center and I'm going to ask 'em whether they can put it in a rack and then I'm going to spend their day and setting it up and then I'm going to come back to you.

You would say that's inefficient. That's a waste of like, don't do this, just go and use any of the websites, use any cloud provider to do this. And yes, there are still sysadmins.

Yes, that does still exist, right? But you cannot tell me that, say, sysadmin as a job is the same as it was 20 years ago, right?

And I think this is the type of change that I see coming, in that a lot of stuff that we've now done by hand will be, I think automated or will get easier.

You know, be it, you know, how to go from a blank page to a prototype or from a half working prototype to something more solid, or from no tests to some tests.

You know, I see it as a pretty mechanical thing still in that it writes code for you. It's not an oracle that can answer any question you might ever have.

But if you know what to do, and if you know the right questions to ask, you can now use these tools and have them do stuff for you, in the same way that you might have used a Vim Macro to change like the 50 lines matching blah, blah, blah in this document of 3000 lines, you know, whatever.

And you know, again, as somebody working in developer tooling, this is changing my world, I think.

Brian: Yeah, I wanted to ask too as well, 'cause we kind of got into this before we hit record 'cause you worked at Zed.

You're working on Sourcegraph who also has Cody and like my intro to writing code was like notepad in Pearl Scripts like.

Thorsten: Mhm.

Brian: High school, but I didn't really get into it until Sublime Text was like, oh, everyone used Sublime Text.

Thorsten: Yeah.

Brian: And now we've got VS code, which is like a behemoth in the space.

So like I equate to like your editor being like your lightsaber and like you add your config and like it's your color, it's your, it's like your weight and how you want to like go battle.

But there's like this new world where it's like no longer, like you're now, this might be a bad analogy, but like you're now the Jedi general and you have all these Padawans, like your agents are your coding assistants.

So I feel like, I want to get your take on this 'cause you're right here on the sort of cutting edge of this and building it.

Like do you feel there's a world where we don't choose our editor, we choose like what Padawans we take into battle when we're going to either write Go or write whatever?

And the thing I was going to mention is, I was writing Go a couple weekend ago and it was writing like, I was, I would Go 1.5 I think or whatever the latest one is, I was using and there was a change in 1.2 and a standard lib and the Copilot didn't address that.

And I was getting like compile like errors when I was trying to run my program and build it.

So then I went and the system prompt was like, hey, this is the version we're using.

And then I went and like generated a system prompt from effective Go, that series of articles and then eventually now it's in the docs and now I'm good.

Like my Padawan is writing the right Go I need, it's like adjusting it in the situation that I have to build and I have the confidence to like go do some Go routines, knowing that I'm going to have the latest and greatest Go.

So like what's your thought in like our evolution that now we have a series of agents or a series of co-pilot and assistants?

Thorsten: Yeah, that's a really smart thing to do by the way, like using the docs and...

Brian: Oh, thank you.

Thorsten: Yeah, this is already advanced stuff.

Like you are already ahead of most of the people that, you know, might listen to this and they...

I know people who've never tried Copilot, right?

And I know people who tried chatGPT once two years ago and brushed it off as oh, it made some errors or something.

And what I'm about to say is not going to resonate with them, right?

The point I'm making here is that there's a huge divide of people who brush it off.

And then I think people who, in my more caffeinated, you know, when I have too much caffeine I call it, you know, when you have, when you've seen the light, like when you've climbed that mountain, and you've seen, you had this one moment where you're like, oh my god, it can do this?

And then it does this and oh my god. So all of that as a disclaimer.

I said this just today, I said, you know, I'm working on agentic tooling at Sourcegraph and I'm working closely with our CEO and we're both, or all of us seeing the same things where you have these models, and you think of them as like, oh, I ask a question and come back with an answer.

But then you give them tools, and then you put them in this agentic loop where you say, feel free to use these tools.

I'll run the tools. I'll send you back to results.

And I think if someone has never done this, what I'm about to say sounds nuts, but if you've done this and you've seen what these models do, it's mindblowing.

You give them, as a recent example, I gave Claude three tools. I said, you can read a file, just, you know, basically Claude, ask me to read a file, I'll give you the contents of the file.

List directory, which is just an LS, and run a terminal command.

Three tools, and then I was talking to Claude in this loop and I said, just trying out, I was like, how, what does this file do? Blah blah blah.

And then Claude was like, oh this file does this. Oh but there's a bug here, let me fix this. And I was leaning back and I thought, it can do anything.

It doesn't have access to any file added operation or something else, right?

And then it got stuck, and I thought, oh, is there like a loop or something or I messed the code up?

And suddenly something came back and the file that it said it was going to change was marked as changed by Git and then its response came back and it turns out, given those three tools, what Claude decided to do, I didn't tell it to.

What it decided to do to change the file was to run a terminal command that would echo the new version of the file that it wants and redirect that echo into the file.

So it would run a terminal command that was this long just to modify this file.

John: And just pipe that through into the file?

Thorsten: Yeah, yeah, just redirect it into the file and use that as the editor. And I sat there and I was like, this is crazy.

And I thought I could give this interview question to say junior engineers and I bet some of them wouldn't make it through that interview question.

There's like given only list, your refile, and run term command and you cannot use an interactive editor like Vim or Nano, how would you do this, right?

And it's just, oh I modify, blah blah blah blah blah.

So if you've seen this, and if you've had other moments like this and you've seen how good this stuff can get at writing code, when you give them a feedback loop, if, you know, give them compiler errors or linter errors or diagnostics or something else, it's really hard to say, oh there's nothing of value here.

But instead, what I ended up thinking was, again, working on agentic tooling, exactly this at Sourcegraph, which is amazing, but I'm thinking this is just the beginning.

Like if this stuff gets faster, if the tokens get cheaper, you can have multiple of those things running at the same time, and then you start thinking about how do they communicate with each other, or how do I communicate with each other?

And then you start to think, what's the UI for this going to look like? What's UX for this going to look like?

Because I sometimes sit here and I wait for it to finish stuff, and I get distracted and I open Twitter or something else.

So what's the solution to this, so that people don't get distracted?

And in everything I just described, what didn't I mention a lot? It's how you write code, right? You will keep writing code. You will correct these models. There is code that you will still have to write. They're not all seeing eyes. You have to direct them. You have to know the code, you have to be an architect, or you know, at least know how to make good decisions. But these tools are so powerful and that's becoming more apparent by the day.

And again, like in a world where you have a small model maybe running locally, that predicts your next cursor position, do you really care that your editor has a macro system built in anymore?

You know, if somebody has ever used, you know, Zed inline completion or curses tab or something else, you want to modify a CSV file to remove the third column.

Like back in the day, meaning half a year ago, I would've been super proud to knock out a Vim Macro and then, you know, 20 add sign, Q, replay this for all 20 lines or something.

But nowadays, you know that if you do it for two lines, the model gets it, and then it suggests you want to hit tab and I'll do it for the rest of those lines?

That's a mechanical change. It's not an all-seeing oracle that's come down to earth to know everything, but it's on a mechanical level, this is changing editing, right?

Like on a really dumb, ergonomic, mechanical level.

And then again, like you have other agents deciding on their own how to manage these files and how to run tests and how to fix compiler errors and whatnot.

Given all of that, looking at, you know, me tweaking my Vim config years ago, and people, you know, writing quick scope plugins or like minimizing keystrokes, it seems all a bit like a black and white movie, right?

Brian: Yeah, there was a Twitter back and forth that eventually I also saw was on Reddit, about whether or not candidates should be using AI assistance for take home projects.

And then folks are trying to figure out like how do you, do you combat against it or do you just like leverage that?

John: Oh man, there was also this whole thing going on where that guy from Columbia is getting kicked out of Columbia.

He did like the Amazon interviews and a bunch of FAANG interviews with his little like side LeetCode cheating tool basically.

Brian: Oh yeah, he did on YouTube as well.

John: And it was on YouTube and it's been a bit sad to see him kind of speed running, you know, the destruction of his early career.

But at the same time, maybe he's proving a point around like just the ideals around like kind of how silly LeetCode and some of these interview processes are.

Not to hijack your question, Brian, but.

Thorsten: Just one more.

I would say that you still have to know how to code. You still have to understand how this works because otherwise, you cannot tell good from bad.

You don't know what they are doing, right? And maybe at some point, we get to this, where you don't even have to check, and they always nail it a hundred percent, but we're not there yet.

And I think, put another way, I can only be efficient with these tools if I know how to direct them and really know like, no, no, please don't do this.

Use this library. Also make sure that you don't fall into this trap of doing this, do not special cases.

Like that's what I did like two hours ago. It put some special casing in it where it's like, if the key of this is exactly the value of this, then we do the special case.

And I had to correct it and go, do not special case this, do not do it, even though it might work for this, but don't do it. And to me, it's something like the washing machine.

You, it automates some manual thing to some extent, but should you think, oh, this is the magic thing into which I throw my clothes and they come out clean?

No, you kind of have to know that you don't throw rocks in there or sand or something, right?

And you don't mix the whites and the colored red shirts or something. Like you need to have some understanding of what's going on.

That doesn't mean that, you know, you have to wash everything by hand and it doesn't mean that everything has to go through a machine, but I think you need some kind of mental model of what's going on.

Brian: Yeah, your analogy of washing machines are good because I've got an 11-year-old who has no idea how to balance the load.

So like if he drops his blanket in one side and a bunch of T-shirts on the other side, like that thing's going to, it's going to rattle all day.

We're going to think the house is coming down, and that's something that he will not know unless it happens or unless I tell him.

So like, we're still going to ship bugs, like AI's not going to be perfect, but I think there's a world where we eventually get better and better and we're building like maybe rewrite the TypeScript compiler in a weekend, as opposed to six months.

Thorsten: I'll say one last thing on this, and that is...

People underestimate how much dumb stuff they have to do every day that can be automated. I've been fighting this battle for years.

I wrote a blog post called "Typing can be the Bottleneck," right, where I told people, be good at typing, this is your job, this is how you communicate with the computer, this is how you input stuff into the computer.

Don't pride yourself on being able to type 40 words per minute if you can type faster. And people tell me, oh typing is not a bottleneck.

Like, apparently they sit in the hammock all day long and think of ideas and then it's just spurts of typing.

But I'm sitting here, and I have to look up docs, I have to use the search tool, I have to run terminal commands, I have to write Slack messages, I have to write Google docs and RFCs and design docs and all of that.

And being good at typing helps with this. And I think when you look at development, once you have these tools and their assistance, you realize how much dumb stuff you have to do.

You know, like, oh, typing this Git commit thing again or doing, you know, fixing when I move the HTML thing down here, then I have to update the imports up there, and then they have to do this and blah blah blah.

And that's where I think this comes in. It's not the hammock moments where you dream of something amazing, but it's more this, there's a lot of brute force still needed and a lot of chores to do and you know, the tooling can kind of help you a lot.

John: Yeah, it kind of makes me think of some of, and I talk about this guy all the time, but Cal Newport and some of his ideas around slow productivity and deep work where I think he would argue that some of those things, you know, the kind of monotony of like sitting with a problem for a really, really long time and then like coming to a conclusion or a solution, is like part of the knowledge work.

Thorsten: Yeah.

John: Well, we'll move on to reads. Thorsten, I got to ask you, are you ready to read?

Thorsten: 100 percent.

John: Well Brian, why don't you give us your read first this week?

Brian: Yeah, so there's a paper out there about the Sesame AI. So this is a conversational AI.

I do remember it like examples on a podcast I was listening to of folks doing conversations like as a co-host on a podcast.

Like, hey, this is Miles. Miles, what do you think about this subject? And it's like built in like organic pausing.

So it feels like the person's like actually thinking in that context, better than like the GPT thing.

So if you haven't read this, actually I'm curious, have you guys heard the examples that came out of Sesame?

Thorsten: Yes, it's mind blowing.

Brian: Yeah, it's amazing.

And one of my favorite things to do right now is like some, I've got a 6-year-old daughter and we were driving home from school and she's like, hey could you play that one song that the words go like this?

And I'm like, listen girl, I have no idea what the song is. Like you got to give me more than that.

So I'm like, oh let me just pull up. So I ended up pulling up chatGPT and doing this sort of voice talking function and it was like, hey, can you play that song that goes like this?

And it was like Sara Bareilles "Brave" was the song which don't ask me to sing it 'cause I can't even think of how it goes now.

But then they started playing the song. It's like, oh yeah, if also if you want songs like this, why don't you listen to Katy Perry's "Roar" and like this and that?

And my daughter was in the backseat soliciting and she's like, are they still on the phone?

I'm like, oh no this is a not a real person. It's a computer. She didn't get the context.

Thorsten: Yeah.

Brian: But it was pretty amazing experience 'cause she's like, oh can you ask her to do this thing or whatever and it's like, oh yeah, yeah.

Oh it sounds like she would like this stuff. And it was just, I could see where this world is going and like it might be scary or could just be amazing for kids and learning.

John: Yeah, I was recently also playing around with an open weights text to speech model called Kokoro, which is like, you know, shot up to the number one on Hugging Face for this.

But it also has that where it kind of has that weird uncanny like, and even like just things that you'll hear, you know, people making with their mouths off of mics or like in the phone or like those pauses or like little grunts, little like noises and things.

And that's just that uncanny valley of like, wow, I've never heard that before. Especially from like an open weight model. It's a crazy feature.

Okay, I'll give a read here this week as well. This one's maybe a bit of a hot take, not a hot take, but you know, something's spicy going on and out and about.

But uBlock Origin, which is a very popular sort of ad blocker on the browser, has been removed from the Chrome store and this is kind of a very, very long tale.

I think probably the end of this where Chrome had been saying they were going to do this.

I think that uBlock was coming up with different ways to like get around it, and now it's just off the Chrome store completely.

So the big behemoth, Google continues to, you know, throw some weight around for its ads business is what it seems like.

But I'm curious, Brian, Thorsten, do you all use an ad block on your browser? What's your browser stack look like these days for this?

Thorsten: I've been using uBlock Origin for I don't know how long, you know, long.

So I was surprised when it didn't turn on or when it was deactivated and I saw the real face of the internet again.

John: Yeah.

Thorsten: Which I haven't seen in a long time. And it was also, I have like a work profile, right?

And a private profile and I think in the work profile there's no history of whatever.

So I assume, oh I'm on a new website that I haven't clicked through all of the cookie banners, whatnot.

But it was full of ads, and I was like, what's going on? Why is this deactivated?

And I didn't know that, I don't know why they were deactivated. I thought it was something like outdated version target. I don't know.

But I don't have any, I don't know, moral or ethical opinion here. I just know that I really, really, really do not like popups. I do not like cookie banners.

I do not like stuff that slides around on the screen, regardless of the content. It's just, I don't like that form of UI.

And so I've been using ad blockers ever since they came out in 2005, whatever it was in, you know, popup blockers in Firefox or something.

John: Yeah, I was going to ask you Brian, 'cause you've been using Perplexity more and more, which you know is sort of a competitor to Google search where, you know, Google search is really just the engine for Google ads and that whole business.

I mean, where do you see AI search and ads and kind of that maybe concerning clashing of worlds happening in the future?

Brian: Yeah, yeah, and I was going to say, I haven't used an ad blocker since I was like a front end dev, like 2018.

I had to basically use it so we could like figure out the workarounds.

So I've been using the raw version of the internet, but I've also trained myself to not go to the blogs and the sites that have all the bad experiences.

Like I pay for Apple News Plus because I'd rather go find the news somewhere where it's like, okay, this gave me the news and like I don't want to pay for 27 services to like read articles.

But as far as like Perplexity, I've been using it for two months at this point, and I love it.

I love like the idea of having it embedded like search AI embedded. I question on how above board it is and how they're getting all this content.

There's definitely scraping a bunch of stuff.

John: Yeah.

Brian: But like what I'm trying to find out, so I watch the Warriors and like they're now on a, like a nine game winning streak.

If I were to find out okay this from this game point on like when Jimmy Butler joined the team, like what's the free throw percentage?

And that's like stuff that you got to dig in real deep. They got mba.com, and like I'm not an analyst, I don't have the data, but Perplexity like crushes it on that.

So when it comes to like ads, I think what they've done so far is I get, I get popups with, I do turn off notifications on my phone 'cause I just don't want to be pinged, but I know they have notifications, and they'll just give you like, oh, here's a news article or here's something that's related, that's obviously an ad, but it looks like, you know, some news article that's going to pop up in your face.

That is how they're sort of, I guess getting around that. But I turn off notifications, so it's not really working for me.

I kind of just ignore that, and try to get my, what I'm trying to get done there.

So I think whoever owns the data, who owns that part, is going to be king in the future.

And like trying to get people to click on ads and buy, I don't know, like ear wax removers or whatever, that's a currently a thing on TikTok right now.

It's like they're trying to get me to clean my ears with some camera machine.

John: Oh my.

Brian: The world's going to change. I think the world's evolving in front of our faces on how people can like get your dollars out of your pocket.

Thorsten: Yeah, I think that that's the one thought I have while you were saying this, that everything that we talked about in the last 30 minutes is just like the beginning of the internet, right?

Where people were saying all kinds of stuff, right? Like, oh, because it's on the internet, then it'll be this, or everything will be on the internet, or the internet will solve this and this and that.

And it took years, you know, for that to shake out and to really, you know, the boom and the bust of the dot com era right?

To kind of realize that, oh, just because a website is a website, it doesn't make it valuable.

And I think all of that is being shaken out in front of us right now.

John: Yeah, that's a great perspective. That's probably the biggest thing I'm taking away from this conversation.

Just, you know, things are changing and you know, it's exciting. There's lots to be excited about as we're building and moving forward on things.

But Thorsten, I wanted to ask you if you had a read this week or anything you wanted to share?

Thorsten: Yeah, my read is Simon Willison's blog post called "Here's How I Use LLMs to Help me Write Code." He published this a couple days ago.

For those who don't know Simon Willison, he's been blogging about LLMs and he doesn't, I don't think he even calls it AI now that I think about it, but he's a technical person.

He wrote Dataset, I think. He's the creator of Dataset, the Python tool. He's big in the Python community.

He is a programmer, he knocks out tools left and right.

And for the past two years, he's been, you know, talking about models like the new models, how to run them locally, how to use them on a CLI, local models, or Ollama CPP, all of that stuff.

And he's a special person in this world. He's calm, he's reflected, he's no hype, nothing, but he does have a good technical understanding of how these models work and what they can be useful for.

So this blog post, I think it's something that a lot of people have been asking about. Maybe they didn't know that they were asking about it, but I think a lot of people should read this.

And in this blog post, he talks about how to, you know, set the reasonable expectations. I'm reading through the headers here, right?

Context is king. Ask them for options, tell them exactly what to do. You have to test what it writes. Use tools that can run the code for you.

And this is all practical, as practical can be advice of somebody who's used these tools and knows how to get something out of them.

And all of that stuff is something that I would sign, you know?

John: Right.

Thorsten: There's this misconception that people think on day one, they know how to use these tools and that's not true.

It took me at least one and a half years to have this moment where I realized, oh, this is how I should approach this.

And it even, it took me, you know, fine tuning a model. It took me writing tests for models, using them with temperature zero and using them in production to realize that oh, they can be programmed.

It's not just a lottery ticket. And sometimes you win, sometimes you lose, try again and maybe put like an exclamation mark here or move this over here or something.

No, there's, I wouldn't say I can predict how good prompts are performing, but I will say that some people know how to prompt these models and other people don't know how.

And I think what he's describing is a lot of practical advice that helps you get more out of this.

So I sent this on the Sourcegraph Slack. I'm going to put it in my newsletter.

John: Yeah.

Thorsten: It's a really good blog post.

John: Yeah, this was an amazing piece. And he's quickly become my like go-to source at the Linux foundation as well for, you know, like, read this, if you want to learn a little bit about prompting or read this thing from Simon about, you know, his evaluation of Grok or something.

I had a very similar experience where it, it really took me building, you know, AI agent stuff when we were at OpenSauced to really start to understand like, oh, this is kind of how you can heat up and engage really the neural network that underlies the whole architecture of these things to get it to go down the path of that graph that you need to essentially is really how I kind of started to think about, you know, what these things really are.

Thorsten: You know, the people made fun of, oh, prompt engineering and whatnot.

But like I urge anyone to build, say a test that ask an LLM something about something and then modify the prompt and you know, you want this in a loop.

Like you want it to be easy to retry and then truly like say, I don't know, give a prompt to the model and say, here's a piece of Go code and it has a bug in it or whatever, maybe doesn't have a bug, maybe something else.

And give it say 20 lines of code and ask it how would you improve this? Or what would you change? Or something like this.

And then play around with the prompt and start with that stuff that everybody laughs at. You are an expert programmer.

Or say you are John Carmack, or you are Russ Cox, you know, or you are a security engineer.

And you will then turn the temperature up and down, and you will see that stuff change.

And you will see that if you stay with one prompt and the temperature's down and you rerun it, you still get some variation from it, depending on the model, but you start to get a sense of how this stuff behaves.

And then you start to see that what you're really doing is like you're throwing these marbles into this big Rube Goldberg machine. And yes, it's a complicated, big machine, and all of these millions and billions of matrix multiplications. You might not be good at predicting where the marbles come out at the end, but you will get some intuition of how many marbles and where you're going to put them in. And then based on that, where they might come out.

And it's not an exact science, right? But I urge anybody to try this and to get a feel for this.

John: Yeah, very, very well said. Well, that's all the time we have for today. So listeners, remember, stay ready.