Warp with Zach Lloyd
Warp founder Zach Lloyd discusses building a modern terminal in Rust, rethinking developer UX, and turning a command-line tool into a business.
Episode Description
Warp founder Zach Lloyd discusses building a modern terminal in Rust, rethinking developer UX, and turning a command-line tool into a business.
Episode Summary
Zach Lloyd, founder and CEO of Warp, joins Anthony Campolo and Christopher Burns to explain why he left Google, where he led engineering on Google Sheets, to build a reimagined terminal. The conversation traces the core UX improvements Warp introduces—a real text editor for input, block-based output grouping, and built-in completions—before moving into the technical decision to build the entire app in Rust rather than Electron, a choice driven by the performance lessons Lloyd learned fighting JavaScript limitations at Google. The hosts and Lloyd then explore the business model, which mirrors Figma and Notion: a free individual product that spreads organically into teams, with paid features around collaboration, security, and onboarding. A substantial portion of the discussion centers on the terminal's broader shortcomings—inconsistent help formats, inaccessible interfaces, overwhelming error output—and how Warp's structural awareness of commands and output positions it to solve problems a traditional character-rendering terminal never could. Lloyd shares the near-term roadmap, including assistive command correction, extensible completions, and knowledge-sharing prototypes, while fielding questions about platform support, VS Code integration, shell compatibility, and the potential to one day write Warp's own shell.
Chapters
00:00:00 - Meet Zach Lloyd and the Origin of Warp
Anthony Campolo introduces Zach Lloyd, founder of Warp, and shares his own enthusiasm as a daily user of the terminal. Zach recounts his career path: over twenty years as a developer, a long stint at Google where he led the engineering team behind Google Sheets, and a previous startup in marketing technology. He explains that after his first startup he wanted to solve a problem he personally experienced every day.
That search led him to the terminal, a tool used by nearly every developer yet largely unchanged for decades. He saw an opportunity not just to improve the UX but to make the terminal collaborative, more secure, and ultimately the foundation of an enterprise business—a pitch that required convincing investors since no dedicated terminal company had existed before.
00:03:06 - Core Features That Redefine Terminal UX
Zach walks through the specific improvements Warp brings to everyday terminal use. On the input side, Warp replaces the default terminal editor with a real text editor where the mouse works, selections behave as expected, and multi-line commands are intuitive—comparable to writing code in VS Code. On the output side, Warp introduces "blocks" that group each command with its output, creating a notebook-like experience that makes copying, navigating, and sharing results far easier.
Beyond input and output, the conversation touches on additional features like natural-language search powered by OpenAI's Codex, templatized command workflows backed by an open-source repository, and the overall reduction in configuration overhead. Anthony emphasizes that the real test of Warp's value is the pain that returns when you switch back to a conventional terminal.
00:06:10 - Why Rust and Not Electron
Christopher asks about the technology behind Warp, contrasting it with Electron-based predecessors like Hyper Terminal. Zach explains that Warp is a fully native Rust application—from UI framework to shader code—because an early Electron prototype proved fast to build but slow to use. He draws a direct parallel to Google Sheets, where the team spent years trying to match Excel's performance but felt constrained by JavaScript's lack of low-level memory control.
Rust gave the team complete control over performance, and despite a steeper learning curve, the trade-off has paid off with very few crashes and reliable speed. The hosts note Rust's growing popularity in the tooling ecosystem, referencing Vercel's Turbopack and Stack Overflow's "most loved language" surveys, while Zach clarifies that marketing buzz wasn't the reason they chose it—performance was.
00:10:36 - Platform Support and the Path Beyond Mac
Christopher and Anthony raise the question of multi-platform support. Zach confirms Warp is Mac-only today but explains that roughly ninety percent of its Rust codebase is portable, positioning the team to compile for Linux first, then potentially a WebAssembly-based web version and Windows. Linux is the most requested platform on their GitHub, with Windows close behind.
The conversation broadens into how being a funded company rather than a volunteer open-source project changes the calculus around platform support. Anthony argues that financial incentives naturally push a company to serve Windows users, whereas unfunded projects often deprioritize platforms their maintainers don't personally use. Zach agrees, stressing the goal is to nail one platform before expanding.
00:13:09 - Building a Business Around the Terminal
Zach outlines Warp's business strategy, modeled after Figma and Notion: offer a free product individuals love, let it spread organically through teams, then charge enterprises for collaboration, onboarding, security, and internal-tooling integrations. Anthony highlights the security angle specifically, recounting the common but alarming practice of sharing environment variables through Slack messages and local files.
Zach agrees, noting that API keys routinely end up in insecure local files, and points to companies like Doppler that exist solely to address secrets management. Because Warp is the actual tool developers work in—not a sidecar utility—he sees a unique point of leverage for improving security, reliability, and workflow problems that all flow through the terminal.
00:16:06 - Rethinking Terminal Discoverability and Standardization
Christopher raises the broader issue of terminal discoverability, pointing out that help messages, error output, and command conventions vary wildly across tools. He imagines a future where changing into a project directory automatically surfaces the most relevant commands. Zach responds that Warp's structural understanding of commands and output makes features like filterable logs, collapsible JSON, and contextual suggestions feasible—things a traditional character-rendering terminal cannot do.
The discussion also covers how conventional terminals are essentially black boxes that have no awareness of what the characters on screen represent. Warp's block model gives it at least minimal structure, which opens the door to standardizing how help text is displayed, how errors are surfaced, and how developers discover what a tool can do.
00:22:29 - Shells, SSH, and Accessibility
Christopher asks about shell compatibility, and Zach confirms Warp supports bash, zsh, and fish, honoring existing user configurations so the transition is frictionless. He hints that Warp may eventually write its own shell to achieve deeper vertical integration but says that isn't on the short-term roadmap. The conversation also revisits SSH, where Zach explains that Warp preserves completions, themes, and editor behavior on remote machines—a notable improvement over the typical experience of losing all customizations.
Accessibility emerges as another key theme. Zach describes ongoing work with outside contributors to improve VoiceOver support, arguing that Warp's structural awareness of commands and output gives it a natural advantage. He frames terminal inaccessibility broadly: it affects people with visual impairments, but also beginners intimidated by an opaque, undiscoverable interface.
00:25:13 - Roadmap, Hiring, and Closing Thoughts
Anthony asks how the team prioritizes among hundreds of open issues. Zach describes balancing high-impact user requests against effort, while also investing in forward-looking features. Near-term plans include tab reordering, flexible input positioning, assistive command correction built natively into Warp, extensible completions, and prototypes for shared terminal notebooks that help onboard new team members.
The episode wraps with Zach sharing that Warp is hiring remote-first engineers with offices in New York and San Francisco, and he encourages listeners to try the product, join the Discord, and provide feedback. A lighthearted closing exchange about light mode versus dark mode—Zach is firmly dark mode—caps off the conversation at 00:34:01.
Transcript
00:00:00 - Zach Lloyd
Oh, awesome.
00:00:10 - Anthony Campolo
Zach Lloyd, welcome to the show.
00:00:12 - Zach Lloyd
Thank you. Thanks for having me on, Anthony.
00:00:14 - Anthony Campolo
I'm really excited to chat about Warp today. I am a Warp superuser. It's been my terminal of choice now for maybe going on six months or so.
I think Chris is going to be a noob to it, so you'll get a little bit of the expert-and-the-newbie convo here. We'd love to hear a little bit about yourself and Warp, why you decided to create it, and all that.
00:00:36 - Zach Lloyd
Sure. About me, I've been a developer now for 20-plus years. Prior to Warp, I was a developer at Google for a long time. I was actually the tech lead for the Google Docs suite, and most of my time I spent working on Google Sheets. I helped run the engineering team on that app and actually helped build a lot of it.
I've also done one startup before, which was a company called SelfMade. It was in the marketing technology space. When I was thinking about what to do after that, I was looking for a project that would solve a problem that I personally had, trying to improve software that I use every day.
I was interested in making the lives of developers better. I thought about tools that I regularly use, and one that I use often and am not that satisfied with was the terminal command line. I ended up thinking with Warp that there was significant opportunity to take a daily-use tool for most developers and try to meaningfully improve it.
[00:01:32] I thought it was an interesting point of leverage for improving developer productivity across the board. I had to do some convincing that there was an actual business to build around this. There's no terminal company in the world, really, that has existed before. I think that was the biggest leap of faith, and it's still something we need to prove, as far as room for improvement in the core product.
The more I thought about it, the more excited I got. The more I thought you could actually do something that was not just improving the UX, but also making the app collaborative, making it a better tool for reliability, a tool for making systems more secure, and something that could support an enterprise business.
So the company started a little over two years ago, right after COVID started, and we've been at it ever since.
00:02:13 - Anthony Campolo
It's funny that it's a tool every developer uses and tends to use all day. So it's both funny that there weren't terminal companies before and that it took convincing to be like, hey, this power tool for developers is something that's important.
I think it's partly just because there's that old adage that developers just hate paying for stuff. So I could see where a lot of developers would be like, oh, I don't need to pay for a terminal. I'm just going to hack my Oh My Zsh and Starship and get all this custom thing together.
I've gone down that route before. Having used Warp and then trying to configure my own terminal, I'm at the point now where I'm like, please take my money. I want someone to actually figure out how to do this for me. It's just so complicated.
There's so much configuration and so many things you can do with a terminal that having the DX there for you is really key.
[00:03:06] So why don't we talk about some of these features that make a developer using Warp so productive?
00:03:11 - Zach Lloyd
You touched on it a little bit in the sense that we've gotten rid of a lot of the configuration overhead. So when you come into Warp, a lot of things that take time and Googling and asking other people on your team how to set up are just there for you.
That's things like built-in completions, auto-suggestions, theming. The basics of the experience are more intuitive and take less work. We've also changed some of the basic UX of the terminal. The biggest things people do in the terminal are input commands and then deal with the output of those commands. In Warp, we've made a conscious effort to make both input and output work in a much better way.
So on the input side, you're using a real text editor. Essentially, you're not using what comes with your default terminal. The most noticeable thing with that out of the gate is the mouse works in it, which in a normal terminal, you try to click and put the cursor someplace and nothing happens.
[00:04:06] You try and double-click text, the selection shows up, you hit delete, it deletes a character at the end of the line. You try to enter a multi-line command. You want to figure out how to go back to the line before, you start hitting up, and it starts putting your history entries in the normal terminal.
Input, I think, is a very unintuitive thing that people, probably without realizing it, waste a ton of time on. We've made something there that works much more like editing code in something like VS Code.
On the output side, probably the biggest visual difference in Warp is that we have this concept called blocks. When you run a command, we group the command with its output. It's almost like a notebook. You can navigate around your terminal on a command-by-command basis.
You can easily copy and paste a command without trying to drag the mouse and select exactly the right characters, which is a big pain if you're working with long output.
[00:04:53] Anything you do in Warp, you can get a permalink to and share as a block. Again, it's much better than screen sharing for a long command. Input and output are very, very different.
And then we've added some things that are just novel. We have a really cool integration with Codex from OpenAI where we'll do natural-language search. We have a concept called workflows where you can templatize command snippets, and we have an open-source repo around searching for those templatized commands in Warp. So we're really just trying to push the basic UX of it forward right now.
00:05:22 - Anthony Campolo
Yeah. You mentioned, real quickly there, OpenAI, for people who don't know. That's the company behind the technology that powers Copilot. So the idea of having AI embedded in your terminal, I think, is something that we still haven't really gotten to the point where we are with Copilot, but that in itself is such a huge thing.
The thing you said about inputs is what really stuck out to me. Just being able to navigate around, like you say, in an intuitive way made such a huge difference. And then if I ever ended up on a computer now without Warp, now that I'm used to it, I can't deal with it. I'm just like, why is this terminal so bad?
To me, that is the real test of a good product: once you take it away, it adds all this pain back in. It's such a testament to what you built. I'd be curious to get Chris's take here, though.
[00:06:10] And I've never really asked you: Chris, how is your terminal set up?
00:06:14 - Christopher Burns
My terminal, I would say, is jazzy enough. Most of the time I'm a zsh user. I use Fig and Starship. I think that's the thing, whatever that thing is, I don't know.
I'm really more just a [unclear] user. I'm not going to get the most customized terminal experience ever because, other than that, I'll probably wipe my computer in a year or move to a different computer and have to set it up again. And I know what everyone's going to say: just host the config file on GitHub or something, but that's not my jam. I don't have time for that. I've got stuff to do.
I think this is a really, really interesting area. We've seen reinventions of the terminal before. The biggest thing that comes to mind is HyperTerm, Hyper Terminal. But that is in Electron. Warp is different, isn't it?
00:07:01 - Zach Lloyd
Yeah. So Warp is a native Rust app on Mac. We built it. It's Rust the whole way through. So it's completely full stack. Even in our code base, we have our own UI framework that we've developed. The plan is to open-source that once it's a little bit more mature. Even the graphics code, we have shader code.
The reason we did this stack and not Electron was performance. We actually prototyped Warp to start as an Electron app. It was fast to build something, but slow to use. With the Rust app, the performance is much better.
One of my big takeaways from my time working on Google Docs and on Google Sheets in particular was that we tried forever to get the performance of Google Sheets to be on par with Excel, and we optimized the crap out of it. But at a certain point, we felt like we were fighting the platform. You don't have the level of control of the memory layout of a spreadsheet cell. You can't really fully control that in JavaScript, whereas in Rust we have complete control, and the performance, at least by default, is as fast as you can get.
So we very heavily biased toward picking the fastest possible stack, even if it's a little more coding work up front. We've had a really positive experience developing in the language.
00:08:15 - Christopher Burns
That's really interesting because Rust is this language that, the more things go on, the more you see it popping up as the keyword: next-generation tool built in Rust, successor built in Rust. It's almost like I think I saw a comment on Hacker News. It was like, well, how do you know it's Rust? Because they'll say it's built in Rust. Quite simply: new terminal built in Rust. And I think we saw that with Vercel and their Turbopack successor, which is literally Webpack in Rust.
00:08:43 - Zach Lloyd
I saw the news on that. That's funny. Yeah. I mean, there's a marketing angle to it. That wasn't why we picked it.
But Rust people are super into Rust. I'm sure you guys look at the GitHub developer survey, or maybe it's the Stack Overflow one. I forget who puts it out, but it's like the number-one language. I think it's by a significant margin that developers are interested in working in these days. Rust, which is kind of wild.
00:09:06 - Anthony Campolo
Yeah, they call it the most loved language, usually.
00:09:09 - Zach Lloyd
Most loved language.
00:09:10 - Anthony Campolo
I've been dipping my toes in Rust just a little bit. I was playing around with some Rust lambdas the other day and it's really nice. It's fast and has good error messages. I'm a fan so far.
Did you have Rust experts on the team already, or did you have people who wanted to get spun up with it? How do you hire for that kind of skill set?
00:09:30 - Zach Lloyd
We had one person who joined us very early who had been working in Rust, and he had some Rust code that he brought with him, and that was a super helpful way for the rest of us to get up to speed on it. There were only like four or five of us at this time.
Most people on the team have learned Rust. We've hired a few people who had a lot of deep preexisting knowledge, but we don't screen for Rust when we're hiring. We just try to hire the best possible generalist engineers.
There is a pretty significant learning curve for Rust, more so than JavaScript or TypeScript or Python or Go or anything like that. But if you're an engineer with solid fundamentals, I think you can pick it up and become pretty good at it in a month or two. And after that, it's a super nice language to work in.
We have very few crashes. You do end up fighting with the compiler, probably more than you do in other languages, but I actually think better to fight with the compiler early on and have something that has fewer crashes and performs well than to have a very permissive development environment where you have null pointer exceptions that come up later, or dangling references or memory leaks and that kind of stuff.
[00:10:34] So I think on the whole, the trade-off has been great for us.
00:10:36 - Christopher Burns
I think it's also a great choice of language because it's multi-platform by design. You're not limited to using it on Mac OS. You can use it on Linux. You can use it on Windows, you can use it on Mac.
Really? How does each operating system affect your custom terminal? Because obviously Windows writes commands completely differently from how Mac writes commands.
00:10:56 - Anthony Campolo
Well, I think Warp is not available on Windows, right?
00:10:59 - Zach Lloyd
At the moment we're Mac only, but the premise of the question was kind of right in the sense that one of the other big reasons we picked Rust was that it has very good multi-platform support. About 90% of our code base is stuff that we will compile for these other platforms.
So we'll compile it for Linux, which is probably what we'll do next. We'll compile it for the web. Actually, we're very interested in doing a WebAssembly/WebGL-based version of Warp. And then we'll compile it for Windows. Windows, I'll just be honest, I don't really know. I'm not much of a Windows user. We may end up just supporting the Linux subsystem on Windows, but we may actually build something that is used as the main terminal on Windows. I'm just not a Windows expert. My experience is all Mac and Linux, but it's our second-most-requested GitHub issue. Number one is Linux.
00:11:48 - Anthony Campolo
Yeah. This issue comes up with open source as well. It's like you have an open source team and the whole team is Mac users. And then there's this whole subset of Windows users who are like, when can I use this thing? And they're just like, ah.
00:12:01 - Zach Lloyd
Sorry, we 100% want to support it. Our goal is to have a great product, at least on one platform first. Then when we feel like the product, which is still beta right now and still has numerous rough edges, we have 750 open issues in our GitHub repo. There's a lot of stuff to improve. We will definitely take it to more platforms. That's a big part of our plan.
00:12:22 - Anthony Campolo
Well, this is an example of where being an actual company and not an open-source project is where you can say, like, okay, we have a financial incentive to support Windows users because it's obviously a huge chunk of potential users.
So I think that's good because this is where open-source projects get caught up, as they're like, well, we can't support Windows because we're not being funded and we're just kind of doing what we want to do because we're devs building a thing for ourselves. And that's nice for the open-source team, but it really sucks for the Windows user.
So actually having these things be products with companies, it can be a good thing and the incentives can align there.
I'd be curious. Obviously you're still a beta tool and there's not really a huge monetization angle yet. But what are your thoughts in terms of how this is going to become a sustainable business?
00:13:09 - Zach Lloyd
You said it right. So we're a company. We're trying to build a business. I think that's an advantage in this space. There have not been businesses before.
I think having raised capital actually allows us to hire a team of people who are fully dedicated to this problem space, which I think is a big enabler for us building something really cool. And like you said, for being able to take it across platforms, the business that we're trying to build, and aren't super far along on yet, is one where companies are buying Warp for their teams and organizations.
We're not, at least not at the moment, planning on building something where we directly charge individuals. Maybe there's some future angle on that, but I actually think our best business plan and go to market is to have a free individual product that developers love, that they share with their friends, that they share with their teammates, that they bring into their companies.
Then, more similar to something like Figma or Notion, the business angle and the paid product will be features around collaboration, features around how do you make it easier to onboard an engineer into the terminal, for instance, or how do you make the terminal a more effective tool for firefighting?
[00:14:20] Or how do you make the terminal a more secure environment, or how do you make the terminal integrate really well with the company's internal tooling? And so all of those things, I think, if we can demonstrate that there's ROI and that Warp is making developers more productive, we'll charge businesses for it. That's the plan.
00:14:38 - Anthony Campolo
Yeah, that makes a lot of sense. I can imagine even just the security angle. You know, just picking up one of those threads would be huge if you could have a tool where you can manage environment variables for your company.
Because I know, like when I got onboarded at my company, it was like, all right, here's this 30-line environment variable file. I'm going to copy and paste into Slack and then delete from Slack so that no one happens to see it sitting on your computer. Save this in your 1Password. And it's just like, this is the process, really?
00:15:05 - Zach Lloyd
No, it's crazy how much stuff is like that. People copy-pasting API keys into the terminal. The last time I did this from GCP or AWS, there was some web page that was like, copy this now because you'll never see it again. And then the API key goes off into the ether and you just hope that it's stored someplace secure.
It probably ends up in some local environment file on someone's laptop, which is crazy. I think you could build an entire company just around this, like Doppler. There are companies that are just trying to solve this problem.
What's cool about Warp is, similar to something like Chrome, we're the actual tool. And so I think we have a really interesting entry point for improving these types of things, rather than building something that sits alongside the tool.
It's a big investment to get it going, and it's a big investment to get the actual terminal itself to be something that's awesome. But all of these tangential dev problems and security problems and reliability problems flow through the terminal. So we think we have a pretty cool point of leverage for improving all those things.
00:16:06 - Christopher Burns
I think this is a really interesting space. As you mentioned, Doppler, I think that's really interesting. But then I see things like Fig are starting to gain features with Doppler. They're two completely different systems.
And then there's also Raycast that's more like a command bar than a terminal, but it kind of works like a terminal. I think the biggest thing here, and what I'm sure you're working on, is that the way we've been developing using the terminal hasn't changed in 10 to 20 years. It's always just been that terminal.
And the way JavaScript tools have moved, the modern tools, we orchestrate a lot more from the terminal now in terms of starting our projects, opening web pages, formatting code. All of it is orchestrated by commands that are run through terminals.
My biggest question is: we have tools that abstract the command line. The perfect example is Git. How many times does the first-time user of Git just go for a GUI instead of the CLI? Well, pretty much 90% of the time, because the GUI is much easier to just get your Git up onto GitHub.
But how do we teach them how to do Git properly? How do we say, okay, these are the first commands to run, these are the second commands, third commands, and if they do it wrong, how do you correct it? How do you guide them along that path?
Because even I find the terminal to be such a black box. Everyone can write a help message differently. Some people put -h, some people --help, and it's sometimes so crazy.
But the biggest thing that I think I'm really getting down to is: how do you view the terminal today, and do you think that Warp could potentially provide future standardization for some of the formatting around the things we're doing?
00:17:50 - Zach Lloyd
It's a great point. So to the terminal versus GUI, first part of the question, the interesting thing to me is there's certain built-in advantages. If you can do things in the terminal, the terminal as opposed to a GUI is sort of infinitely flexible in terms of you can pass in any combination of arguments. If you wanted to build a GUI to do everything you can do in Git, it would be the world's most complex, completely unusable GUI.
The terminal, because it works with these text-based apps, has advantages. You can script them all, which is super cool. You can compose them, so you can take the output of one and put it into the input of another.
I do think at the end of the day, it's to every developer's advantage if they can actually get comfortable in the terminal because it's a power tool, and it can really level up your productivity.
To the second part of your question, which is, well, how do you get people to be more comfortable in the terminal, and how do you get them to be effective, and how do you standardize it? That's a big part of the mission of our company: to try to solve some of these problems around onboarding into the terminal, around making the terminal an easier tool to learn, around documentation.
And yeah, I do think it would be awesome if we could standardize some of these things. For instance, man pages are a good example. Every tool outputs its help in a crazy different way. It would be super nice if there was a standard format for outputting help. The terminal could then process it and turn it into something that's structured and searchable for a user.
Those types of ideas are super valuable. We've already built some features that I think do help with this. For instance, in Warp we have a feature where if you paste a command into Warp, you can hover over the flags with your mouse or use Command-I and we'll show you what they mean. So if you paste something from the internet and want to understand what you're about to do, we'll help you do it.
There's just so much room for improvement. And it is kind of like a black box that I think really needs to be improved.
00:19:39 - Christopher Burns
How I see a potential future is as soon as you cd into a directory, I feel like the first thing to do is let's see what's in the directory.
Or then if you know that it's a JavaScript program, then you've got to open package.json, see the commands you need to run. My revolutionary feature, if you build this, I'm going to call it, is that as soon as you cd into a project structure, it says, here's the commands that you're probably going to use. It's probably going to be these top four commands we've worked out. So if it's a Yarn project or a compiled project, you're probably going to run these four commands. Do that.
I think that's super cool. But also there's so much area of innovation when it comes to things like, it sounds simple, but Next.js spitting out tons of errors and the error page just goes on for days and you don't see the first error because the bottom error has already pushed it off the top.
How do you actually make that easier? Is there a way to get that to where you could crunch the brackets? And I guess this whole thing about rewriting that complete terminal experience will provide this functionality going forward.
00:20:40 - Zach Lloyd
That was an awesome example. So that's literally something that we've been talking about building, which is the experience of working with long log output. I think there's so many things you could do to make that better. You could elide content, you could make it filterable. If there's JSON in it, you could make that JSON have a sort of navigable structure.
And this is all stuff that we can do in Warp. Whereas in a traditional terminal experience, I think it would be very, very hard to do because the normal terminal is just a character rendering device. You send characters in, something on the other side is listening, whether it's the shell or some other running program. That program sends characters out. The terminal has no idea what those characters mean. It doesn't know if it's part of a command that's just been run. It doesn't know if you're in Vim. It just has no idea.
In Warp, we have at least some idea of where a command starts and ends. Even just that minimal structure would allow us to do something like you're talking about, Chris, where we could make the editing or viewing of a long log output so much more pleasant for people.
00:21:42 - Christopher Burns
Exactly. I think it gets ten times worse when you're SSHing into a remote machine where you definitely do not have any other interface.
00:21:51 - Zach Lloyd
So that situation is horrible to me. You don't have another option because those machines don't have a GUI. And then typically when you SSH in, all of a sudden all of your terminal settings go away and it's like, uh-oh, my aliases, my completions, all of that stuff is gone.
So our SSH experience in Warp, you keep that stuff. You keep your completions. At least you keep your themes. The way the editor works doesn't change. It's not a perfectly seamless experience just yet. It's a thing that people want us to keep improving. But 100%, that's another experience. Every time, as a developer, I'm in some remote box, I'm like, uh-oh. In a typical terminal it's rough. It's significantly better in Warp.
00:22:29 - Christopher Burns
Does Warp support things like bash, zsh, fish? And what, in your eyes, really makes each one different, and why are they important instead of there just being one singular option? Apple basically said bash is gone, zsh is in, and everyone just went, okay. Does it really make a difference? And really how important are the alternative ways of writing commands? Because truly, I switched from bash to zsh and did I really even notice a difference?
00:23:04 - Zach Lloyd
So with Warp we support bash, zsh, and fish. You can run any of those shells. Most of our users are on zsh just because that's now the default shell on Mac. From Warp's perspective, it really is up to the user. The reason we supported those shells is because they're the most popular ones, and we wanted to make it super easy for a developer to try Warp without losing any of their existing config.
So if you come in using zsh or any of those shells, we use your existing config. So all your environment variables, your aliases, your path, all of that stuff just works out of the box.
At some point, I think we would actually consider writing a shell, just because the philosophy of Warp has been the more full stack we can be, the more vertically integrated we can be, the better developer experience that we can give around the tool. But that's not something that's on the short-term roadmap. Our priority right now is to make it easy for developers to transition on the tool, try it out, see if it's helping them get more done, and to do that, the easiest thing was to support people's existing shells.
00:24:07 - Christopher Burns
Yeah, I believe Apple moved from bash to zsh because of open source reasons.
00:24:13 - Zach Lloyd
That's right. There was, I believe, the later versions of bash, and I don't want to get this wrong, were under a GPL license. It was a license that Apple did not want to ship with, so they switched the default to being zsh.
And if you do use bash on Mac, the default one, you end up with a super old version of bash. So a lot of people will use Homebrew to install a more recent bash if they want to use it.
00:24:38 - Anthony Campolo
Chris, since we don't say Z over here across the pond, they call it Z.
00:24:44 - Christopher Burns
Zsh, I wouldn't know that. See, I'm terrible with pronunciations, or I'm just British. Are you sure it's pronounced zsh? Or is this another dino situation?
00:24:52 - Anthony Campolo
Well, this is the problem. When you invent a new word that's made up of nothing but consonants, no one knows how to pronounce it.
00:24:58 - Zach Lloyd
I say zsh, you say zsh.
00:25:01 - Anthony Campolo
I've heard other people say zsh. Maybe zsh is another one, because it's like zsh has three syllables. Zsh. One syllable is the most elegant to me.
00:25:10 - Zach Lloyd
Okay, I like it. It's closest.
00:25:13 - Anthony Campolo
It's like fish. There's the Fish shell. So if you add Z, it's a zsh. Is that so? Anyway, we're getting a little off on tangents here.
I would be curious. You said you have hundreds of open issues. It's still in beta. You have a lot of people wanting to do a lot of things with this tool. How do you prioritize? How do you decide what to work on?
00:25:32 - Zach Lloyd
That's a tough one. We want to fix the things that have the highest user impact first. We have to balance that against how hard those things are to fix, to be honest, and how many resources we have.
So this is the generic engineering manager answer: trying to fix things that have the highest impact that we can do with the least effort. And then we're trying also not just to fix things that users are asking for, but to push the state of the art further and build things that we think are going to make the overall developer experience better, and things that are important for positioning the company for success.
We're right now building out our initial set of more collaborative features and starting to test those. It's some combination of pushing the company forward and addressing the biggest pain points that users have, where we think it's going to solve the most pain for people with the least effort.
00:26:19 - Christopher Burns
What does the next six months look like in terms of roadmap?
00:26:22 - Zach Lloyd
It's trying to fix the top user issues. And so those would be, for example, things like reordering tabs or making the input position flexible, those types of issues. It's trying to make some things in the user experience better.
We're doing a lot of work around assistive command input, a feature that we're working on, possibly in collaboration with this open-source project that's called the, I don't know if I can say that, it's a very popular open-source repo that does command corrections. We're trying to build that functionality natively into Warp, where if you mistype a command, we suggest the one that you probably meant to enter.
We're working on making our completions extensible. Right now all of our completions are bundled into Warp, and so we ship with those. But we want to make it so people can add their own completions.
We are prototyping some concepts around knowledge sharing in the terminal. So, for instance, if you want to have a set of saved commands that your team uses, or if you want to have a sort of shared terminal notebook or document that, again, someone comes onto your team and they're like, how do we do x, y, z in the terminal, that could just show up and be available natively for people to use.
We're prototyping those concepts and seeing if there's value. So some combination of fixing existing things that users are asking us to fix and then trying to push the terminal forward.
00:27:45 - Christopher Burns
The, I'm not going to pronounce it, the whatever-you-want-to-say, f-u-c-k, is great if you're also dyslexic and you probably type things the wrong way too often.
00:27:55 - Anthony Campolo
Well, this is even an attack vector. They'll squat on incorrect npm names and then try and download malware. I've heard this is actually an attack vector.
00:28:04 - Zach Lloyd
Fascinating.
00:28:05 - Christopher Burns
And also it's an accessibility feature.
00:28:07 - Zach Lloyd
It's an accessibility feature. I mean, that's another area in Warp I think we can do much better than the normal terminal.
We've done some work on accessibility to try to make Warp work better with VoiceOver. We have some folks outside the team who are working with us on that to try to get there. Like, terminals should be accessible. The fact that we have more structure in the terminal, I think, will allow us to do a much better job of that.
So that's another thing that we care about and are trying to fix. Even just letting people easily understand what the output of the last command was, I think, is not so easy in a regular terminal because the terminal doesn't know what was a command and what wasn't. And so in Warp, we have this structural advantage that we're trying to use to make it more accessible.
And that's a big part of our mission. The terminal is inaccessible in a lot of different ways. It's inaccessible for people who have visual impairments. It's hard to learn. Nothing in it is discoverable. It's an intimidating tool for new developers who are just coming into development for the first time, and their first experience trying to do some development is trying to set up some Python environment or something. And it's like, ah, what is this tool doing? And so that is a big part of our mission: can you make the tool more accessible?
00:29:16 - Anthony Campolo
Yeah, I've recommended Warp to even very new developers. I think that, as you say, it gives you more insight into what's happening. It gives you a better idea of what commands are at your fingertips. And that's a huge win for newbie developers.
00:29:31 - Christopher Burns
We quickly spoke earlier about platforms you support. You said about web, but what about a VS Code integration? How hard would it be to replace the terminal in VS Code with, say, Warp?
00:29:42 - Zach Lloyd
So we would love to do this. This is also one of our most requested issues from a technical standpoint.
It's challenging. The order of operations would need to be: we need a working version of Warp in web tech, which is something that we're 100% wanting to build. That's a significant technical lift. And then we could get a version of Warp into VS Code as a VS Code extension.
But the ideal thing would be to work with the VS Code team, if they would ever do this. Their terminal concept right now is not pluggable. They have a whole terminal menu, for instance, and I don't think we could hook Warp into that without some work on their side to do that.
I know VS Code is open source, so maybe that's a potential thing that we could build as well.
The sort of workaround for this right now is we have some nice integrations where it's like, from Warp, click on a file and have it open in VS Code. From VS Code, there's a keyboard shortcut where you can open Warp in the right directory you're in.
And then we have this feature called quake mode. Have you heard of this? It basically lets you slide your terminal up in front of wherever you are and make it go away, kind of like in the video game Quake. If you really want, you can make it look like the VS Code terminal, but that takes some work. And ideally I think we would just be in VS Code as an extension.
00:31:00 - Christopher Burns
A lot of my time when it comes to the terminal now is using the terminal in VS Code, even though it just feels like they're just porting the terminal through from the operating system.
But obviously I bet it's way more complicated than that because you also have things like VS Code on the web now, and how does that run on the web? And also other online code editors like StackBlitz integrate into all of them. That's the plan.
00:31:23 - Zach Lloyd
Yeah, we would love to do that. The other thing is, there are a lot of terminal use cases that are semi-orthogonal to coding that we want to be great for. So for people who are doing DevOps, for instance, I think you really want the terminal as a more powerful thing than the thing at the bottom of your code editor. So we're trying to attack those cases as well.
00:31:43 - Anthony Campolo
I want to point our listeners also to the fact that you've done the rounds on podcasts. You've been on DevTools, Changelog, and Software Daily. I'm always a big fan of CEOs who go out there and communicate. I've listened to all these podcasts, really appreciated them. I thought they were great.
Is there anything else that you want to talk about to let our listeners know about the product or things that are coming up, or just anything you want to point people to?
00:32:07 - Zach Lloyd
We're hiring, the team is growing. So if this is a space you're interested in, if you're interested in helping developers be more productive, we're hiring for awesome engineers. Super cool team. It's remote-first, but we have offices in New York and SF.
We love product feedback, so anyone who's using it who wants to give us product feedback, we would love that. We have a pretty vibrant Discord.
And so, yeah, I appreciate everyone who's trying Warp. We're definitely working hard to improve it for folks.
00:32:33 - Anthony Campolo
And then let our listeners know where they could find it and any Twitter handles or things like that for yourself, for the company you want to share.
00:32:41 - Zach Lloyd
Yep. So you can get Warp just by going to warp.dev. You can also install Warp via Homebrew.
We are @warpdotdev on Twitter. If you want to actually follow my Twitter, I don't know why, but you're welcome to. It's @zachlloydtweets.
We're on YouTube. We're on TikTok. We have good instructional content. Yeah. Please check out all of our social channels.
00:33:06 - Christopher Burns
I guess my final question is, do you prefer terminal in light mode or dark mode?
00:33:10 - Zach Lloyd
I'm a dark mode person. The only time I use light mode is if I'm outside.
00:33:14 - Christopher Burns
Why not sync to the OS?
00:33:16 - Zach Lloyd
There you go. We have that. That's a thing. Yeah.
00:33:19 - Anthony Campolo
Well, thank you so much. I definitely recommend our listeners check out Warp. I think it's a great tool. It's one that I can put the AJC web dev stamp of approval on.
00:33:28 - Zach Lloyd
Cool. Thank you both for having me on the podcast. It's been awesome.
00:34:01 - Christopher Burns
Thank you.