The Changelog: Software Development, Open Source - Goodbye Atom. Hello Zed. (Interview)

Episode Date: March 15, 2023

This week we're talking with Nathan Sobo about his next big thing. Nathan is known for his work on the Atom editor while at GitHub. But his work wasn't finished when he left, so...he started Zed, a high-performance multiplayer editor that's engineered for performance. And today, Nathan talks us through all the details.

this week on the change log we're talking to nathan sobo about his next big thing nathan is known for his work on the adam editor while at github but his work was not finished when he left so he started zed a high performance multiplayer editor that's engineered for performance and today nathan talks us through all the details. A massive thank you to our friends and our partners at Fastly and Fly. Our pods are fast to download globally because Fastly, they're fast. They're fast.

They're fast globally. Check them out at Fastly.com. And our friends at Fly help us put our app and our database close to our users. No ops. Check them out at fly.io. So on June 9th of last year, GitHub officially said farewell to Adam, the beloved text editor. Not me, the editor.

The Atom, not the Adam. Atom editor, yes. And when I saw that farewell, I immediately thought of Nathan Sobo, who we had on the show back in 2017 because Adam was a lot of your work there at GitHub. Welcome back, Nathan. Thank you very much. Yeah, I

have thought of you guys too over the years many a time. Aww. Thank you. And I even re-listened to that podcast that we did. How was it? It was good. Yeah, I felt like we all did a great job. Excellent.

Sometimes I dread going, especially back to the really older episodes, to hear because we think, oh no, those noobs. Although 2017 wasn't so long ago. We can go back. It wasn't, but we've evolved a lot since then. When I hear that rock intro, i know it's a version of us that's like just in the past but not terrible but not our best your hard rock days yeah it's uh well we just had this like uh we wanted to come in with a bang you know it wasn't necessarily like oh we're into metal or something like that

we wanted to sound like right get amped get hyped hyped. This is a fun thing. But then people told us that we weren't very approachable. Because it's like, is this like a heavy metal? For sure. You know, is this hardcore? I don't want a hardcore tech podcast. I don't know. So then we hire a brake master cylinder. And that's the history, basically.

That's the long story short. Real quick, as we talk about history, here's ancient history. I don't know if you know this, Nathan, but Adam, I know you know this, because we were just talking about it recently. There's a new movie coming out on Apple TV Plus called Tetris. And it's a fictionalized, dramatized version based on the true story of Tetris and how it was brought to market. And the main character in that is Hank Rogers, played by some actor, I don't know his name. And it just so happens, we're talking about ancient history,

that Adam, not the editor, but Adam Stachowiak, interviewed Hank Rogers on Founders Talk episode seven back in 2010, ancient history. And he told, Adam, you told the Tetris story before it was cool. Yeah, man. So did you go back and listen to that? I't but i remember it very fondly and that was quite fun because you know hank i mean let's tangent this for just a moment because yeah hank shared the history of like alexi and this initial ip issue and like international law and being able to sort of get

the rights to tetris to not so much just simply own it, but be able to put it on all these different platforms is now on today. Like the Tetris we all know because they worked so hard, they fought so hard to like get back what was rightfully theirs. And Hank was a large part of like helping Alexi and the whole process come together because they were just committed to this game from the the rules to the gameplay to the platforms all that it was just an interesting story really so interesting that they made a movie out of it's coming out soon and that's just cool like the main character in

this movie you interviewed him over a decade ago and got the story i wonder if they should like buy the rights from us for this we go get some royalties you're gonna royalty check out of the sucker what's gonna mention at least you know change out of this sucker? Let's get a mention, at least. Change a lot of that FM. Yeah, let's get a mention. Maybe in the credits. Yeah. Something.

Anyways, that's even further back, Nathan, than your 2017 interview. But back then, we were talking about Atom. I think VS Code wasn't a thing at that point. I don't remember when VS Code actually came on the scene. I think it was. Yeah, I think it was. Yeah, I think it was probably around, but hadn't taken off. And obviously GitHub had not been purchased by Microsoft at that time.

A lot has changed since then. Adam was very much Chris Wanstroth's idea. He had a nice Twitter thread recently kind of telling some of the story of Adam. But you were crucial, and maybe even lead, I think, on the Adam editor inside of GitHub, which was groundbreaking in many ways and paved the way for VS Code, right? And electron-based browser tech editors. Is that fair to say? Yeah, it is. I mean, I remember Chris and Corey, they were like a few weeks in at the time I joined. And they had this WebKit, the old WebKit framework that you could pull into Mac apps, let you kind of drop down into Objective-C. And so Corey had wired up these IO APIs.

But one of the challenges we ran into is like we didn't have access to the npm ecosystem and so from pretty early on i was on this mission to figure out how to get you know node integration so that we could access all the npm libraries and i thought oh it'd be cool if we just had kind of node smashed into chrome because i you know chrome uses va like we were trying to figure out how to do it. And I don't know if you want the full story, but we ended up, I think I told you the story in the last podcast of finding Chang barely able to communicate through this language barrier, but enough to be like, here's what we want. You know, Node and Chrome having a baby. Right. And that became Electron and the rest is history. But yeah, the story of Zed is kind of funny because having, you know, sort of brought about the advent of Electron, we became really frustrated with the limitations of working that way. Yeah.

And, you know, that's a big part of why we started on the path that has become Zed. Yeah, so we go back to June of last year when that post came out by GitHub saying, although Adam was kind of dead on the vine for a while, the writing was on the wall. It was just like they had to officially make it official. And at that time, you tweeted, as Adam's sun sets, Zed's sun is rising rising we are not done here so I love this this is like a sequel you know this is like okay one ends and the next one begins when was his tweet Jared as

Adam's son sets Zed's son is rising we are not done here when was that tweet uh June of last year oh wow okay this was like right around the, yes, June 8th, 2022, right after they announced the farewell. Very, very well played. That was poetic, Nathan. Nice one. Thank you. Just came to me.

And at that point, I'm like, we got to get you back on the show. And then you're like, let's do it. But we're not quite ready yet because, yeah, Zed's sun is rising, but it's just a tip over the horizon. We're not ready to actually launch this sucker until now so here we are zed is now out there and available as a beta and we're excited to talk about this as you're kind of your round two right at this text editor game yeah that's right it's great to get an opportunity to do a lot of things right and learn a lot of lessons from Adam and carry them forward and do what I think is a much better product or has the potential to be what I've always been shooting to build, which is version of the mission? And then, you know, kind of the, did you begin with first principles with this mission? Obviously, you began from zero, right?

I'm assuming this at least, because that would make sense. Because before you didn't begin with zero, you began with electron and the constraints there. Where did you begin here? What's the mission and where did you begin? I mean, the mission is sort of the same as it's always been, which is to build this extremely well-crafted, lightweight, fast, extensible eventually, but not now, but also collaborative tool. that developer space is just our ability to effectively communicate about code with each other. And there's just so many conversations that I think makes sense to have around code. I came out of Pivotal Labs. That was a culture where we literally sat and coded together for 40 hours a week. I don't really want to work that way anymore, but it really did

indoctrinate me into the value of just having conversations about code. And that's always been a big part of my toolkit, but it's always felt like a big gap for me in the tooling that was available. If you want to write a bunch of code by yourself, push it up, and then have a conversation just about the changes you're introducing to main or whatnot, then pull requests work really well. But there's all kinds of conversations that I think could be facilitated around code that just really aren't. And so that was kind of what I pitched Chris on when I joined GitHub is this idea of a social code editor, the time like that the tagline

of GitHub was social coding. And I just thought we could take it much further. But I think what I didn't necessarily bargain for was just the pure difficulty of building a good code editor at all. And then taking on the crazy level of extensibility that, you know, that was really what Chris was excited about more than anything, is just making this thing crazy extensible like a modern emacs and you know i took that and ran with it as hard

as i could as well you know creating electron and embracing npm and all that but by the time we just got through like learning everything we needed to know to build a an excellent editor and then investing all that time into extensibility. It wasn't until, I think, after our interview that we really sunk our teeth into, okay, how can we help people talk about code in this tool? And I think it was spring of the following year that we decided to, the year following our podcast,

