Listen to Episode

Read Episode Transcript

This week on the Change Club we're talking to Nathan Sobo about his next big thing. Nathan is known for his work on the ad of Mediter 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 and don't look gloomy because fast they're fast, they're fast, they're fast globally. Check them out at fastie.com and our friends at Fly Help us put our app in our database closer 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 Atom. 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 thought of you guys too over the years, many a time. Oh, thank you. And I can relist into that podcast. Oh nice. 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 well, we just had this like, we wanted to come in with a bang, you know, it wasn't necessarily like over into metal or something like that, which is like, we wanted to sound like, right, get amped, get hyped. This is a fun thing where then people told us that we weren't very approachable. Because it's like, is this like a heavy metal for sure? You know, this is hardcore. I don't know. So then we have our brake master cylinder and that's the history basically. That's the long story short. Real quick, once 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 with the time of ancient history that Adam, not the editor, but Adam Stakovic, interviewed Hank Rogers on Founders Talk episode seven back in 2010, ancient history. And he told the, Adam, you told the Tetris story before it was cool. Yeah, man. So did you go back and listen to that? I haven't. But I remember it very fondly. And that was quite fun because, you know, Hank, I mean, let's change it 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 a book, but be able to put it on all these different platforms as now on today like the Tetris we all know because they work so hard. They fought so hard to like get back what was right for 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 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. It's coming out soon. And it'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 royalty. You're going to royalty check out of the sucker. Let's get a mention at least, you know, change all that I've been. Yeah, let's get a mention that maybe in the credits. Yeah, something. Anyways, that's even further back Nathan, then your 2017 interview. But back then we were talking about Adam. I think I think VS code wasn't a thing at that point. I don't remember when VS code actually came on the scene, but I think it was. Yeah, I think it was. Yeah, I think it was probably around, but wasn't like hadn't taken off. And obviously GitHub had not been purchased by Microsoft at that time. Right. Right. A lot has changed since then. Adam was very much Chris Wandsdoth'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? When an 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 web kit, the old web kit framework that you could pull in the 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 would be cool if we just had kind of node smashed into Chrome because I, you know, Chrome uses V8. 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 contest 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, 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. And, you know, that's a big, 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, you know, Adams, although Adam was kind of, you know, dead on the vine for a while. Right. Right. 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 Sunsetz, as Adams Sunsetz, Zedz Sun is 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, heard as Atoms Sunsetz Zedz Sun is rising. We are not done here. When was that tweet? June of last year. Oh, wow. Okay. This was like right around the, yes, June 8th, 2022. Right after they announced the fair well, very, very well played. That was poetic, Nathan. Nice one. Thank you. Just came to me. 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, Zedz 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 year 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 sort of the ultimate code editor. Can you give us the maybe a short 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. What did you begin here? What's the mission? And where did you begin? I mean, the mission's 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. I've always believed that like one of the key bottlenecks 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. Like I came out of pivotal labs. That was a culture where we literally sat and coded together for, you know, 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 as this idea of a social code editor, the time like the tagline of GitHub with 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 out or add a lot. And then taking on the crazy level of extensibility that, you know, that was really what Chris was excited about more than anything. He's just making this thing crazy, extensible, like a modern EMAX. And, you know, I took that and ran with it as hard as I could as well, you know, creating electron and bracing and PM and all that. But by the time we just got through like learning everything we needed to know to build 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, you know, I think it was, you know, spring of the following year that we decided the year following our podcast. So that was 2017. We decided to build what became teletype, which was the collaborative coding package for Adam. And, you know, Tony and I like 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 them 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. That's kind of okay to some degree, right? Like you kind of build up your scan, 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 Adam 2.0. I didn't really feel like that'd be great for the Adam community. And I didn't really have authority to do that. I get up. That was always rookie. Like, what I did and did not have authority to do is always kind of undefined. You know, we were kind of this little right little team under the umbrella of the Smuch lawyer, larger organization. So we call it X-ray, which is kind of like what you get upon the splitting of the Adam, you know, the and I remember I, you know, 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 in Tony and I. We stood in front of the whole Adam team in like 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 it's, but yeah, we started in and we would, I remember writing these notes in the repo that were just kind of intended for product managers and people at GitHub just so that they could maintain awareness of what we were doing. But it was all open source and at some points and 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 wins inside of GitHub. And at some point, it became clear that like there wasn't really an appetite for an Adam 2.0 within the company. I left for the birth of my second daughter. And like when I got back, Microsoft had acquired the company and it was clear really well. Wow. Gonna happen. And so that's when I just switched teams. I worked on web hooks because like at that point, GitHub's web hooks were like still being delivered by a bunch of like single threaded Ruby processes that were like each consuming like 700 megs of RAM, just like blocking sending HTTP requests out. So I wouldn't did that. But 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 their blinking just being like, you are done yet. You are done yet. Like mocking me. It's the drum. Boom. Boom. Yeah. Telltale heart or something. So I mean, you asked about the mission and I kind of diverged off in it. Not 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 we have a, 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 was sort of like my undercurrent of questions like, because then you know, you were so knee deep into Adam and obviously you have this passion for it. And it's, it's interesting even that VS code was similar in nature in terms of bill because it was also built on electronic early in its day. I don't know the case to this day, but like, why did it win? It still is. Is a question. Okay. There you go. So I, it would make sense. You know, it's like, well, how did you know, VS code win? Because obviously Adam lost based on the sunset. 100% it's just a, it's an L in that case. That doesn't mean the work you do is, you know, an L. It means that, you know, the fight, there's awards like browser awards, it's editor awards. I mean, somebody's got a win. Somebody's got a lose. Right. Not mental words here. So, you know, you think like, okay, where were you when GitHub was acquired? And then too, well, why did VS code win and Adam 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 innovative model of doing an editor and web technology. And there was this team in Switzerland that 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 a clips, et cetera. But when they saw us doing electron, they, and we open sourced electron, that was this opportunity. Like, oh, we see Adam 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 Shell. I don't think we renamed it to electron yet. And yeah, that kind of gave them this head start. So I think there was, you know, 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 Adams wounds honestly were like self inflicted on a number of levels. Like I made some stakes. And I think one part of it was just like never having clear leadership. Like I was kind of by the end, you know, I've been there from the beginning to almost the end. I was the longest serving member of the team. But like, I never had any official authority on the team. Yeah. So that was part of it. But there was also just like, you know, having started the dark ages. Like we started in coffee script. It took us too long to switch to JavaScript. We should have gone straight to type scripts. So like just using, you know, in, in failure 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. Like we never really pulled the trigger on that. So that was a mistake. And then we just spoke 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 like, you know, Microsoft's approach was a lot more conservative and a lot more focused. But of course, like they were coming from from the position of working on IDEs, working on, you know, the type scripts tooling. And so I just think like 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 a let 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. We're 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 NewClide. 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, as Zed, we were determined to do things differently. You know, one thing is how to clear business model like and a clear objective from the beginning so that we could really start a company that we would aim to be self-sufficient around this tool that had a clear leadership structure that's 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, you know, 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 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. It's just like, I don't know, I thought I thought it would be pushed to JavaScript to the absolute limit and then beyond, you know, doing things like V8 snapshots to like start up faster and just crazy. Yeah, we just, you know, we're like, we can't do this anymore. So, switching to a better language and Russ to hit 1.0 in the meantime and I'd been following Russ 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 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 even worried about extensibility at all. Like when the iPhone came out, it did a couple of 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 Adam. Obviously, I love extensibility. That's a huge value of like, but Z 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. And 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 like the order of precedence of things that you need to get right. I mean, as a user, my, if I took those three things, performance extensibility and collaboration. And I said, which order do you want them in? Like, 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 them in the command line, but for text editing sublime text because it's just faster. It's faster than VS code. This is faster than Adam used to be. I liked the ideas behind Adam. I love the extensibility and like 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. Like 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, 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 in 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 like built like a video game thing. So like 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 okay. That's not going to get you all the way there. It's going to get be faster than V8, maybe in some context. But this 2D rendering GPU thing, is that that come out of your work on X-ray? Is that a brand new thing you guys built for Zed? So 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 Zed? There's a tiny bit of code. It was all open source. So super clear there. Everybody sue us, but like 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 it to the end or we redirect 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 like 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? We're kind of everything needs to have one unique owner. And it's very, once you have everything be this directed graph where everything is downward, 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 a double borrow, etc. So that was the first big problem we need to solve. It's like how do we do UI? And so initially the foundation of GP UI, 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 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 like you know, painstaking attention to, you know, our algorithmic bounds and etc. And right. And then the JSON would get to the JavaScript and we'd just throw it all away immediately, right? Starting with like parsing that data and then like recalculating styles, refloing 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 in 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 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 this rust create called Pathfinder, which is Patrick Walton wrote it. 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 at a 2D UI are much simpler than a 3D game with, you know, photorealistic water balls 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 pixel 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 that just relentlessly saying until this is fast, we haven't solved the problem, and we're gonna 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 a really great app for you. We can link chief evangelist at Postman, so can 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 from me. What changes for team when they shift their strategy, when they shift their thinking to API first development? So when your one team goes, hey, where 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 an 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 change log pod again postman.com slash change log pod sign up and start using postman for free today or for our listeners already using postman. Check out the entire e-pad platform that postman has to offer again postman.com slash change log pod. This GPU I thing is a brand new thing. Is this something you all invented? Can you kind of like yeah, you kind of glazed over a quickly explain it, but like give us the deeper notes on GPU I. Yeah. So GPU I is a 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 that 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 GPU I covers, you know, just the shell of the apps that interacting with the platform API is to like pull up windows, etc. 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 on data flow rather than control flow. So what does that mean? Well, rust 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 this standard protocol where, you know, like say a user clicks that's models 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 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 GPIs sort of how do you structure the application logic, the models, the views, etc. So that you can have these bidirectional interactions, which are really common in you eyes. Like I open a modal, then the user clicks the x on the modal. Well, the thing that open the modal leads to know about that. So it can hide the modal. That creates this bidirectional relationship. So a big part of GPIs just like a scheme for modeling bidirectional data 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 dipping 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, etc. Like there's this big chain that occurs where we didn't said anytime, any do updates of state, we basically like 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 Flavine. 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, they vastly predates like the availability of GPUs. And it introduces a lot of complexity that's not relevant to the problem we face of like keystroke to pixels. I get a keystroke. I want pixels on the screen on the next frame. And so yeah, GPU 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 data, it's macOS only. You are working on other platforms, but it's not. You can work on it 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 at weekends on Z, that was where I started on the machine I was on. But we designed GPUI 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 really sun Linux and Windows prior to deving anything one point out. I think anything called one point out 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. Taking it back to the web. So when I think about Z, I think I tried it 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, Z is being born into a much different landscape than Adam was born into. Very much when Adam was created, there was kind of a dorth of innovation in the space. I mean, text mate had gone silent, right? Some blind 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 EMAX people who are just still using VIM and EMAX to this day and always will. And Neo VIM 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 execute it very well as you as you mentioned some of the things they did. And so success to them. That's all good. But now here comes Z. And I'm thinking like what I want to compete with in this landscape today with a brand new thing. Maybe I would. It sounds like maybe it's a nice challenge, but also sounds kind of don team. And then I thought, well, the techs make guys guy. I don't know who you don't 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 it's 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. Right. Maybe it helps share your mindset around what Z is trying to become the landscape and how you sell yourself apart inside against the VS code now. To carve out your own user base. That's big enough to support a growing company with, you know, debt, so to speak. Yeah, absolutely. Well, we raised equity for what that's worth, but okay, but but I get it. Yeah, no debt. Yeah, equity partners who would love their money to come back multiplied. Exactly. Yeah. And I, you know, I don't accept investment without an intention to return on that investment. Like, let's share. You know, 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 the front line of where software is written doesn't see enough investment and innovation. Because, like, historically, I think it's been hard to monetize. So jet brains 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 space models. You have these like lifestyle, love scale businesses like Texanator sublime that are operating the small teams, or you have kind of the big corporate patron model, which was Adam and the S code. And like, 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, you know, 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 stacks up. 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 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 fricking 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, you know, for their particular motivations. But I can tell you what I told them and really believe in terms of what the market opportunity is today in terms of, you know, again, if I think 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 makes sense 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 it up 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 song 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 mission to teammate, pull them in and like start a conversation. So that conversation is really growing over the entire code based because again, like you want to introduce the 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 like, do you do that on a poor request? Like, 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, where like have things inside of back ticks, you're talking about code that isn't even there. And then it scrolls off the screen. And it's like gone forever. What's someone else comes to the code and has the same exact question that you had? Or are you like hopping on a Zoom call and now one person's like dictating through the screen? Like, oh no, no, no, okay, open this file. Okay, now go to this function, right? Whereas already in Z, like, we've tackled the real time piece of it. When we want to just have a conversation about code, like we're doing that in Z. So we'll start up voice. That's not in Z yet. So we still rely on an external tool to do the voice for us. But then I'll just open up, like, open up this menu and invite one of my teammates and we're following each other around inside the code instead of trying to dictate through the screen, like, go here, that'll take that because like 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 like, I remember when McKayla, engineer on our team, she was like integrating the terminal into Z. She was interacting with GPI and there might have been some APIs missing. She wasn't quite sure. So we have a conversation and I toured her around inside of 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 jump back into GPI and we wrote the code, added the methods together that needed to exist for her to accomplish, which she was trying to accomplish. Then we hop 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 poor requests like 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 not confining ourselves to that. That's, I think, the innovation opportunity. It just so happens that you know, 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 for 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 being more productive in their communication that funds the people that just want to use it by themselves for free and drives more innovation into the code outer space than has ever been possible, ever been funded. As Jerez said, you are 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 Z 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 team's 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, every listening. It's been since episode 10. Come back on. Chris Wandsroth, yeah. Since episode 10 of this podcast, it's been too long. Come back on. I want to 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 that it makes sense to start on performance on the web page on I think it's slash features of on the right page. It's just the main page probably. Sorry, the dot dev. Yeah. Engineered for performance. You're gonna leverage every CPU, every GPU. And the graph there says that Z performs faster or as fast as sublime text three times as fast as the VS code. And I don't even know CLI on or Clion or CLI and CLI and CLI and CLI and the Jeff brains variant of okay. The Jeff brains variant targeting rust and C++. Gotcha. Just because I think again, like, Jeff, we're not even really targeting Java right now. Like, Jeff brains can have that for the time being for the time being. I love it. Yeah. That's why we put CLI and up there is our point of comparison. Yeah. Sure. So let's talk about the name. Yeah. Is this a pull fiction reference? Please tell me this is a pull fiction reference. People and the funny thing is you're gonna be surprised. I'd never even seen pull fiction. Okay. So yeah, I should watch it. But anyway, so yeah, someone has since informed me of the pull fiction reference. But actually it was a reference. I was thinking about names at some point. And I thought back to the Unix editor Ed. Yeah. Which I've always been like just fascinated by the history of Unix and you know, that picture of like Thompson and Richie on like a teletype hooked to this PDP 11 like that goes to the ceiling like writing Unix on a frickin 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, well, maybe we could name it Ed. And I'm like, what that Ed still exists though, right? Like, right. If you open your terminal right now and you type Ed, it's an editor. I'm not gonna like, it just seems rude to like shadow, you know, the editor. That's still there. Let's add that we're trying to be an homage to. Right. So, you know, I was just thinking of, okay, well, could we name it something similar to Ed? And you know, bad doesn't seem like a great name. Right. You know, like said is taken. Ted has its talks. Just Ted talks. Exactly. So I just, and I knew I wanted to be short. And so yeah, I just felt like said it was a pretty good name. And like, what I like about it, it's like a word for a letter. And I don't know, I like it. So it's a little mosh 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, her first letter of her name. Yeah. First letter of hers too. I think it's cool. I think you're kind of like the last Ed, you know, you put the last letter of the alphabet in front of Ed. And it's like Zed, the last Ed. See, Ed's at the, yeah, the last editor. I'm pretty sure this is the last editor I'm gonna build. So he's Nathan's last editor. Yeah, this is the, it's not the last. Swinging for the fences on this one. Yeah. Yeah. So you've raised me. You're swinging for the fences. You're building a team. It looks like you have a decent size 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? Are you feeling good? We are definitely hiring. Yeah. We're interested in people that know rust fairly well, fairly proficient in rust. And 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 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. So the only avenue that we want to use, because obviously that narrow is your pool to people who are able to work on code in their spare time, et cetera. 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. 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 look to scratch that aren't even really that big. But there's just a lot of circumcissary on a tool like this. So I'm not sure. I think it's the best route to get help. Yeah, this is similar conversation we have a Zach Lloyd from warp and their building. Oh, yeah, I worked at work for a little bit. A lot of the tech that they're using is actually derived from our early work on said. 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 you took a lot of thought from there, 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 going to 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, it's a terminal, you know, like, yeah, 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 was assuming there's some collab stuff that's missing from Z 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 in to GitHub to use my terminal or sign in with GitHub, sign into warp. And so I was kind of trepidacious when I saw the invite about the Z 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. 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 principle 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, you see exactly the stuff that we're sending. Right. So just being like legit transparent. Yeah. Exactly. Just like, see, yeah, we are trying to build the business. But 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, on sublime text users, not 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, you know, equity raised and the business model may or may not hand 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 you can make it unsustainable if you don't do it right. So you have to tread tread carefully with those things. Yeah. For me, I'd like to be as open as possible while being confident that we can build a business. And I think I thought 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 believe the best result is that there's a core team stewarding the product and channeling the efforts of the entire community around it. The S code has that. They just happen to have a very large patron backing them. Right. In our case, we need another plan. So the parts that will 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. Yeah. 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? Will it be, you know, 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 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 it other people want to use and building in the features people need that are maybe there yet 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 set that in stone. But that's our instinct. Well, it's not about setting us to this. It's more yeah. So the reason I ask that question is kind of twofold. I'm curious. But then too, 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. And we kind of talked about some of their thoughts are on the business model and the fact that they're not up in 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 is like, you know, the thing for you to do. Now, obviously, we know open sources 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, and that's that remains to be seen. But I think it's important to talk about those things. And we learned a lot from Adam around, 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 frickin thing out there and get our ducks on 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 were interested in that. And yeah, I mean, really, we may go sooner, but I would really very much like to open source said on said, meaning use some of the capabilities I'm talking about developing as a part of the open source or the experience of contributing to Z. Like you have a question about the code is you're trying to contribute being able to engage with us in Z on the code. That would be cool. That's really like our big vision is for Z to be the future 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 picture here because now I'll sudden, you know, who needs GitHub open source and on Z. I mean, I don't need necessarily like to get hosting. Well, you said where open source is going to be. I mean, on a long enough time frame, yes, but I think okay. Yeah, for a while, like when I'm we're 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 open source that I'm really talking about. Yeah, it's just a new kind of experience that doesn't really exist because if we were just trying to like 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 is 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 is 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. So 100 percent will be interesting to see. Yeah. Yeah. 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 it 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 how much of have surveyed the landscapes 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. That's the easiest answer for developers or any question. But like that's the question. I think you should be asking and figuring out and having all the various presentations of that answer because that's going to guide your direction's product. That's going to guide your direction's 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. Right. 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 needed the bugger. I don't have it a bugger 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, yeah, performance. That's what we lead with on our our main page. Like, you know, uncompromising approach to performance going to whatever link necessary to make it good. Clean design. I think is something I'm really proud of. Just 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 is new frontiers opening up in AI as well, integrating co-pilot is something that's high on our list, but obviously it goes much further than that. But at least at the moment, like 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 is mungable. So one of the things you say at the very top of your homepage right now is Z as a high performance we've covered that a high performance multiplayer, which I think is a keyword 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 an air quotes really because yeah it could literally be your team if you're an organization enterprise leveraging Z. But if you're an open source maintainer and you're adopting dev dev containers and you've got a code space or whatever it is like that's the road you're sort of going to because you want that drive by contribution. I mean you even have youtubers out there who are like examining code. What if it was like you're on Twitch and you were examining stuff and you're a high profile influencer out there or whatever might be and they could be touring as you said this this keyword before touring someone through X, Y, Z, Jared I've talked about this to you before where like let's have somebody give us and we've never done this. 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 co-base. This is something you've I think you've done at least once Jared on YouTube but something we haven't like poured deeply into but like Z 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're 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 dip 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 thought about that I mean it's funny Antonio on our site we have this like graphic where you see the 2d thing and then it kind of yeah it turns 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 that 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 right reducing the hit area only like filling part of the frame buffer during partial we draws and stuff but already like the power efficiency difference like you know you can sit on a laptop coding and said for just especially one of these new like M1 or M2s you know like just all day long uh it's already so power efficient that we haven't done that part yet right but anyway we can yes 120 frames a second you know in burst motor 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 electrons probably never going to be able to do and that you guys are built to do because think about it like this is what made Snapchat so interesting at first was like their filters and it's all it's like by definition like superficial stuff right but it's cool fun crazy stuff that that makes it interesting and people say what editor use like all of a say we have a TikTok where I remember there's this VS code thing it was like a fireworks that would happen once and it was cool and people shared it around but it's kind of dorky and low res and like slow like you know pixelated right and like if you could do really cool stuff minority report style inside of zed just because you can you know kind of like how the Tesla's can dance or whatever just because they're like why not make the thing dance because that would be cool right like there's actually might have some nice network effects to where people are like I just go down the zed you can have it on your computer too okay why not and then they get there like oh this editor is actually pretty nice maybe I'll keep using it so I think that'll be fun and interesting yeah I had that saving 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 what'd it be cool and like right yeah because of how is that 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 this is idea of a multi buffer so if you run like a project white search in zed the initial experience is a lot like running a project white search and supply and where you get this like buffer full of the little excerpts really for last time I ran it it may have changed since then but in zed you could put your cursor in on each of these little excerpts and just edit you could have like a multi cursor edit that like spans across multiple files and like edit everything at once it hits save or when you're like 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 little 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 Ryerson with right right the the codename show that we won't mention the codename of but like the the visual sort of like simulation of what might happen if you simulate you know a get change that we talked about think of 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 more even less useful things that are just rad you know so this reminds me I know Elon Musk is a popular but you know he had the when the cyber truck first came out he did a drive through with J Leno did you guys see this were J Leno drove the cyber truck 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 J Leno's in he's driving it he's asking Elon Musk questions they're they're driving for her and he's like he's like this this car is bulletproof isn't it like you can it's bulletproof or something and Elon says yeah it is and then J Leno's like well why would you want your truck to be bulletproof and Elon Musk says because it's badass yeah and it's like kind of the best answer you know it's like okay like why would you why does that do that it's like well because it's awesome right like isn't that cool and then turn it back off and keep coding or whatever yeah 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 I that was how GitHub always felt in the early days there was just the spirit of fun totally Tom's like motto optimize for happiness such really something I'd like to carry forward I mean we're a different yeah crew than those guys were but yeah make it like fun it's the hacker spirit a lot of it's just the hacker spirit like we could do it because we can 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 well let's say folks listen to this show and they're like man I have got to take the next step I hear it's bulletproof that's bulletproof 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 listen to the show going right now to zed.dev trying it out for the first time was the expectation what do you try 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 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 like a pretty solid experience if you're writing rust I mean first and foremost and I've got I've been written a ton of typescript in it but our our websites 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 you know if it's not that isn't the case like 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 got I don't want to rattle them off you know we'll list the languages we support on our on our docs but rust type script go cnc++ 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 so if that's super important to you then you may need to wait and we'll keep logging 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 you could just basically type as butchers 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 Zad 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 like making it really really fast like how I'd feel about 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 in 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 thoughts 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 it a bugger 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 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 like give us your feedback there's something to be said about fast tooling fast tooling is fun to use my dog's working 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 right I mean when you have a fast tool you're like I want to use that thing shut up dog more often gosh get out of your Rex stop barking that's so cool hey one I was thinking about the conjoined triangles of success because I can't mention or I can't get through a podcast about mentioning Silicon Valley well do you have and it's a it's a stick in this one here it says to conjoined triangles of success anyways do you have a mission for success like I gotta imagine like while we mentioned the w in the L earlier in terms of like you know Adam you got the L there your effort wasn't in now obviously but the the effort it's unsaid it yeah I mean but I would also call like what I'll say though about the Adam thing sorry to interject that's okay please do I view it as a it didn't complete success personally in the sense that I what was it L is for 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 two million people writing software and the thing for sure a month for a while there so it's like it did have utility for a time yet you know anyway I take that I appreciate you saying that I'm not saying that to say it was an L and I agree it was just yes it was an L I mean call it it was the basis for my next point sorry I do I think in 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 it could have been more yeah yeah yeah I think an incomplete is probably a better so it's like did you feel the test now 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 gonna go after I assume since sublime text is the second one of the list in terms of who you compare yourself to performance wise which is the whole mark that you've talked about we've talked about here multi players obviously the the the 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 had and I'll have to give it some thought I hadn't thought about it and that through that lens 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 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 got to be that's why I mentioned the W in the L you've got to have a dope and to get a W you have to cause somebody else to have an L build momentum just analogies is the worst I'm not trying to hurt people's feelings yeah you know you're gonna be said because you can't you can't you know yeah you can't attack every word at once like you said Nathan there's just so many things I think it makes sense because they are sublime text users as a one as one I'm more likely to try out Z because of the performance that I would be to try out some flashy new electron thing because of the non performance for instance like 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 Z and I'm like wow this is silky silky smooth even better than sublime now I'm starting to consider sticking around and but then the second question I'm like okay but what about all my custom stuff that I do you know like 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 you don't be cool as 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 even inherited a bunch of stuff from sublime text with the the the mean and stuff it has a pretty big beach had there yeah I know that's on your list you know 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 Emax people will and VS code has extensibility too I mean there's so many stinking extensions for VS code to huge mode I'd say that's their biggest mode yeah 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 like it comes out of the box ready to use a Z seems to have someone that going forward the thing about Vim and I'm a long time Vim user is you know Vim people liked and Emax people they love to configure the crap out of it because you kind of have to like he's going to come out of the box yeah and you're like this experience needs needs to help I'm going to help it it's another kit it is I got tired of that like I would love to just hit you know the thing of my dock and have it launch and then have it 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're still focused on the extensibility over almost everything else right so I mean I don't know out of 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 yeah we're still figuring it out I think getting it out there and letting people try it and give us feedback will be a very informative yeah well we're rooting for you I always root for the little guy you know I love thanks 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 in the history and you got the history your 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 sure and make an impact but I get it at a given moment a developer is not really using two code editors are 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 and stay tuned to what we're doing and what we're trying to do very cool all right y'all Zad that dev could have this be a thought high performance multi-player extensibility whiz bang features it don't even matter potentially because Jared recommends that coming soon the extensibility piece yeah well it's 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 Zad dev Nathan it's been awesome having you is there anything we didn't ask you has anything that's left unsaid probably about yeah I think we're pretty good yeah 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 zad.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 we'll tell again zad.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 type sense 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