Talking To Zed Industries- Makers Of The 100% Rust, Super-Performant, Collaborative Code Editor

Drew: I think a lot of people in the Rust community will know that Zed is a new code editor written in Rust. We're all super excited about it. So, I wanted to start with a question that I think might feel overly confrontational, but I just wanted to phrase it this way because I think it might get an interesting answer. The question is, why do we need a new editor?

Mikayla: That's an excellent question. For one, I think we need a new code editor because of live collaboration. This was the reason I joined Zed in the first place. Developer tooling has been built with certain expectations and certain models for a very long time. But, in order to get the sort of live collaborative experience that you see from something like Figma or Google Docs, you have to bake-in the right data structures and processes from the get-go. You need to build your entire code editor on those data structures and concepts in order to get them to work. In a lot of other tools I've found that you can feel a little bit of a mismatch between the CRDTs (Conflict-free Replicated Data Type) and the other data structures over here and then the fundamental code and the actual data structure that renders on your screen, which might be over there. So, that's the collaborative angle.

Mikayla: Another reason is just that technology changes and time marches on. Electron is a really impressive piece of technology that solved a really hard problem. It’s now been quite a while since that problem was solved, and we have new tools and new possibilities, specifically Rust. We believe that Rust makes it possible to have the same level of ergonomics and support without the 200 megabytes of embedded V8 that every desktop app is carrying around nowadays.

Drew: When I was doing some research I found a statement from someone at Zed talking about how the editor is built like a video game. Does that play into what you were saying about live collaboration and stuff?

Mikayla: Yes, fundamentally those CRDTs and the underlying tech for synchronizing have a cost. You need to track a little bit more data because you're doing a more complicated problem. Also, specifically with code editors, the bounds on the problem in terms of resource utilization, like memory and file handles and all that sort of stuff isn't under your control. For example, if you ask us to open a hundred files, our job is to open a hundred files or die trying. So, we're kind of stuck in this little triangle where we have to do something that is a little more expensive than it would be otherwise because of the live collaboration features. And, the amount of work we have to do is not under our control. So, we have to make sure that what little we add on top of that is as small as we can make it. And on top of that, we want to make a fast, nice app. We live in this all day long.

Mikayla: To solve those trade-offs, the founders really had to go back to the beginning and be like, "Okay, there's all this Electron, there's all this JavaScript, there's all this stuff. Let's just toss that aside. Let's make this as small as possible and then build up from there." For example, we've been continually improving GPUI. But, we don't want to have to lug around all of the weight of the way editors have been built and tackle these new problems. We want to simplify. And, if that means we have to do more work or we have to build it like a video game or use tools from other realms of software, then that's what we do to solve this problem.

Drew: One of the other things I saw when I was doing research is that the founding team of Zed has a crazy amount of experience to lead them to this moment in their careers. Can you speak to that a little bit?

Mikayla: Zed is a special project at a special time, because it's one of those things where all the stars aligned over multiple decades to make this thing possible. Nathan (the CEO) led the Atom team at GitHub. He was core to that whole thing. That project of course led to the creation of Electron and the current state of desktop app development.

Mikayla: Nathan and Max both also worked at Pivotal Labs before being on the Atom team. They did a lot of pair programming together there, and that has carried into our culture today. Also, Max worked on Tree-sitter, which is one of the core components of almost every syntax highlighting or code parsing tool made in the last 7 years. Antonio also entered the mix when they were working on Atom. If I remember the story correctly, he just started submitting really good PRs for Atom, so Nathan brought him in and they became good friends. But the key here is that all three of these guys live in different places. Antonio is in Italy. He's Italian. Nathan is in Boulder, CO. Max is in Oregon. I think the fact that they live far apart contributed to a lot of their initial research into CRDTs. I believe one of the early live collaboration tools for developers was actually an Atom plugin called Teletype, also by the GitHub Atom team.

Drew: That's awesome! Who you're working for makes a big difference, and that must be such an awesome thing to be working with a really specifically experienced team like that.

Mikayla: Yeah. And, it's hard to overstate how important collaboration is to Zed. I think one of the reasons we function so well as a company is because we are collaborating and pair programming every day. Though, it’s not quite pair programming. I call it parallel programming. We're sharing context, figuring things out, and understanding the problem together. If you look at our GitHub repository you don't often see very many code reviews, but you will see multiple heads on every commit. That's because we're spending all day together, understanding the problem together.

Drew: So, are you personally in the collaborative feature of Zed for a large part of your day?