so that was 2017, we decided to build what became Teletype, which was the collaborative coding package for Atom. And Antonio and I dove into the academic literature. I'd heard a little bit about OT and CRDTs, but didn't know much. And we went from knowing almost nothing to shipping a product in like six months we were just

crazy like you know i went to italy and worked with him for a while and like we were just worked so hard on that and at the end of that i took a step back and was like we're finally the engineers we need to be to actually build this thing that i've been wanting to build all these years. And we need to start over. Dang. Ouch. That's kind of okay to some degree, right? Like you kind of build up your skin, you build up your knowledge, but then you realize like everything you've been,

you've been going the wrong direction essentially. You need to begin again. Yeah. Yeah. And it wasn't necessarily like it was all wrong or all terrible but it was also just really clear to me based on all the battle scars i'd acquired and the experience that i had at that point but like we couldn't get where i wanted to go from where we were and i didn't want to let it go so yeah that's when we started on this project called X-Ray.

I called it X-Ray because I didn't want to call it Atom 2.0. I didn't really feel like that'd be great for the Atom community, and I didn't really have authority to do that at GitHub. That was always murky. What I did and did not have authority to do was always kind of undefined. We were kind of this little team under the umbrella of this much larger larger organization so we call it x-ray which is kind of like what you get upon the splitting of the atom you know the uh and i remember i you know we were we decided to do it in rust which meant we had to learn rust which was

no i don't know that was a hell of a learning curve, say that. And yeah, we just started building it, Antonio and I. We stood in front of the whole Atom team in January of 2018 in Boulder. And I remember giving this presentation about the kind of responsiveness that we really wanted to achieve that we thought would be what felt amazing in an editor and all these other architectural details of what we thought made sense. And I don't know. Yeah, it was pretty shocking to the team at the time that I was sitting up there saying this. But yeah, we started in and I remember writing these notes in the repo that were just kind of intended for product managers

and people at GitHubithub just so that they could maintain awareness of what we were doing but it was all open source and at some point some people found these notes and we got this little following of people that would just read these like random notes i would toss off at the end of each week and yeah but then i don't know we kind of got like batted around by different political winds inside of GitHub. And at some point, it became clear that there wasn't really an appetite for an Atom 2.0 within the company. I left for the birth of my second daughter. And when I got back, Microsoft had acquired the company, and it was clear it really wasn't going to happen.

And so that's when I just switched teams. I worked on webhooks because at that point, GitHub's webhooks were still being delivered by a bunch of single-threaded Ruby processes that were each consuming 700 megs of RAM, just blocking, sending HTTP requests out. So I went and did that but in the in my spare time antonio and i started set basically because i just couldn't i couldn't let it go i tried like there was a period of time after adam where i'm like maybe i should do something else but every time i think of something else to do I would like at that point I'd actually switch

official studio code because it was a better tool for rust and go etc and that cursor would be there blinking just being like you aren't done yet you aren't done yet like mocking me it's the drum yeah boom boom boom yeah telltale heart or something so i mean you asked about the mission and i kind of diverged off in it no that's good different direction but i feel like it's always been the same mission kind of yeah which is you know this lightning fast extensible highly collaborative tool i'm glad you shared the part of where you were at when github was acquired because i kind of feel like that's the case here every time time we have a hubber on the show, it's like, okay, whether you're there now,

you're in transition, like Rachel was when she came on the show, or like Nathan's case, he's since left. Where were you when GitHub was acquired is sort of like my undercurrent of questions. Because then you were so knee-deep into Atom and obviously you have this passion for it. And it's interesting even that VS Code was similar in nature in terms of build because it was also built on Electron early in its day.

I don't know the case to this day, but like, why did it win? I think it still is. Is a question. Okay, there you go. So it would make sense, you know. It's like, well, how did, you know, VS Code win? Because obviously Atom lost based on the sunset. 100%. It's just, it's like, well, how did, you know, VS Code win? Because obviously Adam lost based on the sunset. 100%.

It's just, it's an L in that case. That doesn't mean the work you did was, you know, an L. It means that, you know, the fight, there's awards, like browser awards, there's editor awards. I mean, somebody's got to win, somebody's got to lose. Right. I'm not meant to words here. So, you know, you think like, okay, where were you when GitHub was acquired? And then two, well, why did VS Code win and Atom lose when you had the same underpinnings?

So my understanding of the situation and it's basically like we created Electron and came up with this Microsoft that was doing Monaco and doing like Visual Studio Online like a browser-based version of the editor that team included like Eric Gamma who worked on Eclipse etc but when they saw us doing Electron they and we open sourced Electron that was this opportunity like oh we see taking off. Let's sort of take this tech that we're building on the web and fuse it with what was at the time called Adam's Shell. I don't think we've renamed it to Electron yet. And yeah, that kind of gave them this head start. So I think there was a big advantage of coming with some existing tech, some existing experience, and then having us sort of taken all the arrows, figuring out how to get Electron done. It was like a pretty good flanking

maneuver. But then I think a lot of Adam's wounds honestly were like self-inflicted on a number of levels. Like I made some mistakes and I think one part of it was just like never having clear leadership. Like I was kind of by the end, the end, I'd been there from the beginning to almost the end. I was the longest serving member of the team, but I never had any official authority on the team. just like you know having started in the dark ages like we started in coffee script it took us too long to switch to javascript we should have gone straight to typescript so like just using you know in inferior tools and never it's never the right time to like take a step back and be like we should level up our tools we should pause do what we need to do to switch we're going to take a short-term hit and move forward. We never really pulled the trigger on that. So that was a mistake. And then we just focused so

much on this very broad definition of extensibility of like, you could come in, run your JavaScript on the main thread and you could do anything. And I think Microsoft's approach was a lot more conservative and a lot more focused. But of course, they were coming from the position of working on IDEs, working on the TypeScript tooling. And so I just think from their perspective, the language server protocol

and focusing in a more pinpoint way, precision way on the specific types of extensibility that would matter, you know, gave them a big advantage because it's hard to maintain all that surface area. It takes a lot of time and energy and resources. And then, you know, early decisions we had made that like weren't the most performant were sort of sealed in concrete by these API contracts we had made. So, you know, a combination of just like, yeah, I don't know. I mean, a lot of the things that made Adam exciting were also the things that made it tough to compete, which was just the freedom that people had to do anything. I mean, I remember supporting a team at Facebook working on Nuclide. Adam was the basis of all the tooling

at Facebook. And that was a much bigger team than our team. It was just like a weird situation, right? So with Z company that we would aim to be self-sufficient around this tool that had a clear leadership structure that sort of me, Max, and Antonio were, my co-founders and I were clearly in charge of. So that if a decision was made or not made, that was like our responsibility and there was no doubt about that. So from a structure perspective that was one thing but then just like i felt like we'd really reach the end of the line on electron and on javascript like you think about a tool is sophisticated as a code editor you don't have time to like pause and clean up garbage or use a language that's just like kicking out garbage constantly and and confined to a single thread unless you're going through some pretty complex

gymnastics to like spin up worker threads that don't have shared memory etc it's just like i don't know i thought i thought that we had pushed javascript to the absolute limit and then beyond you know doing things like v8 snapshots to start up faster and just crazy. Yeah, we just, we're like, we can't do this anymore. So switching to a better language and Rust to hit 1.0 in the meantime. And I'd been following Rust for years being like, this seems like it could be the right tool

to solve the kind of problems we have. And then there was just just like making sure that we had a solid core product that met a lot of people's needs like right out of the box in terms of the languages they wanted to work with interacting with the language server protocol just having all the pieces in place and fast and polished and dialed in before we even worried about extensibility at all. Like when the iPhone came out, it did a couple things like made calls and you could browse the web. And it wasn't until a little bit later that they launched extensibility. And so that's the strategy we're taking as well.

Like, I mean, I am one of the creators of Atom. Obviously, I love extensibility. That's a huge value of mine. But Zed, as it comes out in this initial beta launch, really, it's not extensible. That's something we'll add. But we want to make sure that we get that core experience right so that when we start opening up those contracts, which are going to be much more judicious about, we know that the core is solid, but we don't need to go back and change anything and violate those APIs. Well, I think you're spot on there with regards to the order of precedence of things that

