Ben Edelstein: Hello and welcome to PodRocket. Today I'm here with Zach Lloyd who's the founder and CEO of Warp. How are you, Zach? Zach LLoyd: I'm doing pretty well. Thank you so much for having me, Ben. Ben Edelstein: Yeah. I mean, I'm really excited about this episode. I was checking out the Warp website and just really cool to see some folks innovating on the age-old developer tool, that is the terminal. So, maybe you could give us a quick overview about what you're building. Zach LLoyd: Sure. So, we're building kind of a re-imagined version of the terminal. Trying to make it a modern product, in the sense that if you were to look at what developers do in the terminal and you were to redesign it from first principles, while still trying to make it basically backwards compatible with today's workflows, what are the different improvements that you would make? And so, for us, that's trying to make a terminal that's more usable. It's trying to make a terminal where it's harder to make catastrophic mistakes, where it's easier to learn how it works, where it's collaborative and works for teams. And so, that's what we're trying to do. Ben Edelstein: Got it. So maybe we could break down those three kind of pillars you mentioned, the first being usable. So, how is Warp more usable than the typical terminals out there? Zach LLoyd: Yeah. So, there's a few big differences right off the bat with how input and output work in Warp. So, if you use a normal terminal, on the input side, the text editing experience doesn't work like it works in any other app that you likely use. So, for instance, you can't click and put the cursor someplace. If you select text and hit delete, it doesn't get deleted or it'll delete a character at the end of a line. It doesn't have the normal key bindings for like cut, copy, paste. And then, advanced things that people do in their text editors like VS Code, like multi-cursor editing or syntax highlighting, none of that stuff works in a normal terminal. So if you are new to that environment and you start using it, you're kind of, right off the bat, taking a step backwards in productivity with input. Zach LLoyd: On the output side in a normal terminal, all of the output is just one big stream of text. So there's no demarcation about when one command starts and ends. In Warp, we have this concept called blocks where you can take actions on the individual commands that you've run. You can navigate your terminal on a command by command basis. And this fixes basic things like, "Hey, I just ran a command and I wanna copy the output of that command." I don't have to scroll to the perfect spot with my mouse and do that. I can just sort of select a block, hit copy and get the right thing. I could share contents from block. So those are like the really basic things that we're trying to solve, or like the things developers do every day in the terminal that are not familiar or not ergonomic. Ben Edelstein: Got it. That makes a lot of sense. So, basically, like a text editing experience like VS Code or Sublime that just feels natural and normal to what people are expecting. I would agree that whenever I'm using the terminal, it always works a little differently than I expect. And even though I've used it a million times, I always have to adjust my brain to, you know, "This is how you select text. This is how you go to the end or the beginning." And so, I feel like that certainly seems clearly useful to just make it easier and more modern. You mentioned pillar number two, originally, is helping avoid mistakes. So, what does that look like? Zach LLoyd: Yeah. So that looks like... I think it's like, how do you make it so that people enter the right commands and kind of know what they're doing. In the terminal, it's like one of the big areas, and how do you make the terminal configured so it works better for people? And so in Warp, we ship with most configuration. We ship with like a set of sensible defaults. That's one thing that you get with Warp. Zach LLoyd: And so, for instance, completions just come out of the box. You don't have to go and find a third-party tool to help you get completions. You don't have to make any changes to your RC files. And so, we help you write the commands. And I don't know if that's really about error prevention as much as it is about just, again, making the terminal a faster, more intuitive tool, but it's certainly useful. We ship with auto-suggestions, out-of-the-box. We ship with feature, which is really cool, where if you don't know how to do something, you can look it up using AI through Codex. And so, it's really about helping people get to the command that they wanna get to faster. Zach LLoyd: We would like to add some stuff around actual error prevention. Meaning like if you're about to enter a command, can we sort of scan it and give you something like auto-correct? Be like, "Hey," it's red-underlined, "This is not right." Or you're about to do something dangerous that you pasted from the internet, can we kind of put some guardrails on that? Like, "Hey, don't [inaudible 00:05:45] -rf your root directory." Or, "This is a known suspicious thing, don't just execute it. Zach LLoyd: In a collaborative context, what we wanna do is let people sort of get approvals for commands that they're thinking about running. So it's like if you're gonna do something semi-dangerous in production, can you have someone else on your team sign off on it? So, those are some things that we either have built or are planning on building to help make it easier to do the right thing in the terminal. Ben Edelstein: Got it. And on the autocomplete side of things, I think you mentioned AI a bit. There's a couple of tools in this space that have tried or are actively applying AI to autocomplete. Like there's GitHub Copilot, which I never actually use, but I always see people on Twitter talking about how awesome it is. And there's one called Kite that I'm not sure if it's still around or not. But are the techniques you use to do autocomplete similar to what those tools are doing when... I mean, those are more like on the actual writing code side, so have a more abstract problem, but kind of similar or is that the right way to think about it? Zach LLoyd: Yeah. Well, the underlying technology that we use is actually the same as what Copilot uses. So Copilot uses an API from OpenAI called Codex. And so, we're actually using that same API. We don't capture anyone's data or build our own model or anything like that at the moment. What we've done is kind of made it very easy in the terminal setting to use natural language to figure out how you do a command. Zach LLoyd: And so, it's slightly different than Copilot in the sense that Copilot's trying to help you sort of write source codes snippets and it's very cool. We're more of like, "How do I tar an archive, create a tar archive in my current directory that has a certain name?" And you can just type that in. And so, rather than going to stack overflow and like having to sift through a bunch of stuff, it actually will suggest right in the terminal, hey, this is tar - whatever it is, to run, which is super useful application of that technology. Ben Edelstein: Yeah, certainly. And do you have documentation for common commands surfaced in in-line or is that something on... I saw something about documentation on the website, so I'm not sure if that's... Zach LLoyd: We do have this. So this is another feature that we have. I think it's really cool. It's called Workflows. And, basically, it's like instead of with completions, where you're trying to sort of build up a command one word at a time, you do like git space, and then you hit tab, and it gives you a bunch of choices, and then you choose checkout, and then you hit dash dash, and you hit space. So rather than building a command a word at a time, the idea with Workflows is that you can search by what you're trying to do. I think an easy example is like, how do I undo my last git commit? And we'll give you the entire command for it. And we'll actually even show you documentation around like, well, what does that command do? Zach LLoyd: If it has parameters, we'll kind of aid you in inputting those parameters. So it's like, we'll show you like, hey, if you're trying to curl something, the URL goes here, the flags for the headers go there and we'll tell you what each parameter means. And it's meant to be an easy way to save commands to... You can actually save them with a file-based format right now and add new ones. We have a public repo where people are contributing sort of commonly used things, on a tool by tool basis. And then, eventually, what we wanna do is make it so this is a really compelling feature for teams where they're building up libraries of safe commands to use internally. Ben Edelstein: Yeah. I mean, that also makes a lot of sense. Like I know nowadays a lot of teams have like a Google doc or something with all the common commands and a new engineer is onboarding and they just say, "Hey, go look at the command of this Google doc. Here's how you do X. Here's how you do Y." But yeah, bringing that right into the terminal where you're actually running the commands and you can have deeper context seems clearly useful. Zach LLoyd: Yeah. That's exactly the idea. Ben Edelstein: And then you touched on this a bit on the collaborative side of things you mentioned before. Like an idea... I don't know if you do this today or it's on the roadmap, you said, of like when someone's about to do something dangerous on a team-based setting, maybe you're running the command on prod and it says, "Hey, this is a dangerous command. Let's get approval from someone else." Is that kind of the main idea behind the collaboration or are there other collaborative features on the roadmap as well? Zach LLoyd: There's other stuff too. So, we don't have that implemented. I think our focus thus far has really been about building a better single user terminal experience. But I do think that that sort of command approval flow is pretty interesting. The other things that I think are really interesting are, you can think of it in terms of asynchronous for synchronous collaboration. So, there's asynchronous use case, which is kind of like the Google docs or Figma use case, where it used to be that I could have someone look over my shoulder and sort of tell me how to fix something in my terminal setup when my path isn't set right or I'm missing some random environment variable. We would like to enable that natively where you could have multiple people in a live terminal session and the use cases around sort of joint debugging or joint looking at production. So that's one use case that's really powerful that's on our roadmap. Zach LLoyd: The other one is more along the lines of what I was talking about with safe commands, which is like, what are the sort of pieces of knowledge or things that you do in the terminal that you could share directly from within the tool? So, it could be commands, it could be a richer version of that, which is like a notebook concept where you can put like an entire workflow for like, "Hey, how do you do a database upgrade?" Well, it's these commands and here's the documentation and here's what you should do if this happens, or if that happens. And so, these are things that we wanna sort of build into the tool as first-class modes of collaboration. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan Hughes and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So, check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show. Ben Edelstein: Pivoting a bit, I'm curious to understand more on the business model side of things. And first question is, is Warp open source or any plans to be open source, or how are you thinking about that decision? Zach LLoyd: So, Warp's not currently open source. We have a few open source repos that are like extension points into Warp. So that's like where you can submit themes or workflows. I would say it's very likely, but not definite that the core client app will also be open source. I think it's to our benefit to do that from a adoption standpoint, from a visibility, so that people can audit that we aren't making any mistakes with privacy or security. It's kind of a one-way sort of valve. So once you do it, it's done, and we wanna be pretty deliberate in choosing the license and the timing and making sure that the code base is in a good spot before we do it. But I think it's quite likely that we will open source the client. I don't know the exact timing that we will do it. Ben Edelstein: Yeah. I mean, that makes sense. It does kind of feel like it's a good fit for an open core model where you have the basic client is open source for the exact reasons you mentioned, and then I'd guess maybe the collaboration or some of the other features may be closed source and that's where you monetize long term. Zach LLoyd: That's exactly the plan. I think it's unlikely that the server components would be open source, but there would be an API defined. So if anyone else wants to implement them, it's possible. But yeah. The business that we wanna build is around monetizing collaboration. It's around monetizing things that have like a marginal cost in the cloud, and that are differentiated things that terminals don't do today. And I think that that's very compatible with a model where the client code is open source. Ben Edelstein: And on the subject of the server side of things, I mean, terminal... I don't know of any other terminal that has any server component right there. It's kind of the quintessential local application. So, when you launched on Hacker News, there was some, maybe we can call it healthy skepticism, about the fact that there is a server component, and some amount of data is exchanged between client and server. So, what data do you collect from the client side? Like what data is getting sent to the server and how do you kind of think about security, privacy, et cetera? Zach LLoyd: Yes. There was a healthy amount, you can call it skepticism or critical feedback. It made complete sense. I guess, first let me say what we don't send. It's we don't send anything you type in the terminal and we don't send anything the terminal outputs when you run a command. Just like full stop. There's no recording of what you're doing in a terminal session. The only exception to that is if you explicitly use our feature where you want to share a thing you did, which is our block sharing feature, and you have to go click create permalink. And in that case, we store it because we are basically saying we're gonna serve that on a web endpoint. So that's what we don't store. Zach LLoyd: What we do store right now in our... Again, I would say quite likely to make optional, is telemetry. Meaning like, how is a person using the app? Like for instance, are they using split paints? Are they using our command pallet? Are they using random features? And so, the reason for this is we want some feedback in terms of, are the things that we're building actually valuable to users? And so that's like... I think we've gotten enough feedback and I think it's reasonable feedback that will make this optional, but it is super useful to us as a early-stage startup to know if we're building the right things. Ben Edelstein: Yeah. That makes sense. And I imagine another advantage of, eventually, if you open source the client, then it is very obvious to folks what you're collecting and what you're not collecting. And then there's no ambiguity at that point. Zach LLoyd: 100%. We publish right now, even on our privacy page, a complete list of all the telemetry events. But we're an early-stage startup. And so, it's a big ask for people to trust us and I am understanding of the skepticism if you can't see the code and it's a company that's new. And so, I think we have to do more to earn the trust of our users, and that's something that's top of mind. But the feedback made total sense and it's something that we're figuring out how to address. Ben Edelstein: So, one of the things that is kind of cool or I think a lot of people appreciate about the traditional terminals and especially the popular ones like iTerm, is that they're pretty extensible. I mean, you can use Bash or Zsh, or there's a few different interfaces, and then you can customize colors. And I mean, the sky is the limit in terms of how people customize their terminals nowadays. Is there a future, or in the present, can you customize Warp to some extent? Or maybe down the road, would that be something where you have a plugin ecosystem or a configuration language or something like that that people can use to really tailor the experience to their needs? Zach LLoyd: For sure. So today, Warp also supports Bash, Zsh and Fish. So you can use your own shell and you don't... We thought about building a shell, and maybe one day we will, because I actually think there would be value in like a deeper integration further down towards the OS level, but for compatibility reasons, we made it so people can use their own shell today. And then we have, I would say, decent configurability for where the product is at right now. So you can you can make your own themes. And so, there's like a YAML format for that. Zach LLoyd: So you can do a pretty good job of customizing the look and feel of the terminal. You can make your own key bindings and keyboard shortcuts. There's also a data format that underlies that. Like I said, there's a Workflows data format. But relative to something like iTerm which has just been around a lot longer, we don't have all of the sort of knobs for configuration yet. So that's the configuration piece. Zach LLoyd: My general product philosophy on this is that the terminal needs to... Actually out-of-the-box require less configuration to be useful. It's not that it's too configurable, it's that the defaults that it ships with are too underpowered and unintuitive. And so, we're trying to ship it with less configuration required and a more out-of-the-box batteries included experience. But we also wanna allow developers to configure it because it's such a core tool in their workflow and every developer works a little bit differently and should be able to tweak it to their liking. So, that's the configuration side. Zach LLoyd: On the extensibility side, I think, it's a huge opportunity to build something that is more of a platform for the command line than just a product. I think we need to have a set of API extension points that developers can build into to make it really easy to find the right completions you need or the right workflows you need for whatever tools you're using. And so, that's something that we really wanna sort of lean into. Again, in our product life cycle, we're pretty early on this, but I think the way it works today with people just finding like a GitHub repo that has like a cool terminal enhancement, and then they kind of curl it through Bash, leads to like a messy configuration system. It's not very discoverable, what's out there, to make your terminal better. And so, I think we can build something that's much better than that. Ben Edelstein: So, on your website you kind of proudly proclaim that there's no Electron or Web-tech involved in implementing Warp. And I imagine probably that it has to do with performance. I mean, it's no secret that Electron isn't the most performant platform. And it seems that you use Rust and [inaudible 00:21:35] native app built with Rust. So, I'm curious. In addition to performance, were there other reasons why you went with Rust and kind of more, specifically, what stack you're using alongside Rust? Zach LLoyd: Sure. So, it was primarily motivated by performance. We actually tested... An early version of Warp was written in Electron and it didn't perform well. The reasons that we chose Rust, so definitely performance was a big part of it. A second part of it was pretty good cross-platform support. So, I would say 90% of our code base is platform agnostic and we will use it to compile Warp for Linux, for Windows, and hopefully also for the Web using web assembly. The rest of our stack on the client is... So, it's Rust and then it's a GPU-accelerated terminal. So we actually do sort of a full stack of rendering. Meaning we have our own UI framework that we wrote in Rust, and then we actually have our own Shader code, and sort of every pixel on the screen is kind of within our code base. Zach LLoyd: There's like pros and cons to doing that. The pros are that we have complete control over the rendering and can optimize all parts and don't have any big dependencies. The cons are that it's more work. We get less for free. And consequently, it's like some things that you would just like to not have to worry about as a developer, you have to worry about in Warp. But overall, I think it was the right trade-off for the application that we're building. Ben Edelstein: And you mentioned, eventually, maybe being able to target Web as a platform to run Warp in. So would that be like... Or maybe you tell me, what would the context be in which you'd want to have Warp running in a browser? Zach LLoyd: Yeah. So I think there's a couple compelling contexts. One is if you're using Warp against a remote machine, and so there's a Cloud Shell use case. So if you look at like Google Cloud or AWS or Azure, they all have this nice thing in their consoles where you can pull up a terminal against a machine that's running Docker and running a server, and you can debug against it. It would be nice to be able to use Warp for that case. Because those Cloud Shells which are like xterm.js, they don't have your configuration, they don't have any of the nice input-output features of Warp. And so, I think having like a richer terminal interface is just as compelling there as it is if you're using it for local development. Zach LLoyd: The second use case that I think is really cool is collaboration. And so, if you want people to be able to sort of join a session, I think it's nicer to be able to share that session by link and have them pull it up in a Web browser, than it is having to do like a full download of a native app. So I think for the sharing use case if you wanna be able to check Warp on your phone, all of those things are super nice to have a Web rendering. Ben Edelstein: So, taking a step back from the product, I'm curious about your background and what led you to wanna go and start this company. Zach LLoyd: Yeah. Good question. So, my background. I've been a developer now for, I don't know, like 17, 18, maybe 20 years, depending on when you count the start of it. Probably the most significant thing I've done was, I was a principal engineer at Google. I helped build and manage and run the Google Sheets team. And so, I built a lot of that product. And then when I left Google, I was a principal engineer, I was like the tech lead for Google Doc Suite. And so, my strongest technical background actually is in building these kind of collaborative productivity apps. Zach LLoyd: And so, one of the things that led me to start at Warp was just like I feel really comfortable building this kind of app. I've seen the value that adding collaboration on top of a traditionally desktop app can build. And you get value in ways that you don't even really expect. I've kind of built apps that involve like the processing of a lot of text. And so, there's actual technical lessons from doing Google Docs that are applicable to Warp. In fact, one of the reasons we're doing it native, is because we could never really get the performance in a browser for something like Google Sheets on par with Excel, and it drove me nuts. And so, yeah. Those things all led me sort of towards doing this. Zach LLoyd: I've also been a startup founder. I left Google a while ago. And so I did another company that was in a totally different space, but a lot of the lessons of starting a company are things that are transferable. And so, I've tried to be really sort of intentional about how we build the team and the culture and use the lessons from my last startup. And so, all those things make me feel really excited about what we're building. Ben Edelstein: Could you highlight like one or two of those few lessons, both on the technical side, things you learned building Google Sheets and Google Docs, and then after that, maybe on the startup building side? Zach LLoyd: For sure. So on the technical side. So if you're building something like Google Sheets, the big challenge from a performance standpoint is how do you handle lots of data, like big sheets? And what that comes down to is a lot of being very careful in terms of how you control the memory layout. If you're not smart about how you make a big spreadsheet, you're gonna have gigs and gigs of RAM. And in the browser context, you're just fundamentally limited in terms of how much control you have. Zach LLoyd: JavaScript doesn't really let you control what size your cells are, it doesn't really let you control garbage collection, which can end up being quite slow. Because you're kind of counting on the just-in-time compilation of something like VA, which is good, but not as good as native. And I felt like we ended up spending a tremendous amount of cycles on performance work, where had we had deeper control over the platform, we wouldn't have had to spend that much time. And we would've also been able to get to a faster product. So that was, from a tactical standpoint, one of the big lessons of Google Sheets. Zach LLoyd: Google Docs was like, start with a faster platform. Now, you can still write slow code in Rust. Like if you write an algorithm that's N squared or do something silly, it's like... Any platform you can write something slow in, but you don't pay an upfront penalty for writing in Rust in the same way that you do writing for the Web. That makes sense? Ben Edelstein: Yeah. Zach LLoyd: And then for the startup lessons, I would say the things that have been... My biggest [inaudible 00:29:17] personally changes in terms of how I'm approaching Warp as a startup rather than my prior startup, is just like how much sort of work upfront we're putting into defining the kind of culture that we want. And so for us, that's like a culture of transparency, it's a culture of pragmatism, it's a culture of hiring people who are very product and user focused. I've really trying to be intentional with who comes onto the team. Are they really interested in solving the problem? It's trying not to grow too quickly before we've actually got the base thing working correctly. Zach LLoyd: And so, these are all things I just wouldn't have known had I not started a company previously. And I think it's helped us to get to like a team that's relatively small, but extremely high quality, where I love working with all the people. And so, that's been a really good lesson for doing a startup once. Ben Edelstein: So, to close things out, I'm curious to learn a bit more about what you see as the long term roadmap. We already spoke about a number of the short term things that you're gonna build and we talked about the future of the business model. But just like five, 10 years, what is the future of just the terminal overall, and how does Warp fit into that? Zach LLoyd: Yeah. So, the long term vision and the reason I think this is a really cool thing to work on and a cool opportunity, is that the terminal is, one, it's extremely widely used. So it's a tool that almost every developer uses every day, whether they want to or not. And it's a really low level tool in the sense of like a lot of different development activities flow through it. Whether it's building, running, debugging code, or interacting with cloud systems, or interacting with different APIs from other developer companies. And so, I think if you could meaningfully improve it, it's a huge point of leverage for helping developers get more done. Zach LLoyd: And so that's like big, big picture of what we want to do. Is build something that's like... I don't know, even if it's just like 20% more efficient for every developer, that's a tremendous amount of savings of developer time and developer productivity for the world at large. Pretty much every business hires developers. And so, I would be very happy with that as a base outcome. Zach LLoyd: I also think that there's stuff that's like adjacent to the terminal where we eventually could sort of start to play and expand. The mission of the company is to elevate developer productivity. It's not just like to build the best possible terminal. And so, things I think we could eventually sort of experiment with are code editing. A lot of developers still use the terminal as their code editor. I think we could get into, how do you make remote development easier, so you're not developing on your local machine? I think we could get into, how do you make sort of building internal apps easier? Like if you think about it, CLIs, a lot of them would be useful beyond someone's just local machine. And so, those are areas that I think we will start to explore. But for now, the focus is on just like let's just make this tool as good as it possibly can be so developers can get more done. Ben Edelstein: Awesome. Well, Zach, it's been a pleasure having you on, and really enjoyed learning about Warp and hearing about your perspective on the future. For anyone out there who's interested in learning more, the website is warp.dev. Is that what you'd recommend for someone who wants to check it out or any other resources that you'd wanna point people towards? Zach LLoyd: So warp.dev is great. One plug I'll make is that we are hiring, and if you're someone who's interested in developer tools and building great products, would love to talk to you. The website's the best place to start. You can download the product and play with it if you have a Mac. We've also documented a lot of our culture and how we work if you're interested in checking that out. Ben Edelstein: Great. Well, thanks again, Zach. Zach LLoyd: Thank you so much for having me. Kate: Thanks for listening to PodRocket. You can find us at PodRocketpod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.