Mikayla: Yes! I am almost always pairing with somebody. We always try to make sure we can pair. Even if it's like European evening and American morning we will pair for an hour or two to talk about the problem and then go off and do it separately. So, most programming is done together. That said, there are a lot of things that aren't programming, such as reviewing PRs from external people, that might be done a little more solo.

Drew: I feel like when I've done a lot of pair programming, it just makes the emotional load of taking on something that feels hard so much easier.

Mikayla: Yeah, you feel like you’re in it together! You also usually have a slightly different perspective or slightly different skills that can complement each other. I will say, what we do is not classical pair programming. For a long time, pair programming has been two people sitting at one keyboard. One of the key things about collaboration in Zed and other tools is that you're in your code editor, with your theme, your settings, and so on. You just happen to be visiting their file system and utilizing their language server and stuff like that. So, it's actually a lot more comfortable and a lot more like bouncing off each other. I'll often be like, "Okay, let's split up. I'll implement this part. You implement that part." It's a good flow.

Drew: So, speaking of taking on hard things, to me building a code editor from scratch seems really hard. Everything that you explained in terms of the reasons why you would want to build a new editor makes total sense. However, there's all these other people building new editors. And, most of them are forking VS Code because they're getting a bunch of stuff for free by doing that. How do you guys think about prioritizing what to build? There's all of this stuff that you have to add to the product just to catch up to the level of features that people expect.

Mikayla: That is the question at Zed. It’s the question we spend most days thinking about in one way or another. It's both a blessing and a curse of working on a code editor because there are so many things we have to do. This has meant that oftentimes our decisions are driven by what we're interested in. That was especially true when we were starting out. It's not really the case as much these days. But, when we were starting out, whatever you wanted to get done got done because everything had to get done. So, when you don't have fold indicators or indent guides and you have a little idea of how to do fold indicators, you do fold indicators instead of indent guides. These days it's a little bit different because we have done a lot of that low-hanging fruit. We are still working on how we make decisions for all the stuff that isn't like a big headline project. It's easy to talk about Windows or the agent panel or the debugger. These are very clear things. We can put them on a list, and we can figure out the order we want to do them in. But, where do you put “the debugger doesn't work on my Python project that uses distributed venvs” or whatever the little thing is?

Mikayla: I guess this is a good time to talk about our approach to AI. When the ChatGPT demo came out, Nathan immediately started reading the white papers about how it worked. We all started experimenting with AI and learning about it. You know, some of what we do is interest-driven development. Nathan got really excited about AI, and people in the community were really excited about it too. So, there was just this massive pressure to do something about it. We initially took an approach with AI that I think was very sound. It was all about controlling the context. So, you could control everything, even the system prompt. It was all there. It was a very, very thin wrapper around the LLM APIs. It seemed great, but people didn't like it that much. Then, the agentic stuff came out and agents became the de facto way. Part of it was us being like, "Okay, this is all happening. We also need to keep up. There's a moment right now of people switching editors. We need to make sure we are an option for them to switch to."

Mikayla: So, how do we choose what to build at Zed? There's a little bit of strategy to it like "Hey, right now is a great time to do an agent. Let's make sure we have an agent out really soon." There's a little bit of personal desire. Something that's really important to us is that we are making our dream code editor. If there's a dream feature you want, you put it in there. So, there are a few different forces at play.

Drew: You mentioned that you're building your dream editor. That's a very cool thing about the opportunity to work on Zed. It's very rare that you get to work on something where you are also the user.

Mikayla: Yes. All of your friends are users too. For a while there, I was doing dad-driven development where every few months I would go visit my dad and show him Zed because he's a software developer as well. He'd look at it and be like, "Oh, there's a problem here. Oh, you can't adjust the panes of the window or whatever," and then I would spend all of the next week making resizable panes and stuff like that. It's fun to be able to do that for myself and for the people in my life.

Drew: I think dad-driven development is great. So, I see interesting new feature releases and things from you guys all the time. I wanted to give you the chance to call out any exciting highlights, whether it's business-wise or product-wise. Any exciting milestones that you've hit recently?

Mikayla: In the last few months, we've actually released a ton of features. It's been a pretty crazy go, go, go time at Zed. We launched the agent panel a couple months ago. We also launched an integrated Git client, which turns out to be something a lot of people really like. We kept getting the feedback that people wanted integrated git. Being a lot of people from GitHub, Zed is full of Git CLI power users. So, we were surprised by that one. We also just launched a debugger. There's been a lot of feature releases lately that have really tipped Zed from being a work in progress to being close to general purpose. I think the most exciting development that I can talk about though is Windows. We are now properly staffed and committed and driving forward on Windows. There are some core technical things we're working on because the Windows platform is so different from macOS and Linux. I don't know if you've seen it, but we have this cute “Windows is coming” sort of website (linked below) that does a Windows 95 experience. Our Head of Marketing vibe-coded the whole thing in Opus. So, Windows is happening. Windows is coming. I promise.