you need to get right. As a user, if I took those three things, performance, extensibility, and collaboration, and I said, which order do you want them in? That's the exact order that I want them in. And so many tools, to this day, I'm a Sublime Text user because for me, I use Vim in the command line, but for text editing in Sublime Text, because it's just faster.

It's faster than VS Code. It's faster than Atom used to be. I liked the ideas behind Atom. I loved the extensibility and just the whole, it's web tech, you can hack it yourself. But it was always just a little bit too slow. VS Code feels the same way, especially when I start searching and navigating files.

It's just a little bit slower. And so performance for me, it has to be there. It has to be there. And then extensibility is awesome, but comes next. And then for me, because I code mostly by myself, collaboration, that kind of stuff is like for me, because I code mostly by myself, collaboration, that kind of stuff is like, yes, I could do better. Yes, I'm an outlier because most people have teams, but not as important. I'm curious though. So this x-ray work that you did, one of the things about

Zed and this breakthrough performance that it has, according to the website, I've only used it for 15 minutes. It does feel fast, but it has this built like a video game thing. So you're doing this whole, because it's like, well, how do we actually make it fast? And you could say rust, but it's like, OK. That's not going to get you all the way there. It's going to be faster than V8, maybe in some context. But this 2D rendering GPU thing, does that come out of your work on X-Ray? Is that a brand new thing you guys

built for Z? In other words, is it just like a spiritual successor, or is there actually code that you built on this version 2, Atom 2.0, which was called X-Ray, that made it into Z? There's a tiny bit of code. It was all open source.

Super clear there. Nobody sue us, but a tiny bit of code from X-Ray involving some of the core data structures around the buffer, the text buffer. I'm not sure if we either made its way in or we re-derived it based on that knowledge. But most of our approach to UI that we took in X-Ray, we discarded because it didn't work, actually. So a big thing that Antonio and I did in those first several months, nights, and weekends working on Zed was taking a step back and figuring out how do we do a graphical user interface in a language with the constraints that Rust imposes

around ownership, where everything needs to have one unique owner, and it's very you know once you'd have everything be this directed graph where everything is downward right a tree structure of ownership and of course there's library types like arcs and stuff that allow for shared ownership but every time you introduce one of those you introduce awkwardness and the potential for runtime panics if there's like a double borrow etc so like that was the first big problem we needed to solve is like how do we do ui and so initially the foundation of gpu i we thought well maybe what we could do is still have electron do the rendering for us like just that last little bit and so the core of zed was actually we tried a couple different approaches

one was like embedded into electron as a library and then the other was actually running as a separate process and the views would like render json which would then be consumed by react on the front end and would render the ui and so we put all this work into the core of the system written in Rust with painstaking attention to our algorithmic bounds and et cetera. Right. And then the JSON would get to the JavaScript and we'd just throw it all away immediately. Right. data and then like recalculating styles reflowing the dom like no matter what we did we just couldn't achieve the performance that we wanted even you know starting from zero and doing as much as we could at rust and so at some point where it's like i don't know i was afraid of

doing our own ui honestly to some extent because it just seemed daunting like it just didn't even seem like a reasonable thing to try uh to me but at some point it's just like well there's no point in doing this if it isn't super fast and like this is not fast like and so finally it was just like we have to abandon electron we have to do the graphics ourselves and i'd never really done any graphics programming we played with it a little bit during X-Ray, like doing like WebGL stuff. So yeah, we started with this Rust crate called Pathfinder,

which is Patrick Walton wrote it. Really cool ideas in there about doing like Bezier curve, 2D rendering on the GPU. But that was too slow. And so finally, we just boiled it down to like, well, what do we actually need to draw like what is a 2d ui and it boils down to like some rounded corner boxes with borders

and padding you know like drop shadows we need to get glyphs and icons on the screen you know there's like a pretty limited vocabulary that we knew we'd need to have. And so we ended up just like writing our own shader code. And to this day, it's like we have like maybe 600 lines of shader code. The UI library is pretty large, but like in terms of the actual code that needs to run on the GPU, because the primitives involved in a 2D UI are much simpler than a 3D game with, you know, photorealistic waterfalls or whatever. You know, like, it's actually pretty simple, the code we have to run on the GPU. It's all the code

around that, that, you know, efficiently gets, you know, from a mouse click to like, what happens to pixels on the screen. A lot of the innovation, I think, is like code that runs on the CPU that kind of gets that data into the GPU's memory. But yeah, that was the path of just relentlessly saying, until this is fast, we haven't solved the problem and we're going to do whatever we need to do to get there. This episode is brought to you by our friends at Postman. Postman helps more than 20 million developers to build, test, debug, document, monitor, and publish their APIs. And I'm here with Ken Lane, Chief Evangelist at Postman. So Ken, I know you're aware of this, but companies are becoming more and more aware of this idea of API-first development.

But what does it mean to be API-first to you? API-first is simply prioritizing application programming interfaces or APIs over the applications they're used in. APIs are everywhere. They're behind every website we use, every mobile application, every device we have connected to the internet, our cars. And what you're doing by being API first is you are prioritizing those APIs before whatever the application is that is putting them to work. And you have a strategy for how you are delivering those APIs. So you have a consistent experience across all of your applications. Take us beyond theory. Break it down for me. What changes for a team when they shift their strategy, when they shift their thinking to API-first development? So when your one team goes, hey, we're building a website, it's got an address

verification and part of an e-commerce solution, that web application is using the APIs to do what it does. And then when another team comes along and goes, hey, we're building a mobile application that's going to do a similar e-commerce experience and may use some of the similar API patterns behind their application. They need address verification that that's a consistent experience. Those two teams are talking rather than building in isolation, doing their own thing and reinventing the wheel. And then when a third team comes along, needs to build a marketing landing page that has address verification, they don't have to do that work because those teams have already collaborated, coordinated, and address verification is a first class part of the experience. And it's consistent no matter where you encounter that solution across the enterprise. And that can apply to any experience, not just address verification.

Very cool. Thank you, Ken. Okay. The next step is to go to postman.com slash changelogpod. Again, postman.com slash changelogpod. Sign up and start using Postman for free today. Or for our listeners already using Postman, check out the entire APAP platform that Postman has to offer. Again, postman.com slash changelogpod. This GPUI thing is a brand new thing. Is this something you all invented? You kind of glazed over it quickly and explained it, but like give us the deeper notes on GPUI. Yeah, so GPUI is an application framework, a UI framework that we basically created

because at the time, what was it, like 2019? I think there were some experimental Rust graphics libraries out there, but none of them that we looked at really solved all the problems we knew we would need to solve. And just from a stylistic perspective, if I can't pick up a thing that does the things I needed to do, then I'd rather build it myself so I really understand it and I really have control of it. I can map it to my intuition. So GPY covers just the shell of the app so interacting with the platform APIs to like pull up windows etc like we did that ourselves

and then you know once we have like a window open it's just like a giant right now metal canvas that we're going to render graphics into but there's also just like how do you structure the views so it's based on data flow rather than control flow so So what does that mean?

Well, Rust's ownership rules are really strict. So we have this kind of global object that owns all the top level views and models. And then the views and models can kind of interact with this global object via the standard protocol where, you know, like say a user clicks, that's modeled as an event that calls an action on a particular view. And we call that into the view and then the view can do whatever it wants. And when we call that into the view, we kind of yield the guts of the application to the view. And so if the view wants to emit an event, it says, Hey, I'd like to emit an event. And then control flow returns back up to the parent object.

And then we move that data to any of the subscribers of that event. And so like in a language where like ownership is more promiscuous, like JavaScript, you might model an event as like, oh, on click, I'm going to attach this closure here. And inside the closure, I'm going to implicitly capture this, which creates like a cyclic loop, right? And so when the click event happens, I'm just going to loop through all the event handlers and call them.

But in Rust, like ownership is one way, like that model of like attaching a click handler that like calls a method on you, it creates these cyclic data dependencies, like that just doesn't work. So that's a big part of GPOI, sort of how do you structure the application logic, the models, the views, et cetera,

