Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Building a New Terminal App (with Zach Lloyd)
3.1k Plays4 months ago
The terminal might be the most used development tool in history. So it’s a little odd that it hasn’t changed that much in the decades since the terminal first came into being. Is the terminal a “completed” project? Or are there new ways to look at it that might make it even more useful?
This week’s guest—Zach Lloyd—is convinced the terminal is ripe for a new approach that’s more than just a new coat of paint. And in this episode we dive into what that approach is, what he’s trying to do with the Warp Terminal, and how it’s put together using a combination of Rust and GPU shaders.
Along the way we look at what LLMs could do to improve the terminal experience, where the boundary lies between terminal and shell, and where Go has solved some problems and created others over at Warp HQ.
–
Become a Supporter on Patreon: https://patreon.com/DeveloperVoices
Become a Supporter on YouTube: https://www.youtube.com/@developervoices/join
Warp Homepage: https://app.warp.dev/referral/VQGWW3
VT100 Information: https://vt100.net/
Game of Life in Rust: https://github.com/krisajenkins/game-of-life-rust
Zed (Text editor in Rust): https://zed.dev/
Flutter: https://flutter.dev/
The Painter’s Algorithm: https://en.wikipedia.org/wiki/Painter%27s_algorithm
Zach on LinkedIn: https://www.linkedin.com/in/zachlloyd/
Kris on Mastodon: http://mastodon.social/@krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Kris on Twitter: https://twitter.com/krisajenkins
–
0:00 Intro
2:22 Why Create A New Terminal?
7:28 Blurring the Lines Between Terminal and Shell
16:04 How Do You Build A Terminal Program?
24:55 Implementing a Terminal in Rust
30:32 Rust Frameworks for GPU Shaders
40:04 Will Any Of This Go Open Source?
42:49 Managing a Mixture of Rust and Go
47:52 What’s the DX of Warp?
51:43 Integrating LLMs into the Terminal
1:05:58 Outro
Recommended
Transcript
The Terminal: Timeless or Outdated?
00:00:00
Speaker
I've switched through a lot of programming languages in my career, trying to keep learning things, keep it interesting. I've cycled through a few different editors in my time, as my habits have changed over the years.
00:00:12
Speaker
And I think I've made a major change to the operating system I use maybe twice. But there's one tool that has remained pretty much constant and pretty much the same throughout my entire career, even though I've used it every single day. And I think that's true for the majority of programmers stretching all the way back to the 70s.
00:00:34
Speaker
The tool we've used that hasn't changed much in five decades is the terminal. The way we use a terminal, the things we say to it and the way we expect it to respond to us would be familiar to a programmer from 50 years ago.
00:00:49
Speaker
And you have to ask is that because we absolutely nailed the design first time congratulations no notes or is it because it's so familiar so comfortably in the background we don't even really think of it as a potential target for innovation.
Introducing Warp: The Future of Terminals
00:01:06
Speaker
Well, I'm joined this week by Zach Lloyd. He's an ex-lead dev on Google Sheets. So having spent a chunk of his career modernizing that other 70s software icon, the spreadsheet, what else could he do but go and look at the terminal and ask, what else can we do with this software?
00:01:25
Speaker
His answer is warp, and in the course of unpacking what the warp terminal is, we cover how do you implement a terminal program from from first principles, how and why warp is written in Rust, and Rust that generates GPU shaders, and where large language models can tastefully add to the terminal experience.
00:01:49
Speaker
This episode might make you want to switch terminals, but I hope at an absolute minimum it gets you to look at that foundational tool with a new appreciation. I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is Zach Lloyd.
00:02:16
Speaker
Joining me this week is Zach Lloyd. Zach, how are you? I'm doing great. Thanks for having me, Chris. It's a pleasure. You are doing something that I'm, we're going to have to dive into this because I could be persuaded that this was madness as a business idea.
Reinventing Terminal Usability with Warp
00:02:34
Speaker
It's certainly a very interesting technical challenge, but you're building a new terminal, right? That's right. Yep. So we are building,
00:02:43
Speaker
Warp is the name of the product, the name of the company. And the idea is to reimagine the command line terminal, make it more useful and productive for developers, kind of by going back to first principles and building the thing that we think will help developers get the most out of the tool.
00:03:02
Speaker
This is... yeah so there's a lot of technical stuff we need to get into. I know it's fascinating under the hood. But it's one of those places in tech where you could say it ain't broke, don't fix it. But you could also say it really hasn't changed since the 70s. Surely there are some new ideas, right?
00:03:20
Speaker
Yeah, I mean, we're we're more ah in the latter camp. where' um you know it's It is an extremely powerful tool for developers who can master it. um It's a tool where If you get it configured and you learn all of like the sort of arcane ways of using it, you can really increase your productivity, whether it's doing coding or DevOps work or production work or whatever. The problem is there's a very steep learning curve for the terminal. I believe that. It is not a very accessible tool. um And you know our our view is that it's
00:04:03
Speaker
it It really is a spot where there's a bunch of innovation that you can do to make it, um you know, more accessible to new developers, but also more powerful to developers who, you know, don't necessarily want to spend all their time configuring and setting up the tool that they use. They just want a tool that helps them get their job done. um So that's kind of our um biggest product philosophy. Okay, so would you say you're focused largely on the doesn't currently use a terminal market? No, I like our Terminal is interesting because every developer uses a terminal. like soon or If you walk by any developer's desk, they're going to have they're going have a code editor are open, they're going to have a terminal or two open. For some developers, that actually, they're doing their code editing within the terminal and something like Vammer Emacs. And we're we're trying to make the the terminal
00:04:52
Speaker
kind of a better product for everyone. my um you know My sort of dream is that we lower the barrier of entry for people who maybe are turned away from development because the terminal is such a hard tool to use. But you know also, I want the terminal to be more powerful for developers who have more of my background, where I've been doing development for 20 plus years now. And I've always been one of those developers who ah you have to use a terminal. But when it comes time to do something really hard, I would go tap one of my teammates on the shoulder and be like, can you show me how to write a set script that analyzes these logs to find the particular you know person who is spamming us? And there's usually one person on my team who's been really awesome at it. And yeah you know so I want to expose that kind of power
00:05:41
Speaker
um that is inherent in being really good at the command line to even really experience developers that can get better at using it. Yeah, because there's there's always, I mean, I would consider myself, I hesitate to use the word expert, but certainly long suffering terminal user. There's always like an ork flag or a said flag that sends me to stack overflow, right? Yes, yes that is that is the the most common um pattern of using the terminal that that I've had in my career.
00:06:16
Speaker
You either remember it or you're on Stack Overflow or you're bugging a teammate. And so we we think that you know really like making terminal commands more accessible, making the cognitive burden on someone, trying to use the tool a lot lower, um making it possible to do complex workflows much more quickly, all that stuff is possible if you if you take a look at some of what makes the terminal hard to use right now and just try to reimagine the product.
00:06:44
Speaker
to make
Enhancing Terminal Usability
00:06:45
Speaker
it more usable. And so for us, there's really, there's three aspects to that. So one is, um, we've tried to, to improve some of the basic usability of the terminal. And so what I mean by that is like, you know, first experience a lot of developers will have in the terminal, they'll try and edit a command and they'll try and edit it like they could edit it in their IDE. And that actually just doesn't work in the terminal. So you can't like click and put the cursor someplace. You can't select texts and delete it. Um, there's not really any like,
00:07:14
Speaker
in telesense or syntax highlighting, you you can kind of configure your terminal for your advanced user to do some of this. But like the basic experience is really lacking. um And so we try to improve that. And likewise, we try to make it easier to deal with like the output of the terminal. So in a normal terminal,
00:07:33
Speaker
um you know The output is one just like long stream of text, and we've tried to make it so the terminal itself knows what output is associated with which input command, and that makes it really easy to do things like copy-paste or share terminal outputs with your teammates. and so Like I said, the first thing we do is just be like, hey, how can we make the basic um app more usable for developers?
00:07:57
Speaker
this okay So you're pushing some of the things that I would expect to get from the Shell program into the basic terminal support. Yeah, totally. And so there you know there's pros and cons to this approach. um you know the The biggest pro in my mind is that I think actually if you asked a lot of developers, maybe most developers, when they're using the terminal, they're just they're not really thinking hard about, is this a terminal feature or a shell feature? They're using a command line. And the like architecture to them is sort of a implementation detail.
00:08:36
Speaker
for lack of a better word, like the fact that there is a terminal in a shell and we could talk about like, what is the the difference between seeing those two things. But for them, they're using a tool and the goal is like, I want to type commands and have things happen and get to some end result that I care about.
00:08:51
Speaker
and um you know So we've we've tried to orient our product really around like, don't make the user care so much. If this is a terminal level thing or a shell level thing, make it so that that they can just accomplish the task that they're trying to do. And so that that's like the pro. The con is that um you know There is this historical division in architecture between terminal and shell, and sometimes when we've tried to blur that division, you end up with ah things that really experienced or knowledgeable terminal users are like, wait a second, like I have this configured in the shell, and now it's happening in the terminal. It can create some compatibility issues. So that's like the challenge for us, is like we want to innovate on the user experience, but we don't want to break things for people who are you know good at using the terminal already.
00:09:42
Speaker
Yeah, yeah, it's like by adding in a feature that, I guess you only really understand the difference between a terminal and a shell when you first switch shells to try and get some of those features. And then you don't yeah I don't want you to break the new shell that I've deliberately switched to. Right, right. um Yeah, so so innovating on the UI has been one big big piece of warp.
Collaboration in Terminal Workflows
00:10:07
Speaker
um you know It's your earlier question of like how do we build a business around this. So we have a second part of Warp, which is around collaboration, which is a really new concept in the terminal. And you know the idea there is that it kind of harkens back to what I said earlier, where it's like when I when i would have an issue in the terminal, when I was working and't know in like the Google office, I would go tap my friend Josh on the shoulder. I'd be like, how do you do this?
00:10:33
Speaker
A lot of people are not working in offices the same way. They're working remotely. They're traveling. And so having a way to sort of store that knowledge of the the more advanced terminal users and make it accessible to everyone on your team.
00:10:47
Speaker
but so Josh is a service. so yeah yeah josh you know Rather than tapping Josh on the shoulder, I can i can actually send Josh a link to my terminal session and he can join it and help me debug something. Oh, okay, so you're doing that kind of collaboration. We have that kind of collaboration. And then we have the kind of collaboration that's more asynchronous, where it's like, Josh can just like sort of add these, what we call workflows. They're really like command snippets or recipes where it's like, Hey, here's how I do, you know, here's how my favorite commands for analyzing logs. And you can put that in a sort of team space and everyone on the team can get access to it. So that's like a,
00:11:27
Speaker
a sort of totally new concept in the terminal that we've added. And that's one of the the things that we're trying to build the business around is like enabling teams to leverage communal knowledge, or maybe not even just knowledge, but like communal execution environment, sharing environment variables, things that help a team um ah make make it easier to do like the team's workflows from the command line.
00:11:50
Speaker
yeah and then What you're making me think of is situations in the past where the way that folk knowledge is shared is you look through the dot .history file of what yeah people have typed in this show. it's kind of It's like making a product around that.
00:12:05
Speaker
ah yeah like so that you know you waste less time looking for this stuff and you know you can systematize it and use it across the team. and you know Obviously, there have been ways there are other ways of doing this. like You could do it by like making a readme or making a shared script. What we've tried to do is just build it directly into the tool and in a way that's like similar to Figma or Google Docs, where you know rather than going to an external thing to sort of sink sync all of your design files, you could just kind of do it right from the tool itself. um And then the third thing that that we've done, which honestly when we started wasn't totally our aim, but the world of technology has changed around us, is Warp is a has like a sort of first-class um AI integration.
AI Integration in Terminals
00:12:56
Speaker
And I'm sure, I know there's like a lot of
00:12:58
Speaker
AI fatigue, but I will say and in our in our favor, the terminal is actually an amazing ah place to surface this technology because the um it's just a notoriously hard interface to to remember how to use it. And so in Warp, what you can do We have this feature that's called Agent Mode. You can just talk to the terminal in natural language. And when you talk to a natural language, what's really cool, it's not just like a chat experience. It's an experience where you can ask it to do things and it will actually do them for you. So I can be like,
00:13:35
Speaker
you know create me a git commit um with this message and actually go ahead and read the files and summarize the changes and put that in the message. And because you're in the terminal, what it will do is it will sort of cat all the files, take a look at them. It'll look at the diff and it'll be like, okay, this is what happened in this. And so that's just one example, but um it It really sort of lowers the barrier to entry rate and it can speed you up tremendously if you're doing any kind of complicated workflow. So that's the other sort of paid part of warp that we're building the business around is the AI. Okay. Yeah, that makes sense. Then I was going to ask you this later on in the podcast, but it instantly raises it. Does this have like privacy concerns? I didn't really want my terminal commands going to someone else's server.
00:14:24
Speaker
A hundred percent. so um Terminal is a very sensitive environment. like you know people there's PII printed in, enter there's passwords printed in it. And so our our approach to this is that it's all opt-in. So we don't, we don't if you as a as a like hard rule, we don't suck up any data. We don't look at your commands. It's up to you as a user to be like, I want to ask AI about X and I want to provide AI
00:14:58
Speaker
certain contexts. We make it easy, so it's it's much easier um to do these workflows in Warp State than it is to do them in like chat GPT or even using Copilot, but we give the control to to the developer.
00:15:16
Speaker
And then for places where there's like real privacy consciousness, like we have some enterprise um customers for Warp. What they will often do is they'll be like, we don't want this stuff going across the public internet. We don't want it going to open AI. It's public. We have an internal sort of LLM for the AI case. And so yeah we can configure Warp to work with um with other LLMs. And you can keep your data private that way. So that's another answer. But yeah, it's a totally it's ah it's a totally privacy-conscious thing. And we care quite a bit about that. And um we give all the control to the developer.
00:15:56
Speaker
Okay.
Technical Insights into Terminal Construction
00:15:57
Speaker
Okay. So if we're talking about integrating warp with like a local server or something, ye it is the perfect time to start from scratch and tell me how you build the terminal. okay i'm I'm digging into my memory. I can remember the phrase VT100 and there I kind of cap out.
00:16:15
Speaker
Yeah, so I'll start. you You should guide me in terms of what level of abstraction you want here. But just like the basics are, just so everyone who's listening remembers, like the terminal is um is is the actual like a GUI app that you are running. So when you launch a terminal on your Mac or a Linux machine, you're launching an actual app that has a window and ah it it like renders a screen and ah it takes keyboard commands. And what this app is doing is it's actually emulating a piece of physical hardware, um which you mentioned, Chris, like kind of the most famous one is the VT 100. And what this piece of hardware did, and it's not really used anymore, is it like basically took characters that you typed in from keyboard
00:17:05
Speaker
um It sent them across like ah ah ah basically a communication channel where on the other end there's something running called a shell. The shell interprets those characters and then sends characters back. In addition to sending characters back, it also sends back these sort of control sequences, which are things that um tell the terminal how to do its rendering. And then the the other big piece of the terminal is the screen, and ah the characters are rendered on the screen according to the instructions that come back from the shell. That's like the basic architecture. Does that make sense? Yeah, so that's the original thin client, right?
00:17:46
Speaker
Yeah, and so the terminal is really dumb. And you'll often hear people say dumb terminal. And so the terminal, what and what that means is like the terminal doesn't have any knowledge of like what's happening to those characters, what program is being run on the other side, semantically, like what they mean. That's all the job of the shell. So the shell is basically interpreting those characters, launching programs. Those programs are doing whatever they do. They're processing text. but Those programs are returning text, and ah the care and the the terminal is just responsible for rendering them on the screen. So the terminal just knows characters in, characters out is the simplest way to think about it.
00:18:26
Speaker
So if I wanted to build my own terminal as a first approximation, all I need is read line, print line, and this big manual full of control codes that say, now switch to red, now go to cursor position 15. Is that fair? Yeah, I mean, so something like that. So like to dive in like a little bit more, so when you when you um run the terminal, what it's doing is it's It's making this um system call, which creates something called a pseudo terminal, PTY. And so like on like Unix or Linux or Mac, um the kernel has now
00:19:08
Speaker
you know The expectation isn't that you're going to be using a physical terminal. The expectation is that you're going to be using one of these software terminals. But the actual architecture is really similar. And so when you make this system call to create a PTY, you can think of it as like you're creating like this basically you know set of file descriptors where on one side of them is the ah terminal program, you know the GUI program that's running the terminal emulator. And on the other side is the shell.
00:19:37
Speaker
and they kind of like like There's more to it, but but basically what you do is the terminal creates this PTY. It sets up a shell program that it wants to run ah on the other side of the PTY. It it sort of forks and execs that. and Then at the end of it, you have everything going through this one pipe of files where characters are going in and characters are going out. and so If you're writing a terminal, what you need to do is you need um over in like the gooey land you need some way of listening for the user typing in characters you need a way of like then sending those characters through the pty to a shell and then you need a listener for when the shell is returning characters back and that listener needs to not just like know how to interpret characters it it needs to have like a
00:20:27
Speaker
a sort of parsing logic that matches the VT100 sort of spec. And so what that means is like when the shell is writing characters back, it's writing some things back as just plain characters that are printed to the screen. But sometimes it's writing things back that are like encoded sequences which have a richer meaning. And like a good example of this is like, hey, say that you're running a program and that program wants to return colored text.
00:20:56
Speaker
It actually writes a few characters before and a few characters after the text that it wants to color. And those are like meta characters. They're not printable characters. So then your terminal needs to have a parser that is, you could think of it like a state machine that knows, hey, OK, I saw these control characters. I saw these other characters. I saw the end of the control characters. This is blue text. I know how to print blue text.
00:21:21
Speaker
and so I don't know if I lost you there or whatever, but it's like, i know and with yeah and with you you need a parser on the terminal side. And then on top of that parser, you need um an abstraction for representing the character grid on the screen. And you need a way of like drawing characters to the screen. That's like the final piece of it. Yeah. None of that sounds too hard on the surface. Just quickly check mine. Is that request response? Is it like, I'm going to send something and then wait for the thing back? Or is it asynchronous?
00:21:51
Speaker
It's more like it's, um, it's following like the, the Unix like file paradigm. So you're like listening for like your, you have like file descriptors that you are reading characters off of. So kind of like, uh, Yeah, just like you're reading from a file on both ends and so when characters come in, um you read them and there's, there's a lot more technical detail to this like there's different ways of buffering this or whatever, like, actually on the side of the shell there's um
00:22:23
Speaker
there is a a thing that's kind of built into the concept of the terminal called a line discipline, which actually like accounts for buffering up text before it gets written back. um But yeah, you should think of it as like reading from a file is the best analogy, not reading from one file writing to another. Yeah. Yeah. Okay. Okay. I can see that. yeah So this, this seems to me, if I know how to write a parser and I know about you know, multi-channel communication, it seems like the next hub part is just having that big list of control codes and supporting them. Yeah. So that's like, that's kind of a pain. Um, I mean, there's a, there's a bunch of open source stuff out there that helps a ton with this. You don't need to rewrite, like if you're actually taking this on as a project, um, you would want to go find,
00:23:18
Speaker
an open source parser to do this. um It's interesting that there isn't really a published spec for this. oh like ah like if you go to The best thing that I found is actually on this website called vt100.net, which gives you the state diagram.
00:23:39
Speaker
um and it's like ah it's like ah It's like a very complicated like like you know, finite automaton or something. It's like ah going back to CS days is where it's like you, it gives you all the transitions based on the control codes, but there's no like published official spec for it. So everyone just ends up implementing the um the thing that the VT100 supported. I honestly thought you were going to tell me it was like AT&T nailed this or Xerox PARC nailed this in the ATO's and you just have to.
00:24:10
Speaker
No, but it's it's it's messier than that. like Terminals are are, I think, messy. and like There's various evolutions and extensions that let um that make the the type of metadata that you can pass from the shell to the terminal be more complicated.
00:24:29
Speaker
um so But yeah, what what you would basically do is you would write this parser in the state machine, and at the end of it, you would you know the other thing you would have to have on top of that is some sort of graphics layer for printing characters to a screen. But no, to get like a ah basic terminal working is I don't want to oversimplify it because it's, it's, you know, doubles in the details, but yeah, that's, that's, that's the gist of it. Okay. I can see that. So I'm moving on to implementing it. Yes. That seems on the surface. Anything that can, has a decent graphics package would be a decent choice for this. And I know you've chosen Rust, which I can see pros and cons to that. Tell me about that choice. Yeah. So.
00:25:16
Speaker
Rust is great, so the the choice was driven by we wanted um to build on a stack or a language that was very fast. Rust is pretty high performance, so just like the way that you memory manage a memory in Rust inherently makes it very fast. We wanted something that was ah had a great community. So there's, there is a lot of community support for us. Um, we wanted a language that was safe and like, uh, from like a, like a memory standpoint. So it's, it's safe. We want a language that basically I would describe it as like speed and performance characteristics of CRC plus plus, but with nicer ergonomics and better safety and a little bit of an easier, easier language to work with. Although
00:26:08
Speaker
I don't know, have you have you built anything in Rust? It's also got a steep learning curve. Yeah, yeah i've i've I've never used it for work, but I've played around with it a lot for different projects. In fact, including one project that involves control codes for the terminal, which was the game of life in text. Oh, cool. and It's the fan language. Yeah, the kinds of Rust um are basically around the learning curve. So the way that memory and assignment and ownership and lifetimes and all of these concepts work in Rust is really quite different than any language that I had used before. So it's there's you know you it takes a little bit of time to get used to the memory model. That's the biggest con. The other con is like, um
00:27:00
Speaker
The options, at least at the time we started building Wharf, for building like graphical apps in Rust we're not to um yeah were not that awesome. And so we actually didn't find a cross-platform graphical like like GUI framework that we wanted to use, and so we ended up building our own, which I can also talk about. It was very interesting. Yeah, yeah, I want to stand on that structure.
00:27:26
Speaker
And then finally, one other advantage of Rust, I should say, is that Rust does have very good cross-platform support. And so we knew, you know, we started Warp on Mac. We've since support Warp on most Linux distributions. We now have a version of Warp that we are slowly rolling out that actually works on the web. And we're working on a version of Warp that works on Windows. And so Rust was a very good choice for cross-platform also.
00:27:53
Speaker
a version that works on the web, presumably because you're taking advantage of Rust to Wasm? Exactly. Yeah. Yeah. Okay. Yeah. So rusts Rust to Wasm. So if you want to build something that supports all of those platforms, you know, the best options are The options we explored would be actually doing it natively in WebTech or using something that compiles to Wasm and the best Wasm option for us was Rust. We did look at building an Electron app. That's kind of the other like standard
00:28:30
Speaker
option from a performance perspective. Um, it wasn't nearly as performant. And so yeah yeah i enough we had, um, you know, the Zed editor, we had the creator of that on and he started an electron and moved to rust because of performance, right? right Yeah.
00:28:51
Speaker
Yeah. And like for for for a terminal, that really does matter because you know what what you find is that sometimes you have a lot of data flowing through a terminal. It could be a lot of server logs. It could be you've got some big file and want to search through it. And so it's really not fun to have a ah terminal app that is like stuck in garbage collection and you know like can't get a decent frame rate. and so we picked We picked what we thought was the absolute fastest stack. and yeah This was informed a little bit by um my prior experience. so I used to be the lead engineer on Google Sheets. and so yeah and so and in In the course of building
00:29:40
Speaker
Google Docs and Google Sheets, you know we spent a ton of time trying to get performance at something like the level of Excel in Google Sheets in the web platform. And that was extremely difficult because of all of the um because of all of the overhead of doing things in JavaScript and doing them in the web. And so that that' sort of informed our decision with Warp to just pick what we thought was like honestly the fastest possible platform. And so that that for us was Rust plus doing all of the all of the rendering directly on the GPU.
00:30:19
Speaker
Yeah, OK, that makes sense. And it's funny, I gladly do a whole podcast on how Google Sheets was constructed in the early days. But I'm not going to ask you that, because I know you can sign off from legal, which we'll never get. So let's move to the other thread we left there, yeah which is Rust on the GPU. Tell me about the your rendering framework and how it works. Yeah, so our rendering framework um So as a developer who's using it, it feels a lot like you're using something like Flutter, ah which I don't know if you're familiar with that. but i don't So Flutter is a framework and that Google has put out. um You could think of it. it's it's
00:31:05
Speaker
It's a UI framework, so it's not that different from like you know writing a UI in Swift, for instance. And so you know you you construct components. it's all in It's all in code. We don't have like a markup version of it, so it's not like writing HTML. It's all in code. But you basically, as a developer, you would say, OK, I want to create a rectangle.
00:31:28
Speaker
And I want it positioned here. I want text. And I want it here. We have more complicated components like a button or a scrollable area. And so just imagine a UI toolkit. And we defined the API for what that looks like. And so as a developer, that's how you use it. As an implementer, what happens is You know, when we what we do is we we get um starting at like the root of a view, you end up with a tree of these elements essentially. yeah You go and you figure out um what is like the position and so in size of each of them in terms of a few basic
00:32:19
Speaker
um UI primitives. And it turns out it's really it's actually very interesting. The only UI primitives that you need to build an entire terminal app are rectangles. And those rectangles have properties like corner rounding and borders and background colors. and But it's really just a rectangle. You need um images, like if you're going to have icons or anything like that. And you need glyphs for text. So those are the three
00:32:53
Speaker
UI primitive types that are our whole UI component framework. When you take those tree of UI elements, it basically boils down to rectangles, images, and glyphs. And then what you do with those is um we have basically a little bit of graphics code. So ah in like how are you with with It's like graphics programming. So it's basically written in a shader language. OK, yeah. You can think of it as like OpenGL or on Mac. we The shader language is based off this thing called Metal. And you write shaders that support these three primitive types.
00:33:37
Speaker
And so what ah what a shader does is it's a program that runs on the GPU. And essentially, you pass it information around like, like hey, for for here's all of the rectangles we want to render in this like rendering pass. You pass it all of the coordinates of um the edges or like the vertices of the rectangles. And then you pass it logic around like how do you want um sort of the individual pixels to be rendered based on their position in those rectangles. So there's two of these programs. There's a program called a vertex shader and a program called a fragment shader. And you queue this whole thing up every time you want to render one frame.
00:34:25
Speaker
and and then it gets it gets rendered all on the GPU. That's very, very high level. so Let me see if that made sense. okay so Is it up to you to say things like, I've got a medium-sized rectangle in front of a small rectangle, so we don't need to bother print we don't need to bother rendering the small one because it's obscured? Is that on you or is that on the GPU?
00:34:50
Speaker
Yeah, so that's a that one particular question is a great question. So the way that we do this in our UI framework is everything gets divided up into um layers, which, if you're coming from the web world, you would think of as Z indices.
00:35:04
Speaker
i think that I don't want to answer this incorrectly. I think that we have the GPU configured in a smart enough way so that it uses like, forget what it's called, the painter's algorithm or something, where it's like stuff on top of other things. i'm not I don't think it needs to render the occluded pixels, but I would i could be wrong. That's a good question. it's it's It's an interesting question. I think we're smart enough in how we do it. What's up?
00:35:36
Speaker
I guess these things are designed so that they can handle like racing games and minecraft so yeah unlikely you can attack either way exactly so like what we're doing i think is like. Is pretty simple for the for the gpu but it does make a really big difference in performance compared to if you were.
00:35:57
Speaker
um doing all of the rendering logic on the CPU. so um it's and are Just to give you a sense of how much graphics code it takes to render all of Warp, and I think it's probably similar for other terminals, it's like three or four hundred lines of ah shader code. Really? I'm just talking about the the code that's purely in the graphics language. The code for the UI framework is is way more than that, but it all boils down to that.
00:36:24
Speaker
So what you're saying is you define the UI that compiles down to exactly the the shader language, and it's 300 or 500 lines that go across the bus. Yeah, exactly. and okay And how often is that happening? Is that like every time you get a new character? but Is it 60 frames a second? It's happening 60 frames or more per second, as fast as you can. So you're just constantly re-rendering? Just constantly re-rendering. You know, we something has to change to invalidate the scene. um But yeah, basically, if if something and every time something changes, so if the cursor is blinking, we're re-rendering. Right. OK.
00:37:03
Speaker
OK, that gives me a sense of it. So I'd have to learn. Where I want to get to is the point where I feel like I could compete with you and I don't want to. That's the level of knowledge that interests me. I will say we we did this like the hard way. Right. There are if you were just building for a single platform.
00:37:20
Speaker
um I would just use like SwiftUI or something like say we're doing this on Mac. There's no reason to build your own UI framework. That's an insane choice. But because we knew we wanted to support Warp across all of these different platforms, you kind of have to go a little bit lower in the stack to do that. And you know if you were to look at our platform abstraction,
00:37:46
Speaker
um Warp ah Across platforms, we share like 98% of code, and but the parts that we can't share are the direct calls into the graphics APIs. Because those graphics APIs are different on different machines. so like Mac is uses the Metal API on Linux. You use Vulkan or OpenGL on Windows. I forget what it is. On the web, it's WebGL. So you have to abstract it there. You have to abstract it at the at the level of like
00:38:20
Speaker
the windowing api meaning like how do you create a new window on that platform oh yeah and then you have to abstract it at the at the level of the um the text layout because each of these platforms have different sort of system fonts and stuff that they that they ship with um but for the most part you can if you put some thought into it, you can actually abstract. um You can build a cross-platform GPU-accelerated app in Rust. Yeah, I can start to see that. and and You're on the browser, even though with the Wasm version, you're still basically shipping out shader code. Correct. Yeah, exactly. so like like If you were to like go into the browser version of Warp and do like inspect DOM or whatever, you would see
00:39:11
Speaker
one big canvas, ah like one big WebGL canvas, and you would see one big WASM binary for the most part. Like there's some stuff, there's obviously, there's always a little bit more complexity to it than that. um And that's similar by the way to when how like, I don't know if your listeners will be filled familiar with like Figma, but that's similar to how, um like there are other web apps that are basically just full WASM WebGL apps um for similar reasons that Warp is. Yeah, I can see that happening more and more as time goes on. Yeah. And the infrastructure around it gets easier to put together. Yeah. Yeah, totally. And even even for us, there's a bunch of Rust libraries that have made this
00:39:56
Speaker
to have done a bunch of the abstraction to make like sharing like the graphics code easier, which is really nice. Is that something you'll be looking into doing, or perhaps have done, is spinning out a Rust cross-platform framework for doing? 100%. So yeah, our our plan is is to open source the um the UI framework that we've built along with the cross-platform parts of it.
00:40:24
Speaker
um As far as timing on that, i would so we are trying to get our the Windows version out so that we can prove that this platform works everywhere. And then there's just a bunch of work to make it a nice open source project. But I i think in 2025, the UI framework that we use will be out there if in case anyone else wants to to use it, you know, i like the caveat being like we built it for warp, but we did build it in a pretty general
Open Sourcing Warp’s UI Framework
00:40:54
Speaker
way. So if anyone wants to make a UI app, yeah like a GPU accelerated cross-platform UI app in Rust, they can try it.
00:41:04
Speaker
i I saw last night, coincidentally, that um to get like an IoT microcontroller with a capacitive color touch screen is really cheap these days. yeah So if you want to roll your own iPad, that maybe this will be the way to do it. That's cool. So tell me just before we move on from that, like your from developer space in your UI framework,
00:41:31
Speaker
yeah is that like I mean, there are two big models. Is it like a virtual Domish thing or is it like an object oriented UI framework? It's, um, let's see how I would describe it. So.
00:41:47
Speaker
It's not really like a virtual, um so it's it's not like React, I i should say. Like if people are familiar with React or like HTML, it's not really like that. It's much more like um like programming in Swift or Flutter. And so you programmatically describe the scene that you want in that um Yeah, it's like it is a tree of objects. So in that sense, it's a DOM. um But it's it's there's no like data binding, so it's not like reactive. So it's much more like a traditional model view controller type model is how I would describe it. Yeah. I suppose you've got the thing that like unlike the web, most of your input is kind of completely separated from the output.
00:42:43
Speaker
keyboard in screen out yes yeah okay okay yeah that's right so on top of this or perhaps behind this i should say you've got your collaboration app is that have you gone rust across the whole stack We have not. and i I wish we had. okay and I wish we had. So our our, like the SaaS part of warp, like the cloud services part of warp is written in Go. okay And so the,
00:43:15
Speaker
For the most part, we have like the real-time collaboration is actually done through a Rust server, but the um most of the SaaS part of ORP is done through a Go server. and that's built on It's hosted at Google Cloud, and it's built on. ah We use Postgres as like our data store. OK.
00:43:34
Speaker
that i mean I don't want to start a flame warp that isn't already, but you know you it's easy to see Go and Rust as kind of rivals, and with you coming as a background from Google, I wouldn't be surprised if you told me you were all in on Go. I am surprised you used both, and Go is the one you want to get away from. Yeah, like if i had it if I had a time machine, I would probably just go back and do Rust throughout. The the rationale for Go at the time
00:44:05
Speaker
and I don't know how true this still is. was like the um On the server side, there was more official like Cloud SDK support and native support for Go by far. There was like an official Google Cloud SDK written in Go and not one written in Rust. and so if you want to do like If we wanted to do stuff in Rust on the server,
00:44:34
Speaker
we would need to be interfacing with like all of their like REST endpoints to do like I don't know, IAM authentication and stuff that it we just were like, oh, this isn't really worth it. um And like monitoring libraries were more readily available in Go. And so like the the ecosystem at the time for Go was better. ah you know My current thinking on this is that I would rather um our development team and I'd rather me not have to work in two different languages. it's just like It's just like a lot of cognitive overhead for not that much gain. And then because we're in you know, go and Rust, you can't really reuse code across the client server, which we don't have like a, we have some use case for, but not major use case for. um And then I don't know, I personally at this point prefer, I just prefer Rust as a language. Like I'm very big into,
00:45:39
Speaker
let the compiler make my life hard so that at runtime, I'm not going to have as many issues. And I feel like you know Go is ah is a somewhat more dynamic, more permissive um language. And i I feel like it pushes some issues into runtime. And it's it's not as performant as as Rust. And so i'm i'm in the I'm in the Rust camp at this point.
00:46:04
Speaker
Okay. Yeah. Yeah. I can see that. It's, um, it's just interesting to hear an ex-Googler say it in public. You know, when I was at Google, I'd mainly worked in Java, um, which yeah, I mainly worked. And I think a lot of like Google apps is, I still think Java, I don't know how much of it has moved to go. And then, um, you know, a lot of the Google search stuff was all CC plus plus just cause they needed really good performance.
00:46:32
Speaker
Okay, yeah, I can see that. And Postgres Rice at the back. Was that was that always going to be Postgres or was there an evaluation stage for that? I think that the other the other thing that we considered was maybe like a like a Mongo or like a ah like sort of more document DB type thing. um But I...
00:46:59
Speaker
You know, our database requirements are not super complex, and we have a relatively good relational schema. and so i mean we post postgres yeah we we were We were not trying to reimagine or reinvent. like the and we We didn't feel like we needed anything custom on the back end, really. Whereas on the client, we felt, obviously, from how I have to describe it, we built felt like we needed to do it the hard way. On the server, we did not feel like we needed to do it the hard way. but Okay, I like that. Picking you right battles. Yeah. Yeah, we felt like most of the technical challenge and complexity for us to start was in like,
00:47:41
Speaker
high performance um terminal with a very, very different and reimagined user experience. And that's mostly client challenge. i So going back to that kind of user-facing world, I've been using Warp on and off for a couple of weeks, and so I have a sense of what it feels like.
User Experience and AI in Warp
00:48:02
Speaker
But this is radio, and I need you to describe it. So what okay what is what is the what's the developer experience you've actually put in people's hands?
00:48:12
Speaker
Yeah, so there's a that there's a few things that are really different. So the the first thing is ah we've really tried to make it so you don't need to spend time configuring your terminal in order for it to be useful. And so what that means as ah as a user is when you start in Warp, you'll find that certain things that you typically have to set up in other terminals just kind of Work at a baseline level that we think is really good. So for instance your prompt which you know people will configure it using their RC files or Something like that or you don't use an external framework in warp. It just comes it shows your git branch What's dirty your hosts? It shows you you can kind of configure it using a nice like visual UX for it. So the prompt is works the a similar thing is true with completions, so so
00:49:06
Speaker
um You know other terminals if you want help. completing Git commands or Docker commands or AWS commands or you name it, you typically have to hunt around and find something to add to your RC file and warp. We support like 450 different CLI tools with completions out of the box. um That was a quick question, which is how do you keep that in sync? Like if I update my version of the AWS client,
00:49:38
Speaker
Yeah, so there's a, it's not perfect, but the the it's based on an open source project where um the community kind of does its best to keep these things like a changing and there's a so ah schema for it. And so, you know people can kind of submit updates. um the The next thing you'll notice in Warp is just that the it looks,
00:50:02
Speaker
pretty different from a normal terminal. And so, you know, normal terminal is just a character grid. In Warp, we've kind of given you something that looks like, um I hate to say a chat app. Actually, I'm not going to say that. It looks like a terminal, but the biggest difference is like when you go to type in text, the actual like text editor is it does a lot more than what you would get in a normal terminal. and so has Like I described at the beginning, it works more like an IDE.
00:50:36
Speaker
Click to move your cursor around. You can double click to select text. If you hit Delete, it deletes the text you have selected. If you hit Up, you get a history menu that's like visual. You can have multiple cursors even if you want. So it's like, OK, you're editing the IP address in three places. You just hit Command-D, and it selects all those. And so if you're used to using you know like Sublime Text or VS Code or something like that, it's going to feel very normal.
00:51:02
Speaker
When you run a command, it's also going to feel a little bit different because as you run more and more commands, we separate the terminal output into these things that we call blocks. and Those blocks um basically have the command plus the output associated in one like visual unit. And the cool thing about that is like you can scroll your terminal command by command rather than just by line by line. You can easily copy paste. You can get a link to anything that you did, like one command and its output and share it with your team. And so yeah those will those are things that you're going to notice about the basic UX.
00:51:42
Speaker
Another thing that you're going to notice is that you don't actually have to type commands. And this is this is where it starts to get kind of crazy. You can just type in English. And so we have a um we have a local classifier that we built that distinguishes between English and commands. And if we have a very high degree of confidence, like 99.9% confidence that what you're typing is English,
00:52:08
Speaker
we will interpret what you're typing as a question to the LLM. And so that's that's totally different. And so like I said, you could be like, ah you know, you and you can you can very easily include context for the LLM. So I could be like, explain the error in my last commands output. You can type that and you can say, OK, I want to include this output. And it will answer that for you. Or if it doesn't have enough information to answer your question, it will be like, let me run a command to gather that information. So for instance, if you're like, um help me create a PR for my open files, it'll be like, okay, let me run git status and see what your open files are. And then I'll look at your open files and i'll be like, let me run git diff to see what all the differences are. So it it will actually do these multi step workflows for you. And so it's,
00:53:03
Speaker
It's kind of like a terminal with a much higher abstraction layer, ah yeah which I would argue is it's obviously good for new developers, but it's actually really amazing if you are an advanced developer and know what you're doing and just want to do a lot of more complicated things more quickly. You don't want to have to go to Stack Overflow to remember how to do something. So those are the big differences.
00:53:27
Speaker
Is that, I'm just wondering if that's, um, if that's something you need special support for. I mean, there's like someone in your team really grooming the set of possible get question related responses. Um, so I get.
00:53:47
Speaker
we Well, I guess there's two answers. So one is like, we have like support for warp the app, right? Where if you have a issue, you can file something on GitHub. I think, are you asking in terms of in the product experience?
00:53:59
Speaker
Yeah, im so so you're saying, like if I say create a commit for me, you're saying it does git status then git diff. Has someone explicitly said, for this kind of query, these are the kind of actions you need to run? No. so the way It's really interesting the way that it works. The way it works is all through the is all through prompt engineering.
00:54:18
Speaker
so you know We basically have created a um ah sort of agent infrastructure on the AI side where if someone, just to take that example that you said, so if someone types into warp, like help me make a PR based on my open files and take a look at the diffs to help me construct the commit message, you can literally type that. What ah what we're doing is we're sending that along with a system prompt, which says something like,
00:54:50
Speaker
Hey, this is a i imagine you're a smart assistant working in the context of a terminal. And then we give it instructions that say something like, um you can if you you can ask the user to run commands.
00:55:07
Speaker
that will help you achieve your task. um And so that's part of the system prompt. And then the LLM knows that it has available this tool essentially, which is the ability to ask a user to run a command on its behalf. And it's smart enough then to be like, okay,
00:55:28
Speaker
In order for me to answer this question for the user, I need to ask the user to first run the git status command. It's it's amazing. ah yeah And so the you know the way that we think about this is like we we can expose these tools to the LLM and prompt it correctly to use them.
00:55:50
Speaker
And the LLM is smart enough to then be like, okay, I know that I have the ability to ask a user to run a command. So for any context, it doesn't you don't have to do anything specific around Git. ah It will ask the user to run the relevant command. So for instance,
00:56:06
Speaker
If I was like, help me read server logs from ah from Google Cloud, it will be like, oh, OK, I know that there's a gcloud command line tool that does this. I'm going to ask the user to run that so that I can get the information I need to answer the user's question. Does that make sense? Yeah, yeah, absolutely. So if if I were looking at a random server log, it might ask me to send it the first five lines of that log. Exactly. It would be like, OK, run this with tail dash you know, and 100 or whatever, it it it's able to use this, it doesn't, we never let it use it directly. Just i was going to ask yeah because we're, you know, it can be wrong. And so we always want to, uh, developer, at least for now.
00:56:51
Speaker
to double check the command. um So the the the way that we've created the UX for this is like it will ask me to run a command. And then if I don't know what the command does, I should probably hit Control-C and not do it. But if I'm like, oh, right, OK, it's going to run this gcloud command to look to list my servers, i can I can do it. And so it's this incredibly cool way of having um an interaction with the LLM where it gets the information it needs from you in order to help you solve your problem. yeah yeah It's really, really neat. that's It's a totally different kind of programming than anything I've ever done. like you know it's you're You're programming it.
00:57:35
Speaker
by by iterating on different English language things that you're asking it. Like, have you done any of this prompt programming? It's really crazy. Yeah, it is a little crazy. and And the experience can be fantastic. Yes. One thing I wonder is, especially for newer programmers, like is it are you doing anything to help teach them the next time they could have said it in the shorthand form? Yeah, so that's a great question. So i actually yeah so the here's the the risk that I think you're getting at, which is like,
00:58:05
Speaker
Well, if you can just talk to it in English, does that just mean you never learn how to use it? And are you like shooting yourself in the foot because rather than learning how to use this essential tool, you're just like kind of like asking, you're like cheating your way through it. um And there is, I think that there's, that's a little bit of a real risk, but I think on the flip side, what's amazing, at least with the way that we've built it is if I'm like,
00:58:32
Speaker
um you know For instance, I'll just go back to this gcloud example. Help me pull server logs from you know my gcloud run and search for all logs from IPs that are in ah East Asia or something like that. What it does is it it doesn't just do it for you.
00:58:53
Speaker
it gives you each command and potentially if you want explains it for you so i can be like okay before i run this please explain what each part of this is going to do so to me it's actually like If you use it in a certain way, it's an incredible learning tool. It's an incredible accelerator for learning how to do very hard things in the terminal that otherwise I would have asked to ask you know my friend Josh to do or whatever. So that that's what's amazing about it to me. um you know Again, the downsides are,
00:59:29
Speaker
you know, is as a user, you have to want to learn it, obviously, so you got to put in the effort. And then, you know, there's risk. I think everyone knows this because it can suggest things that are totally wrong. And so if you don't know what you're doing, there's risk around that. um And you know I think that that risk will go down as these models get better. And so you know to me, the right approach to this as a user and also as like an application developer building an AI feature is make sure that that um the user is approving and make sure that you have a good ability in the app to explain what the thing you're suggesting, what the AI is suggesting it actually does. So that's our approach.
01:00:11
Speaker
What would you say internally is the adoption of this kind of, I mean, I assume all your programmers are using warp as their terminal. Yeah, so we are using pain of being fired. 100% warp. And then for the, are you asking about the AI stuff? yeah um Generally, that specific, but also generally like how much you dogfooding this and learning about what actually works before you ship it.
01:00:36
Speaker
as a terminal program? So on the AI side. so
01:00:44
Speaker
You know, different developers use it to different extents. I guess that's a really sort of generic answer. There are some developers on the team who are much more enthusiastic and try to use it a lot. And some developers who um who don't really want to use it at all. They don't trust it. They're like, you know,
01:01:08
Speaker
AI is kind of dangerous. And so I think if you look at the prime mirrors, the developer community as a whole, which we find that people have mixed feelings on the use of AI. I'm very much on like,
01:01:26
Speaker
the bullish side, where because it's it's helped me do things. It is literally, without exaggerating, it would have taken me 10 hours to do. Because i've like if you you can get really cool with how you use it, you can you can like have it learn tools and learn data formats and do transform it. It can do incredible stuff. So I'm like very much in the bullish camp. But it's um it's a mix in terms of um how much people use it. In terms of actual warp users, a really significant percentage of them use it
01:01:57
Speaker
like like I don't know the exact thing, but it's it's it's high. It's like a very commonly used piece of the app, which to me indicates that um you know there's real value in it. But we also get people complain at us being like, why the hell did you put AI in my thing? like I don't want it there, like which which is fine. um But ah you know my I think long-term,
01:02:23
Speaker
um You're going to kind of fall behind a little bit as a developer if you don't learn how to use
The Role of AI in Developer Productivity
01:02:28
Speaker
it. And so I think the proper view of it is just like, it's another tool in a developer's toolbox that you can become a better developer if you learn how to use it well.
01:02:37
Speaker
yeah Yeah, I can believe that. If I'm being completely honest and candid with you, so I've been using Warp for a couple of weeks, yeah I tried out the AI stuff immediately, and then I disabled it so I could try it properly, and okay you're reaching the level of trust to where I might re-enable it. Yeah, I mean, I will say, nothing ever leaves your terminal unless you unless you explicitly interact with the AI. So if you're if you're concerned about that, and then um Yeah, it's like it's like learning a new tool, I think, is the best way. And so there's going to be early adopters who are excited about it. There's going to be people in the middle who are like, I'll use this when it's proven. And then there's going to be people who are like, and over my dead body, am I like trusting you know an LLM to do some complicated terminal task? um So that's my feeling. Yeah, OK. That's very realistic of you. And I like it.
01:03:33
Speaker
yeah you've You've raised one last question I want to ask about this, which is, I'm thinking, there's a command line tool I've been using recently that I'm sure your LLM won't know anything about. like It's an internal tool that we have. Is there any prospect of teaching local tools to your wall?
01:03:52
Speaker
Great, awesome question. so You can do this today in Warp, but the problem is you can only teach it for the context of a ah single conversation. but so If I were trying to do this today, what you can do is you can ask Warp, you can you can describe the tool. like I don't know what the name of your tool is, but it's like... Let's say it's like Fubar CLI. If Fubar CLI has a help option, like a dash dash help, you can basically ask Warp to be like, hey, can you learn how to use Fubar CLI for me? Please run Fubar CLI dash dash help. And if the help has like reasonable documentation, um then all of a sudden, Warp will know how to use it.
01:04:36
Speaker
It will only remember that for the length of one session, so you'll always have to do it. And we're we're trying to figure out how to like make this reusable. But the the magic of the LLMs is that they can be taught. And so you can teach it about special internal data formats. You can teach it about parts of your code base. You can have it read your readmes. And based on ah it learning that, it can then do things.
01:05:01
Speaker
Does that make sense? yeah yeah Yeah, and it sounds like an interesting challenge. in short That's got to be something that's going to come ah up if you want collaboration in enterprises where the banks have weird old tools. You have to have it learn how to use your internal tools that publicly available are not in the training set, um but the you really can teach it, which is so neat.
01:05:23
Speaker
Yeah. Yeah. Okay. That's cool.
Warp: Aesthetic and Functional Innovation
01:05:25
Speaker
Um, and I can see that being well used over time, but in the meantime, you've got a nice shiny terminal that I thought was pretty. And that's, I think a lot of people just use it because they're like, Oh, I like it. And how it looks. The themes are nice. Um,
01:05:40
Speaker
ah Okay. i've I've got to go and do some, I spend half my working life in the terminal and the other half talking to people. So I should probably go, I should probably leave this conversation and go straight back to warp and kick some more of the tires. All right. But for now, Zach, thank you very much for joining me. Thanks so much for having me, Chris. It was a pleasure to be here.
01:05:59
Speaker
Thank you very much, Zach. So now on top of everything else, I am thinking between Warp, the terminal, and Zed, the text editor, is there now a race on to see who can open source the best Rust UI framework, because they're both doing it.
01:06:17
Speaker
Are there other contenders? Are there other Rust UI framework creators out there that I need to interview? That's a research topic for future episodes. If you want more things to research, you will find links to everything that Zach and I discussed in the show notes, including, of course, a link to download Warp. If you want to give Warp a try, I would encourage it. It's an interesting addition to the terminal world.
01:06:42
Speaker
Before you go and do that, if you've enjoyed this episode, please take a moment to like it, rate it, share it with a friend, make sure you're subscribed in time for next week's episode. And if you want to support that future train of episodes that's coming on down the track, please head over to the Developer Voices Patreon account and sign up to become one of the wonderful people that helps make this podcast happen.
01:07:07
Speaker
With all that said, it's time to say goodbye. That's the end. I've been your host, Chris Jenkins. This has been Developer Voices with Zach Lloyd. Thanks for listening.