Drew: One of the things a lot of people talk about with Rust is the cross-platform capabilities that it brings. Has it been relatively easy or relatively hard to target the different systems?

Mikayla: We made the problem harder than it would be for a lot of other projects in the space. Zed likes to build its own tools. We like to make them narrow and sharp for exactly what we're looking for. Also, the project that would become Zed was started back in 2018 before a lot of the Rust ecosystem was fully matured. So, it turns out there's a lot of little things that Zed specifically as a UI application runs into. For us, the big reason that Zed isn't cross-platform is because we are an integrated development environment, meaning that Zed needs to talk to your window, your GPU, in fact it needs to talk to every GPU you can plug into with every Windows and Linux distribution. Or, ideally it would. Obviously, it doesn’t work perfectly with everything, but we try to cover as much as possible, especially for recent tech.

Mikayla: On top of that, there's a lot of platform-specific things you want to do in a code editor like opening a URL or minimizing and maximizing the window. Because we've built gpui from scratch, we have to go to each of the platforms and figure out how to do it. There is code that we could have used, but we wanted to just go a little simpler than what’s out there. 2D UI is complicated, but it doesn't need the same things as a 3D scene in a video game. So, we're building all this ourselves and we don't use Winit or WGPU or any of these other things that have different goals. So, that all makes things more complicated. We haven't had any problem with Rust specifically. As you know, Rust is fantastic for all of this. The big problem has just been learning things like which random Objective-C function you have to call to make the window transparent on macOS.

Drew: Right. It's all the platform-specific APIs that you have to figure out how to use. That makes sense.

Mikayla: The one we've had the biggest struggle with is definitely talking to your GPU because GPU drivers have a lot of random problems and people are supposed to keep their drivers up to date. Obviously, we targeted MacOS first, which has actually been very nice as a first target. Apple is so tightly integrated that we don't have problems with GPUs nearly as often. We had it a little bit in the beginning for different displays and stuff like that. But, at this point, Apple has just solved the problem for us. We have to take on more complexity for the other platforms.

Drew: You also mentioned the launch of the Agent Panel. I don't want to just breeze by that because obviously we have this huge agentic editing war going on right now. It's pretty crazy out there! I guess I just wanted to ask or give you an opportunity to point out what you think is different about the Zed approach.

Mikayla: I think the fundamental problem with LLMs and the LLM integrations we're seeing everywhere is that there's no one to hold responsible. Responsibility is a really key part for how human society works. When something bad happens, you go talk to the person who is responsible for it. You can't do that with LLMs. LLMs can never “hold the bag”. They're not people. So, no matter how powerful and how crazy inventive and amazing these LLMs get, somebody's got to put their reputation on the line. That somebody is going to be a human until the AI labs figure out a fundamental change. Someone's going to have to hold the bag. And when you're holding the bag, you want to make sure that the code you're putting out into the world is working. To do that, you probably want to run some analyses on the code. That might be something as simple as compiling it, doing searches on it, or seeing what the language server has to say about it. All of those things are where we come in. We're here to make that the best experience possible. So, that's how I personally think about code editors and agents out into the future.

Mikayla: Nowadays it seems like everybody's building their own CLI agent. I think some of this is just things concentrating up into the big AI companies like OpenAI or Anthropic. That makes some sense, because I think they understand LLMs the best and can write the best prompts. They understand how the whole thing works from top to bottom. I think the reason terminals specifically have gotten so big is because they're easy to make UI for, they're low stress, and they already automatically integrate into everybody's existing tools.

Mikayla: In terms of our agent panel, I think terminals don't make great UI. So, I think there's a lot of room for us to coordinate with the big AI labs and use their knowledge of prompting and how these models work. But, I think over time we're going to see more negotiation around who is owning which part of the process. People like GUIs and left the terminal for a reason, so I think it’s unlikely they’ll go back to it in a big way. We'll see what happens.

Drew: It will be interesting. So, what are the more interesting things you've gotten to work on in your time at Zed?