so that you can have these bidirectional interactions, which are really common in UIs. Like I open a modal, then the user clicks the X on the modal. Well, the thing that opened the modal needs to know about that so it can hide the modal. That creates this bidirectional relationship. So a big part of GPI is just like a scheme for modeling bidirectional data relationships between these big views and models in the app. And then there's another big piece of it, which is, okay, once we have updated

the state of a view, how do we represent that view on screen so there's this concept of a tree of elements which is like kind of inspired by react but the difference is that in react you're sort of like you have the virtual dom and they're diffing it with the underlying dom and then that produces some mutations to this like retained mode representation of the state of the UI. And then a bunch of other stuff, et cetera. There's this big chain that occurs where instead, any time any view updates its state,

we basically re-render the entire window. So we build this tree of elements, and we do a pass from the top that lays everything down. And this is inspired by Flutter which like we found via the writings of brave levine uh so yeah we do this layout pass down that tells that says the constraints how big or small anything can be then everything passes its sizes up so there's one linear layout pass and then one linear paint that like populates this cross-platform scene representation. Then we go straight into the GPU memory and draw it. And so we bypass all this nonsense that occurs on the web.

I mean, this model of the web vastly predates like the availability of GPUs and just introduces a lot of complexity that's not relevant to the problem we face of like keystroke to pixels i i get a keystroke i want pixels on the screen on the next frame and so yeah gpi is the system that we built that kind of aligned with our intuitions and everything we've learned about doing ui and i'm sure there's many ways to do it but this one's ours and it's worked pretty well for us. That sounds like it would be platform specific.

It's not. It's not. Because as of the beta, it's Mac OS only. You are working on other platforms, but it's not. It can work on a GPU on any common architecture. I mean, there's nothing. So like at the moment, we're only on the Mac. And why is that?

That's because I am a Mac user. And so when I was working nights and weekends on Zed, that was where I started on the machine I was on. But we designed GPY very deliberately to not really be platform dependent. All of the platform specific pieces are isolated into small interfaces that should be able to be ported quite readily to other platforms. We haven't done that yet because we're still really early and we want to learn as much as we can and develop the product as much as we can in a focused way. And it kind of just feels like adding another platform is going to add a lot of surface

area to maintain without a lot of new learnings in terms of like the product itself. And so that's why we're just staying focused on the Mac for now, but it's our intention to release on Linux and Windows prior to dubbing anything 1.0. I think anything called 1.0 would include those things. And I think we're well positioned to deliver there as well as on the web.

As well as on the web as well as on the web okay taking it back to the web so when i think about zed i think i try to put myself in your shoes and i know that you had this like cursor staring at you like blinking just making you do this but you know zed is being born into a much different landscape than adam was born into very much when adam was created, there was kind of a dearth of innovation in the space. I mean, TextMate had gone silent, right? Sublime Text had come in and then kind of,

they would release, they still to this day, release like once or twice a year. And it's like, they have some builds you can get on. But it was just kind of like not much new. Then you had the hardcore Vim and Emacs people who are just still using Vim and Emacs to this day and always will. And NeoVim came in at some point and kind of stimulated some innovation in the Vim space. But then VS Code came and really sucked a lot of the air out of the room. I mean,

they are the juggernaut now. It seemed like it happened relatively fast. Microsoft put a lot of weight behind that project and executed very well, as as you mentioned some of the things they did and so success to them that's all good but now here comes zed and i'm thinking like would i want to compete with in this landscape today with a brand new thing maybe i would sounds like maybe it's a nice challenge but also sounds kind of daunting and then i thought well the text mate guys guy i don't know who yeah how big that team is. I think it's very small. And the Sublime Text people, which there's like three, I think, like they're making a good living, right? Like they are selling licenses for a hundred bucks a shot and you're not going to take over the world, but they can be happy writing the code they like to, you know, helping their

users. And then I see you raising money and building a team and I think, well, that's not the route Nathan's going. So you're kind of going bigger. Maybe it helps share your mindset around what Zed's trying to become, the landscape and how you set yourself apart inside against VS Code now to carve out your own user base

that's big enough to support a growing company with debt, so to speak yeah absolutely uh well we raise equity for what that's worth but um okay but uh but i get it yeah no debt yeah um equity partners who would love their money to come back multiplied exactly yeah uh and i you know i don't accept investment without an intention to return on that investment. So I definitely would like us to. And quite frankly, I think that code editors in general, like the entire space, would do well to have a kind of native business model, if that makes sense. Because for all the value that software brings to the world, I think that the front line of where software is written doesn't see enough investment and innovation. Because

historically, I think it's been hard to monetize. So JetBrains is the one company in the space they're 20 years in. And I think they've managed to gain a foothold with this kind of license-based models. You have these lifestyles, scale businesses like TechsMate or Sublime that are operating with small teams. Or you have the big corporate patron model, which was Atom and VS Code. And I just think that will be best served as an industry

if we can come up with a business model that's really a flywheel that's generating value and finding a way to capture enough of that value to continue to generate more innovation and really level up this piece of the developer tooling stack. So I think we need it. In terms of like, yeah, you bring up, I don't know that I would want to compete like in the landscape as it looks today. And like, for me, from a personal,

like my personal, like deep down personal motivations to do this. If I saw an editor out there that like, I was happy to use and felt like really nailed my definition of the ultimate editor the perfect editor then i would not need to compete like i'd be good okay but just from a personal perspective it's not like i like surveyed the landscape and was like let me find a low-hanging fruit to pick it was much more of the perspective of like i've been trying to do this for 10 freaking years still haven't managed to do it and nobody else has either and so i just have to keep going now you'll have to talk to our investors

uh you know for their particular motivations but i can tell you what i told that and really believe in terms of what the market opportunity is today in terms of you know again if i i think if i if i were in this for the money i probably would have started like a crypto token or something you know like that would have been a faster route to riches but like i do think it it makes sense to to build a business model around this and for me the opportunity is really about how we all communicate around code. Like, I mean, I worked at GitHub for nine years. I love GitHub, but I also don't feel like there's been substantial innovation since like pull requests came out all those many years ago.

And I think it made sense at the time to kind of hang the social layer on top of the version control artifacts. I just think we can take it much further. I mean, that's what I pitched Chris on to kind of get hired at GitHub and we didn't manage to pull it off. But now I think based on everything we've learned, we're actually positioned to do that. And so like, what I really want is a world in which having a conversation about any line of code, whether it was, you know, written a couple of years ago, or I just wrote it, and I haven't even hit save, is something that just feels like at my fingertips, like an app mentioned a teammate, pull them in, and like start a conversation. So that conversation is really growing over the entire code base. Because again, you want to introduce a new feature, that probably interacts with some other layer of the system that you may not understand.

Already you need to start having a conversation. But do you do that on a pull request? You haven't even written one line of code yet. You're just trying to understand what's going on. And so there's just so many things like that where it would be a great idea to have a tool that really facilitates interaction around code and it just doesn't exist like i don't know what we did we'd like paste code into slack or like have things inside of backticks you're talking

about code that isn't even there and then it scrolls off the screen and it's like gone forever when someone else comes to the code it has the same exact question that you had? Or are you hopping on a Zoom call and now one person is dictating through the screen like, oh no, no, no, okay, open this file. Okay, now go to this function, right? Whereas already in Zed, we've tackled

the real-time piece of it. When we want to just have a conversation about code, we're doing that in Zed, so we'll start up voice. That's not in Zed yet. So we still rely on an external tool to do the voice for us. But then I'll just open up this menu, invite one of my teammates in,

and we're following each other around inside the code. Instead of trying to dictate through the screen, like, oh, here, type that, because the latency is so high or whatever. I'm just moving around and they're following me, then they're moving around and following me. So I remember when Michaela, engineer on our team, she was integrating the terminal into Zed.