Mikayla: The thing I find the most interesting personally is gpui, our UI framework. I am personally invested in making it general use because it is already very general purpose. Anybody can use it. But, there are a lot of things missing that would make it straightforward to use. For example, we don't ship an input component because we built all that as part of our editor. The UI framework gives you the tools to make one, but we don't ship one. So, I think the thing I find most interesting is taking this custom tool that no one else knows how to use and learning how to make it sing. There's been a long history of UI frameworks out there. When I started out, I spent a lot of time working with jQuery and HTML in the DOM. How can we do better? So, I find it super interesting and challenging for me to build a UI framework with all the tools Rust gives us instead of all the tools that JavaScript and HTML give us.

Mikayla: I would say another really interesting aspect of this has been working on the terminal. It’s actually the first thing I built at Zed. I was hired as an intern at the time for a three-month summer project. I was like, "All right, let me see what's in Zed. Oh, wow, there's not a lot here. Looks like you need a terminal." It was on their to-do list, so I just decided to take it on and get it shipped. I learned so many cursed facts about computers through that project. Did you know that there has been protocol compatibility from typewriters all the way to every modern IDE? There is this one character called the bell character which exists because there used to be a bell on the typewriter. When you sent the bell character, it rang the bell in the typewriter. Then there’s this whole evolution where Morse Code was turned into something the name of which I can’t remember (ed: telegraph codes) that turned into ASCII and then UTF-8. There's this 100+ years of history of communication protocols that are all backwards compatible with each other. That's so cool and weird. It's an interesting feeling being in the age of LLMs but also deep in the past where they rang a physical bell. That juxtaposition brings me a lot of joy.

Drew: Yeah, that's awesome. Usually I ask people where Rust fits in their stack, but I think with Zed that answer is pretty straightforward.

Mikayla: 100%. Yeah, the whole thing!

Drew: So, why is Rust the right language for this task?

Mikayla: Rust makes projects like Zed viable. There are IDEs that were written long before Electron, and there will be many IDEs written afterward. But, a lot of them use a system-level programming language for one part and then write the rest in something else, because it turns out systems programming sucks real bad because of pointers and segmentation faults and so on. So, there's this pattern of, "Okay, we've got this little core thing in the system language, now let’s bail. Let's get out of here, because, oh boy, if I have to deal with another segmentation fault, I'm going to die." With Rust, we don't have to do that. We do the full stack in Rust because it is actually reasonable to expect you can do that in a reasonable amount of time without your program crashing all the time. Rust has really solved some fundamental problems. Would I say Rust is the perfect language for this project? I would definitely say not. There’s no perfect. But, it’s great and getting better. There's this Rust ergonomics initiative that I'm extremely excited for. If we got easy clones and partial borrows, I think it would be a whole new language for us.

Drew: Rust has that unique ability to be applied to all the different layers of the stack reasonably.

Mikayla: Yeah, and we actually use this really heavily. For example, in our testing we have ordinary-ish Rust tests that spin up multiple clients, spin up a server, and have them talking over fake network channels. We do property testing by ordering some messages over these different things. It’s things like "Oh, person A opens a buffer, person B jumps to a line while person A deletes that line," now check, "Is everything what it should be?" To accomplish that, we just use the same code we've been writing. We just call the internal APIs you would have called anyway. We don't need to do anything extra to have this sort of communication. They're just Rust structs. We just call methods on them. They're orchestrated by our framework, and there's a server that makes sure everything is happening, but that is a lot easier to write than if you’re spawning processes and passing messages because there’s a bunch of different languages involved.

Drew: So I’m told Zed is hiring?

Mikayla: Zed is hiring. We are.

Drew: What do you guys tend to look for in new hires?

Mikayla: We tend to look for three things. Obviously, you need to know your stuff. If you're able to think through problems and understand constraints, write good code, and test it well, those are kind of the fundamentals. One of the things that I see people have more trouble with is that Zed is a very social place. Engineers tend to be a little more introverted, so this could be a challenge for some. It's really important that we pair like I talked about before, because that's how information transfer is done. It's how Zed works. So, it’s really important that you’re a good communicator and a good person to work with.

Mikayla: The other thing that can be a challenge for some is that Zed is really set up for self-starters. We have very little process. We have very little hierarchy. There’s basically the founders and then everybody's just kind of in a big pool. People might have specific roles, but there's no managers really. There's none of that structure. This is great if you want to get a lot of cool things done, but it also means that you need to have a certain amount of a self-driven mentality. I think the ideal thing is if you come to Zed and you really want a particular feature and you can actually just get it done. If you can do that, you’re like a perfect candidate. If you're capable of understanding the code base to do that, that's amazing. Also, if you're able to talk to us and be like, "Hey, I really want to add this. I think such and such way of doing it would work. What do you all think?" Then we can have a dialogue and work through a solution. Nothing happens at Zed if you don't make it happen. We're also a growing company, so things are always changing.