She was interacting with GPUI and there might've been some APIs missing. She wasn't quite sure. So we had a conversation and I toured her around inside of GPUI, which I wrote the majority of. And then I followed her and I toured her around inside a GPI, which I wrote the majority of. And then I followed her and she toured me around inside of the terminal code. And then I got a sense of what she was trying to do. And then I jumped back into GPI and we wrote the code, added the methods together that needed to exist for her to accomplish what she was trying to accomplish.

Then we hopped back into her code, which she knew much better than me, and use those methods. And in an hour, with a quick conversation, we accomplished what over pull requests would have taken a week, I feel like. And so that's the level of fidelity that we're looking to bring to interaction around code, starting with real time, but not confining ourselves to that. That's, I think, the innovation opportunity. It just so happens that the primo kind of iPhone, Apple vertically integrated product that delivers that experience, in my mind, is the tool in which the code is written itself. That you shouldn't be command tab A out to a browser, that that experience should be

tightly integrated directly into the authoring environment, just like it is with Figma or Google Docs or these other disciplines that the place to collaborate and talk about code is where you write it. So we have to build a great code editor, but luckily I want to do that. So that's our competitive insertion and that's the business part that we want to build. If you want to use it by yourself, I want you to do that and do it without paying us a dime into the future. And I want to build a business

around teams using this tool to be more productive by having a better mind meld with each other and being more productive or being more effective in their communication that funds the people

that just want to use it by themselves for free and drives more innovation into the code editor space than has ever been possible ever been funded as jared said you are up against a daunting task i mean vs code is quite entrenched oh yeah some of the greatest minds working on it working in it we just had a conversation around dev containers, which was built right into VS Code. It could be built into Zed as well. Pretty easy, I'm sure, because it's open source

and the CLI is there and the APIs are there. But that's a task. The business model seems sound. We've definitely heard the Teams aspect before, and it's nice that you want to give the editor a way, as you said, in quotes, for free, to anyone who wants to use it in perpetuity because you want to build a better code editor.

Something that when you click a button or push a key that the very next frame, it's there. And that's amazing. I do want to mention though, because you mentioned Chris's name. Chris, if you're listening, it's been since episode 10. Come back on. Okay. Come on, Chris.

Chris Wanshroff. Yeah. Since episode 10 of this podcast, it's been since episode 10. Come back on. Okay? Come on, Chris. Chris Wanshroff, yeah. Since episode 10 of this podcast, it's been too long. Come back on. And we'll talk about whatever you want. But this is pretty cool. I mean, this is definitely innovation. And I think that's where we want to see things at. It makes sense to start on performance on the web page.

I think it's slash features if I'm on the right page. It's just the main page, probably. Sorry, the.dev. Yeah. Engineered for performance. You're going to leverage every CPU, every GPU, and the graph there says that Zed performs faster or as fast as Sublime Text. Three times as fast as VS Code.

And I don't even know. CLion. CLion. It's the JetBrains variant of... Okay. The JetBrains variant targeting Rust and C++. Gotcha.

Just because I think, again, like, we're not even really targeting Java right now. Like, JetBrains can have that for the time being. For the time being. I love it. Yeah. That's why we put Sea Lion up there as our point of comparison. Yeah. Sure. So let's talk about the name yeah is this a pulp fiction reference please tell me this is a pulp fiction

reference people and the funny thing is you're gonna be surprised i've never even seen pulp fiction oh my gosh okay so yeah i should watch it but anyway um so yeah someone has since informed me of the fiction reference but actually it was a a reference i was thinking about names at some point and i i thought back to the unix editor ed ed which i've always been like just fascinated by the history of unix and you know, that picture of like Thompson and Ritchie on like a teletype hooked to this PDP 11, like that goes to the ceiling,

like writing Unix on a fricking teletype printer. Right. Just like, that is so mind blowing to me. And so I love, yeah, I love kind of computing history. And I was like, maybe we could name it Ed.

And I'm like, well, that Ed still exists though, right? Like, if you open your terminal right now and you type Ed, it's an editor. I'm not going to like, it just seems rude to like shadow, you know, the editor that's still there. That's Ed that we're trying to be an homage to. So, you know, I was just thinking of, okay, well, can we name it something similar to Ed? And, you know, Bed doesn't seem like a great name. Zed is taken. Ted has its talks. There's Ted Talks. You don't want to be Ted.

Exactly. And I knew I wanted it to be short. And so, yeah, it just felt like Zed. It was a pretty good name. And like, what I like about it I just felt like Zed was a pretty good it's a good name name and like what I like about it it's like a word for a letter and I don't know I just I like it so right it's an homage to Ed and just like a cool word for a letter my daughter's name is Zoe so it's the first name of her or first letter of her name yeah first letter of hers too I think it's cool I think uh you're kind of that's like the last Ed you know you put the last letter of her name. First letter of hers, too. I think it's cool. It's like the last ed. You put the last letter of the alphabet in front of ed,

and it's like Zed, the last ed. Z-ed-ed-ed. Yeah, the last editor. I'm pretty sure this is the last editor I'm going to build. It's at least Nathan's last editor. Yeah, this is the last editor. Swinging for the fences on this one. Yeah.

So you've raised money. You're swinging for the fences. You're building a team.'ve raised money you're swinging for the fences you're building a team uh it looks like you have a decent sized team eight on the website i'm not sure if that's still accurate but something around there and hiring still are you building out a team or you feel good we are definitely hiring yeah we're interested in uh people that know rust fairly well fairly proficient in rust and uh yeah the typical ideal startup employee which is someone that's self-starting and right yeah so if anyone listening to this is into rust and excited about the things i'm talking about like we would definitely love to hear you and get help working on this thing and And next on our radar, and we need to choose the timing

right, is also to go open core. I was just going to ask you about that. That's something that we're not quite ready to do well right now, but I think that's going to really help us with hiring as well. It's not the only avenue that we want to use because obviously that narrows your pool to people who are you know able to work on code in their spare time etc and we want to be more open than that but i do think it'll give us a really good idea of like who's excited about this thing who wants to work on it and just to get some help so yeah we want to go open core there's some pieces of the system that we think it makes sense to retain proprietary the parts of the system that we want to charge money for um but we're hoping that can be like pretty small minority of the total code

that we've produced and that the pieces that we don't intend to charge for we can share more openly that's good for the community and also good for us by i'm sure there's so many itches that people that use that would love to scratch that aren't even really that big but there's so many itches that people that use Zed would love to scratch that aren't even really that big. But there's just a lot of surface area on a tool like this. So I'm not sure. I think it's the best route to get help. Yeah, this is a similar conversation we had with Zach Lloyd from Warp and their building. Oh, yeah, I worked at Warp for a little bit. A lot of the tech that they're using is actually derived from our early work on Zed. Okay.

I mean, there's definitely similarities even inside of the model. Oh yeah. Yeah. And one of the things that we said to Zach and he had to take, he took a lot of thought from there and moved on from there to think about this

is like the first thing Warp did, this is back when we did the show, I'm not sure if it still does it, was like sign in with GitHub immediately before you can start using it. And I was kind of like, eh, it's a terminal, you know? Like I get it. It needs to be there for the collab stuff,

but the collab stuff wasn't in Warp at the time, just like I'm assuming there's some collab stuff that's missing from Zed at this time. And I was kind of like, that's a bummer because, you know, this is my terminal. I don't want to necessarily sign into GitHub to use my use my terminal or sign in with github sign into warp and so I was kind of trepidatious when I saw the invite about zed of like uh-oh is it going to be the exact same setup and I'm happy to say that I'm using it here without being signed in there's a sign

in button in the corner but not required so that's a nice touch because I wouldn't want that exactly I don't know like it's really important i feel like if we can build a compelling if we can build a compelling business that needs to be something that people are excited to opt into if that makes sense i definitely don't want to like cram anything down anybody's throats right um and i don't think that that i think that would be counterproductive and it's just not necessary so yeah being legit and again like you know the same perspective with like telemetry for example like i know that developers rightfully so are like concerned about their privacy from a principal perspective and a pragmatic perspective

and so like you know our telemetry it's opt-in you go to help show telemetry log or whatever and you see exactly the stuff that we're sending right so just being like legit transparent yeah exactly just like so yeah we are trying to build the business but uh we're also developers as well and know what we would want and so we're trying to be respectful of that. Yeah, well I think the open core, the open source aspect, when you get there, helps people with adoption with regards to those kinds of things.

It's like, I'm not hardcore on everything I use has to be open source. Obviously I'm a Sublime Text user, it's not an open source product. I prefer that, especially for tools that I want to use for a long time and for business models that are VC funded or equity raised. And the business model may or may not pan out at the size it needs to in order to thrive. I don't necessarily want to adopt tools that are going to disappear on me.

And so open source at least gives you the, okay, if Zed the company dies, Zed the editor in some form that I can use can live on and somebody can pick up the mantle and run with it. Those kinds of things matter to people, I think. And so I definitely would say that's good intuition. Now, having everything be open, like you said, can ruin your business model, right? Like it can make it unsustainable if you don't do it right. So you have to tread carefully with those things. Yeah. And for me me i'd like to be as open as possible while being confident that we can build a business and that's in everyone's interests i think because ultimately i think a product like this benefits strongly obviously there are examples of editors that are completely community funded but i i believe the best result is that there's a core team stewarding the product and channeling the efforts of the entire community around it.

VS Code has that. They just happen to have a very large patron backing them. In our case, we need another plan. So the parts that we'll keep are just the parts where we're not confident that if we open them up, we would be able to, yeah, build a successful business. That's as simple as it is. You mentioned charging for teams and I guess free for individuals to some degree. Can you speak to the business model? Will it be licenses? Will it be subscription? How will it work in terms of some of the model?

I mean, we're still, I think we're a ways away from that to be real. In terms of some of the model i mean we're still i think we're a ways away from that to be real like in terms of we just got to get individual people adopting this thing it's like here's a phone but if you got nobody to call right it's not very useful so i think a big part of our effort is just you know building an editor people want to use and filling in the features people need that aren't maybe there yet uh doubling down on the things people are loving so in terms of the exact yeah my gut tells me right now it's going to be a subscription-based model similar to github etc but i reserve the right to do more thinking on that i guess or yeah i'd like to do more thinking don't don't don't set that in stone

but that's our instinct well it's not about setting us this is more yeah so the reason i asked that question is is kind of twofold one i'm curious but then two just to talk it out because i think if you want the adoption of developers then you talk about that adoption and how you plan to attract them on this show right you share where you think you're going to go not this is not where we're going to go but this is where we think we're going to go right and in a lot of cases like jared mentioned zach lloyd and you know warp and whatnot that conversation to me like we went back to some of that too with one of his developers that was at all things open we kind of talked about some of their thoughts around the business model and the fact that they're not open source and we jared and i kind of like really hammered home the last i want to say 20 minutes

like warp's got to be open source or like that that is like, you know, the thing for you to do. Now, obviously, we know open source is one, but how do you do it wisely in a way that doesn't, you know, hamstring your future possible business or not, you know just because you make something open source doesn't mean you're making the most of that community and so i think that's part of what we're focused on now is just like first get the freaking thing out there and get our ducks in a row so that we're i mean we're not going to do a perfect job but we're well positioned to do as good a job as we can like channeling the energy of people that want to participate and you know being clear on what kinds of contributions we're interested in that and yeah i mean really we may go sooner but i would really very much like to open source zed on zed meaning use some of the capabilities i'm talking about developing as a part of the open source or the experience of contributing to Zed.

Like you have a question about the code as you're trying to contribute, being able to engage with us in Zed on the code. That would be cool. Because that's really like our big vision is for Zed to be the future of open source. I mean, that's the grand slam we're hoping to hit. Okay. So, okay. I'm starting to see a little more of your picture here, because now

all of a sudden, you know, who needs GitHub? Open source it on Zed. I mean, I don't need necessarily, like, do Git hosting. Well, you said where open source is going to be. I mean, on a long enough time frame, yes. But I think, yeah, for a while,

what I'm more talking about is a lot of the interaction that needs to take place. The collaboration part, the social coding. Exactly. Around open source. I still think there's a role for pull requests. The build gets run, there's this official moment. There may be some conversation that needs to take place on the pull request. I just think there's a lot of conversation right now that isn't happening that needs to happen. That's the kind of future of open source that I'm really talking about. It's just a new kind of experience that doesn't really yet exist. Because if we were just trying to compete with GitHub, I don't think we'd succeed. And I don't

really honestly think that's very interesting. We want to do something new. Yeah. Well, the thing is that GitHub's going to be building that future as well from the other direction with VS Code, right? Right. So you're both going to be going towards a similar space. They're going to be, VS Code's going to become more and more collaborative, more and more real-time. All these things that

you're building at the same time you are, just from a completely different direction. 100%. It'll be interesting to see. Yeah, and if they get there and like, you know, if they get there and execute it really well, then, and I've built something I'm proud of and put in a good effort,

I could look back on it and be proud of it. Then, you know, I won't love that, but I could live with that. But my bet is that a small opinionated team that's really passionate and working on this for a long time is approaching it with the right tools and engineering the entire product around the assumptions of the kind of thing we're talking about has a shot at doing a better job. But we'll see. Here's the question I wonder if you've asked and how much you've thought into it. Because I think we asked earlier earlier how much you have surveyed the landscape.

And you said, I haven't done extensive. I'm paraphrasing. Yeah. But what is it that makes a developer change their tooling? Right. Specifically an editor. And Jared mentioned the list, Emacs, Vim, try hard, fail often, probably to remove that from their hands. You know, Sublime to VS Code, I think that kind of depends on the extensibility.

A lot of people move because, oh, it supports Rust, or it supports Go, or it supports my stack much better, etc. Obviously, performance is sort of the necessary core. Will you win only on performance? Probably not, right? But what is it that makes a developer change their mind, especially when it comes to changing their editor? What is it? Is it an individual? Is it teams?

Because that's part of your business model. And how that question gets answered is, it depends on many, many levels. And that's the easiest answer for developers or any question. But that's the question I think you should be asking and figuring out and having all the various permutations of that answer. Cause that's going to guide your direction as product. That's going to guide your direction as business model and how you can actually create value for those people. Yeah. I mean, I wish I understood the answer to that question in aggregate better than I do, quite frankly, like the framework that i use is you know like

linear had an article that put it really well i think structuring in terms of removing blockers and adding enablers like that sort of any product and so for us removing blockers is just like oh my linter doesn't work or you know just or i need a debugger i don't have a debugger yet so like part of our effort is just like if somebody does try it making sure there's nothing stupid in their way or just getting things out of their way that are stopping them from being able to use it but that alone obviously isn't enough we've got to have these key enablers and so for us what our enablers are, are performance.

That's what we lead with on our main page. Like, you know, uncompromising approach to performance going to whatever length necessary to make it good. Clean design, I think, is something I'm really proud of. The editor is really beautiful and also minimal, fades into the background while you're using it. And then I'm really hoping that people are going to resonate with some of the features we have and some of the features we're adding

in terms of better tooling for connecting with their teammates. So right now, those are the compelling things we're focused on. Obviously, there's new frontiers opening up in AI as well. Integrating Copilot is something that's high on our list, but obviously it goes much further than that. But at least at the moment, doing further innovation on that front isn't at the top of our list. It's really about connecting you with your teammates. So we're hoping those three things can be compelling for people, but we're going to

get into this beta and hear what people have to say and figure it out as we go. I think this team aspect is mungible. So one of the things you say at the very top of your homepage right now is Zed is a high performance, we've covered that, a high performance multiplayer, which I think is a key word there, obviously, right? Yeah. A multiplayer code editor. And so, sure, team, but in open source, like the rando out there could be your team.

So I think you need to really examine what team is because it's in air quotes, really, because it could literally be your team if you're an organization or enterprise leveraging Zed. But if you're an open source maintainer and you're adopting dev containers and you've got a code space or whatever it is, that's the world you're sort of going to because you want that drive-by contribution. I mean, you even have YouTubers out there who are examining code. What if it was like you were on Twitch and you were examining stuff and you were a high-profile influencer out there or whatever it might be and they could be touring, as you said, this keyword before, touring someone through X, Y, or Z.