Drew: My next question was about culture, and you kind of hit on some things there. You mentioned the social, self-starter type culture and the flat of flat hierarchy. You also mentioned the distributed nature. People are all over, and you're always trying to sync up schedules to pair program and stuff like that. Is there anything else unusual about the culture that you would want to call out?

Mikayla: Zed is very, very lively. There's a lot of discussion. Discussion is honestly the number one thing. There's a saying that says that you should have "strong opinions, weakly held." Basically, you own your ideas and believe them, but when someone has a better idea you’re able to recognize it and change. For me, the way I approach this is I trust that there is ultimately a fast, good way of doing something, and everyone is collaborating in good faith to find it. I think that's a really killer part of the Zed culture. People stand their ground but also know when to move positions.

Drew: Okay, so here’s my last culture question. Is there anything unusual about compensation or benefits that would be interesting to point out?

Mikayla: Back in the day when the product wasn’t open to the public, I used to say that one of the benefits was that you got to use Zed. That was fun. Let’s see… There's unlimited time off. So, basically as long as the work gets done you can figure out what you need to do. One thing we've been doing for the last year is going to conferences together. It's always a really good time talking to our users and showing off Zed. We usually organize our company all-hands around Rust conferences so we're all in the same city. It's been kind of funny a couple times because we have so many people. We'll have like 15 people getting together at one booth at Rust conferences. We often kind of take over a little corner of the space because there's way more people than we need.

Mikayla: Here's another unique benefit. Zed is all about writing code. So, if you’re someone who doesn't want a lot of meetings, we got you! Also, we're an open source GPL project with VC funding. That’s a unique mix! Obviously we’re not the only startup in that situation, but it’s not common.

Drew: Actually, you know, you reminded me of something that I should have made a note to ask. Usually when a company is open source and in startup mode, one of the questions is what's the revenue model?

Mikayla: We get that question all the time. It's a little hard to answer because we haven't really tried to do it yet. But, there are three things we're looking at for revenue right now. One of those is token reselling. We can kind of be your one-stop shop to buy tokens for programming. That one might not be super sustainable based on various things happening out here. But, it's nice to have.

Mikayla: Another option is a closed source fork that has enterprise features, things like single sign-on, custom deployments, control over extensions, etc. There's a lot of things that we do not want to put in the regular product that an enterprise will need.

Mikayla: The third thing though is really the big vision, and that is collaboration. Long-term we really want to change how software is done. We really believe in CRDTs and getting these in at the foundation of your experience. For example, the edits going into a pairing session and the transcript of the session should all be context for LLMs. You should be able to take a slider and slide back and forth and watch the project be undone and redone. So, you can start to imagine a more CRDT-based version of GitHub. That is the long-term 10,000-foot vision. The reason we're a startup and not just a nice open source project is because that's a big vision. It's one that starts with having an amazing code editor. We think that once you have that code editor you're already at the right spot to take your normal files and turn them into CRDTs. Then you can do all this crazy stuff with them. There's a lot of this vision that isn't hashed out yet, but the long-term goal is CRDTs and cloud services based on those CRDTs along with live collaboration and other things you can do with keystroke-level granularity that you can't do with Git.

Drew: That was kind of the end of what I wanted to ask about, but I always like to ask if there's anything you wish we'd had the chance to discuss.

Mikayla: So, one thing I'd love for more people to know is that we have kind of two ways you can get hired. Obviously we have a normal hiring process. You can go look at our jobs. There's a bunch of jobs on our Zed jobs page. But, we've also had a lot of success hiring from open source as well. We'll have some really smart people come in and just start making PRs and adding features. We've made really good hires from open source contributors. So, maybe if you feel like your resume doesn't have what it needs on it, or if you're just uncomfortable with the uncertainty of throwing it out into the void, I would really encourage you to just get our attention by showing up and doing good work. I know Conrad and probably a few others also make a habit of publishing calendar links where you can just get some time to pair with us. So, there’s always a path into Zed that starts with just showing up, talking to us, and doing good work. I'm not asking for free work at all. I'm just saying this is an option that exists if it works better for your situation than the normal application review.

Drew: I love that you pointed that out. That is so cool for people that maybe don't feel like their resume is going to really communicate their potential. They can just submit a pull request.

Mikayla: Yes, submit a pull request and talk to us. Even more than sending a pull request, talk to us. Another thing I should mention is that part of this collaborative vision is this fun channel feature. Those are public, and we spend all day long jumping in public channels and working together. So, you can just ride along. We're an extremely open company.

Drew: Thanks so much for your time Mikayla!

Mikayla: Thank you!