Jared and I have talked about this too before. We're like, let's have somebody give us, and we've never done this, Jared. We should do this at some point. I'm sure we've kind of done it in verbal fashion. But like give us a tour through your code base. This is something I think you've done at least once, Jared, on YouTube, but something we haven't like poured deeply into but like zed could be the primary differentiator where it cannot be easy in a sense this multiplayer world this

in quotes team is something to be examined yeah and like we use the term multiplayer like very deliberately because the our vision for yeah how people collaborate is a lot more like a video game like we built the ui like a video game but like we kind of want how people work together to feel like a video game as well where like you're kind of inhabiting with all the other participants this like world and you could travel over to someone's working copy and you're just there and they are there as well and you kind of don't care like what server the dungeon is on right you're you're in this shared illusion that you're occupying the same reality and so that's yeah this multiplayer environment where people just feel a lot more present and accessible the

yeah the interaction feels higher bandwidth is something that we're going for it's not just like an avatar at a diff right well i'm not going to say the m word but i will say that at some point nathan you might need to rewrite your 2d engine and make it a 3d engine yeah i've thought about that i mean it's funny antonio um on our site we have this like graphic where you see the 2d thing and then it kind of yeah and it turns yeah turns down and rotates and everything all the different z indexes kind of blow out right and like antonio actually had to wire some code through because like all the z indexes were sort of fixed and the perspective transform on the on the geometry was just like a you know top down and so he added a little code to

like make it be able to rotate and do all that stuff and i thought oh it would be cool at some point and like another cool thing we haven't even scratched the surface of is like animations like another great thing about zed is because of the way we've architected it we can read we redraw the window anytime anything changes like we do have an idea for sort of reducing the hit area, only filling part of the frame buffer during partial redraws and stuff. But already, the power efficiency difference, you can sit on a laptop coding in Zed for just,

especially one of these new M1 or M2s, just all day long. It's already so power efficient that we haven't done that part yet. Right. But anyway, we can, you know, 120 frames a second, you know, in burst mode or whatever, run animations. And so I just thought it would be so cool to have like parallax effects when you change focus or something, or just do some interesting things that are video game like, yeah.

I would really lean into that, honestly. I would take advantage of the one thing that Electron's probably never going to be able to do and that you guys are built to do. Because think about it, this is what made Snapchat so interesting at first, was their filters. And it's by definition superficial stuff, right? But it's cool by definition like superficial stuff right but it's cool fun crazy stuff that that makes it interesting and people say what editor are you using like

all of a sudden you have a tiktok where i remember there's this vs code thing where it's like a fireworks that would happen when and it was cool and people shared it around but it's kind of dorky and low res and slow, pixelated. And if you could do really cool stuff, Minority Report style inside of Zed, just because you can, kind of like how the Teslas can dance or whatever, just because they're like,

why not make the thing dance? Because that would be cool. There's actually, might have some nice network effects to where people are like, just go download Zed, you can have it on your computer too. Okay, why not? And then they get there and they're like, oh, this editor is actually pretty nice.

Maybe I'll keep using it. So I think that would be fun and interesting. Yeah, I had that same conversation with myself kind of just a few weeks ago. Like, God, that seems kind of frivolous doing something like that. Even though I'm like, but wouldn't it be cool? cool and like right yeah because of how zed is built nobody else can really quite do it the way that we can so yeah and we've done a lot that is of substance like another really cool feature we have is this idea of a multi-buffer so if you run like a project-wide search in zed the initial experience is a lot like running a project-wide search in Zed, the initial experience is a lot like

running a project-wide search in Sublime where you get this buffer full of the little excerpts. At least last time I ran it, it may have changed since then. But in Zed, you could put your cursor in each of these little excerpts and just edit. You could have a multi-cursor edit that spans across multiple files

and edit everything at once and hit save. Or when you're looking at the rust compiler errors you see every error in the entire project presented in one buffer and like you could put your cursor at the top of the screen if you're collaborating with somebody they could put their cursor at the bottom and you just walk fixing the errors because a lot of times like it's simple it's a simple thing you could just fix it right there obviously you could jump into the whole file and to get more times, like it's simple. It's a simple thing. You could just fix it right there. Obviously, you could jump into the whole file and to get more context.

But like you can start at one end and you meet in the middle. Like we do that all the time. And so anyway, what I'm trying to say is like, I think there's a lot of investment we've done that's of substantial substance.

I mean, that's all we focused on. But it wouldn't be the worst thing to like do something cool and fun as well. Yeah, totally. Are you even thinking like, Jared, like the get visual, the one we just covered with, since you mentioned the Matt Reier show with the code name show that we won't mention the code name of, but like the visual sort of like simulation of what might happen if you simulate a get change like we talked about? Something like that even? Yeah, that could be a for instance that could be built in or something.

But I was more thinking of even less useful things that are just rad. So this reminds me, I know Elon Musk isn't popular, but when the Cybertruck first came out, he did a drive-through with Jay Leno. Did you guys see this where Jay Leno drove the Cybertruck for the first time? I didn't see it. Okay, so there's a quick clip. You can go watch it on the internet somewhere. And Jay Leno, he's driving it.

He's asking Elon Musk questions. They're driving together. And he's like, this car is bulletproof, isn't it? It's bulletproof or something. And Elon says, yeah, it is. And then Jay Leno's like, why would you want your truck to be bulletproof or something. And Elon says, yeah, it is. And then Jay Leno's like, why would you want your truck to be bulletproof? And Elon Musk says, because it's badass.

And it was like kind of the best answer, you know? It's like, okay, like why would we, why does Zed do that? It's like, well, cause it's awesome. Like, isn't that cool? And then turn it back off and keep coding or whatever. So I think there's value, even though it seems like why it's like well because maybe it's badass right and maybe that's what gets people interested so and a spirit of fun is just something that's for sure i don't know that was how github always felt in the early days there was just the spirit of fun totally

tom's like motto optimized for happiness so that's really something I'd like to carry forward. I mean, we're a different crew than those guys were. But yeah, making things fun. It's the hacker spirit. A lot of it's just the hacker spirit. Like we do it because we can and because we love it. And because look how cool this is that I can do this. I don't know.

I would lean into that. Thanks. Let's say folks are listening to this show and they're like, man, I have got to take the next step i hear it's bulletproof zed's bullet i hear i hear it's bulletproof your early innings you're still trying to win the minds and hearts and you're even early on that by your own admission yeah so set the expectation for someone listening to the show going right now to zed.dev trying it out for the first time what's the expectation what are you trying to do what should they do i mean download

it give it a try but in terms of the expectation of what you should expect to experience we've been building zed and zed for about a year uh zed is written in Rust. I freaking love using Zed to write Rust on Zed, just the way that we present the diagnostics. And so you should expect a pretty solid experience if you're writing Rust,

I mean, first and foremost. And I've got, I haven't written a ton of TypeScript in it, but our website's written in TypeScript, and it's quite good there, and we've gotten good reports

for that experience. So we've got an integrated terminal. I'm really proud of our UI. It's very minimalist, out of your way, and the performance, you should experience it as best in class. We've got a feedback widget built into the tool, and if it's

not, that isn't the case, please let us know because that's one of our top priorities so you should expect a very sleek you know well designed editor that stays out of your way with you know very good language server integration for the languages

that we support which is god I don't want to rattle them off you know we'll list the languages we support on our docs our docs but rust typescript go cnc plus plus ruby python i'm sure i'm missing some elixir and yeah for the languages we support it's fast it's clean you should enjoy it we don't have a debugger yet uh so if that's super important to you, then you may need to wait. And we'll keep blogging as we fill these gaps. And we really want to get people's feedback.

We read it all. We've also been experimenting with using AI to just like help us ingest all the feedback. So we have this, we have like a community repo of where people can open issues and engage with us that way. And there's just like a fire and forget launches feedback right inside the tool that you could just basically type as much or as little as you want and

just shoot it us and we'll be reading it all. And yeah. So again, we've been, I love using Zed. Does it do everything that all the other editors do yet? No. I mean, it's still in beta and there's still a ways to go.

But like, I don't know. I don't ever want to use any other editor. And for me, the reason is just the performance is really addictive. I didn't know when we were investing all this energy into making it really, really fast how

I'd feel about it it i just had this instinct like let's just do whatever it takes let's make it insanely fast but it i don't know just that feeling of it never getting in your way they're never being sanded the gears just like that you type a key and it just tears away like tissue paper it's not putting up any resistance to your thought stream yeah once i got used to that like i didn't want to do anything else and so i put up with not having a debugger because i want that everybody has different values and you know it's a vector what people put their weight on so you know this is my set uh but if that's something that sounds compelling to you like i would yeah i'd love for

you to give it a try and give us your feedback. There's something to be said about fast tooling. Fast tooling is fun to use. My dog's barking in the background for whatever reason. Who knows why he just decided right now to bark. Whatever, Rex. That's his name. Fast tooling is so fun to use, obviously.

When you have a fast tool, you're like, I want to use that thing. Shut up, dog. More often. Gosh. Get out of here, you're like, I want to use that thing. Shut up, dog. More often. Gosh. Get out of here, Rex. Stop barking. But that's so cool.

Hey, I was thinking about the conjoined triangles of success because I can't mention or I can't get through a podcast without mentioning Silicon Valley. Do you have, and it's a shtick in this one here. It's a conjoined triangles of success. Anyways, do you have a mission for success like i gotta imagine like while we mentioned the w and the l earlier in terms of like you know adam you got the l there your effort wasn't an l obviously but the the effort it's sunsetted yeah i mean but i would also call like what i'll say though about the adamom thing, sorry to interject. That's okay. Please do.

I view it as an incomplete success personally in the sense that what was at Ellis from my perspective, I ended up never feeling like it truly realized my vision, right? Yeah. But on the other hand, like there were kind of 2 million people writing software in the thing. For sure. other hand like there were kind of two million people writing software in the thing for sure a month for a while there so it's like it did have utility for a time yet you don't even anyway i'll take that i i appreciate you saying that i'm not saying that to say it was an l and i agree it was just you said it was an l adam you called it was the basis for my next point sorry i do i think an income no i love that please do i mean i'm not trying to like belittle anything

whatsoever but it fell short it fell short of what we wanted to do it could have been more yeah i think an incomplete is probably a better so it's like did you fill the test no you got an incomplete because you couldn't complete the mission you even said that you didn't have the authority to sort of direct its direction so you were sort of hamstrung. But the point I'm trying to make is to be successful, this mission of success, like if that is the thing for you, what is the first thing you're going to go after? I assume since Sublime Text is the second one on the list

in terms of who you compare yourself to performance-wise, which is the hallmark that you've talked about and we've talked about here. Multiplayer is obviously the next best thing, of course, but is your current mission to win the hearts and minds of sublime text users? I mean, that's a really good way of framing it. I'll have to give it some thought.

I hadn't thought about it through that lens, but I think that does make a lot of sense. I think we're well-positioned to do that, but i think that does make a lot of sense i think we're well positioned to do that but perhaps not entirely there i mean the challenge we face is you just look for 100 miles in any direction and there's you so what do we do first right and i think that's a really interesting way of framing it it's like dominoes right like one topples as they go for obvious reasons because of gravity and connect energy and all that cool stuff. But what's your first domino,

right? You've got to take somebody out. So there's gotta be, that's why I mentioned the W and the L you've got to have a dope. And to get a W, you have to cause somebody else to have an L momentum. Gosh, this analogy is just the worst.

I'm not trying to hurt people's feelings. Yeah. You know, you get a beachhead because you can't, you can't, youhead because you can't attack everywhere at once. Like you said, Nathan, there's so many things. I think it makes sense because they are

Sublime Text users as one. I'm more likely to try out Zed because of the performance than I would be to try out some flashy new Electron thing because of the non-performance. For instance, I've already chosen Sublime Text even though I know VS Code has way more features that everybody loves. But for me, that's something that's the most important. And so if I'm using Zed and I'm like, wow, this is silky smooth,

even better than Sublime. Now I'm starting to consider stick it around. But then the second question, I'm like, okay, but what about all my custom stuff that I do? That you don't realize in the first 15 minutes, but you realize in the first eight hours of using a tool. So, you know, I'll be emailing Nathan tomorrow and say, Hey, uh, you don't be cool if I would do this. I think the extensibility is going to be a big thing that Sublime Text has going for it. There's a lot, there's a, there's a large community of things that have been built for

it. And it even inherited a bunch of stuff from Sublime Text with the theming and stuff. It has a pretty big beachhead there. I know that's on your list, extensibility and multiplayer. So certain camps are going to care about certain things more. I think Sublime Text people will care about speed and extensibility, much like Vim and Emacs people will. And VS Code has extensibility too.

I mean, there's so many stinking extensions for VS Code. It's a huge moat. I'd say that's their biggest moat. It's just the long tail of all the extensions that have been built for them. And the thing that VS Code also has, which Adam had this, it was just the batteries included aspect.

It comes out of the box ready to use. Zed seems to have some of that going forward. The thing about Vim, and I'm a long-time Vim user, is Vim people liked, and Emacs people, they love to configure the crap out of it. Because you kind of have to. It's going to come out of the box, and you're like, this experience needs

some help. I'm going to help it. It's an editor kit. It is, and I got tired of that. I would love to just hit the thing in my dock and have it launch, and then have be usable and then i can extend it from there for sure which vs code has going for it i think adam had that going for it i think sublime text does as well but and i have not used any of the jet brain stuff but it took us some time even on on adam to do that because we were so focused on the extensibility over almost everything else.

Right. So, I mean, I don't know. Adam did have some batteries included, but not enough. So that is, that's kind of still what we're focused on. Getting enough of those batteries included to feel like we've really got the core in place before tackling extensibility. So we're still figuring it out. I think getting it out there and letting people try it and give us feedback will be very informative. Well, we're rooting for you. I always root for the little guy. I love David over Goliath.

I think you have definitely a great start. You have the experience. I love how fast this thing feels in my hands. And the history. And you have the history. You're new, but you're not new. That's right. But you got a big battle ahead're new, but you're not new. That's right. But you got a big battle ahead of you and we'll be rooting for you.

Yeah, we've been fighting this fight for a very, very long time. So, I mean, I don't really view it as a fight. Like we're just trying to do our thing and do something that matters and do something we love and make an impact. But I get it. At a given moment, a developer is not really using two code editors they're using one that's right and there's a finite number of developers so to that extent it is a fight but yeah hopefully this resonates like what the vision I put out resonates with people and

they'll give us a try and stay tuned to what we're doing and what we're trying to do very cool all right y'all zed.dev code at the speed of thought high performance multiplayer extensibility whiz bang features that don't even matter potentially

because Jared recommends them that's right coming soon the extensibility piece yeah yeah well it's on the it's on the mission plan

so there you go exactly that's part of the promise I think if you go there for that and you like what you have there then you know where the promise is going so you go there for that and you like what you have there then you know where the promise is going

so Z.dev Nathan it's been awesome having you is there anything we didn't ask you is there anything that's left unsaid probably but yeah I think we're pretty good okay appreciate you coming back on the show until next time we'll have you back again

yeah I appreciate you having me. Yeah, awesome. Cheers, guys. Cheers. Okay, so if you haven't been to zed.dev yet, now's the time. They're coming out of beta and they're on a Mac near you. Check it out. Try it out.

Let Nathan and the team know what you think about this new editor. Is it for you? Time will tell. Again, zed.dev. Check it out. Speaking of time, we have some bonus content on this show for our Plus Plus subscribers. So if you are a Plus Plus subscriber, stick around. There's more for you.

And if you're not, all you got to do is go to changelog.com slash plus plus sign up, become a member, get ad free shows, get extended episodes like this one, and so much more. Again, changelog.com slash plus plus. And of course, a big thank you to our friends at Fastly, Fly, and also TypeSense. And of course, to the Beats Master in residence, Break Master Cylinder. Those beats, they're banging. And of course, to you, thank you so much for listening to this show.

If you love the show, please share it with a friend. But that's it. The show's done. We will see you on Monday. Thank you. Outro Music