In November, David Cramer, the founder of Sentry wrote, got to admire the never ending passion from Mitchell Hashimoto on whatever he builds. Mitchell is today's guest. He's the founder of HashiCorp. HashiCorp went public in November 2021. But today's episode is not really about HashiCorp. Today's episode is primarily about Ghostty, the open source terminal emulator that Mitchell is building. We talk about designing dev tools.
I would tell all dev tool founders to chase that human experience.
About building challenging technical projects.
To me, I I've taken the opposite approach, which is I look at something like a web browser and I think it's made by people. I'm people, so I could do it.
Open source sustainability.
And I think that bar is so high. I think that for a lot of open source projects, having at least some compensation for time is more realistic. Passion and hiring? In any category, again, I would hire the person that's overly obsessed with a topic over anybody else any any day of the week.
And using AI as a developer?
I think it's extremely suspicious when any software engineer says, oh, I don't use AI tooling.
Tooling. I think that Mitchell is just a kind of walking, living, coding reminder that your passions really, really do matter, and they can take you really far. That was actually just before the call. I didn't I didn't realize that like, you'd written I I discovered this other article that you've written about, like, new normals.
Long time ago.
It's, like, actually, like, a really good article that, like, it was you read it a long time ago as well.
Yeah. Thanks. Yeah. I I wrote that. I was, like, 21 or something.
I I mean yeah. I was just, like, I wrote that because I was in a space where I was just kinda looking around and kind of shocked at what I was getting into, and, but at the same time realizing that everyone around me was sort of doing the same thing. But, you know, when I went home and saw peers my age at the time, it was very unusual what I was getting into, and it just made me realize sort of the importance of the the people that surround you.
Yeah. And, yeah, I think you started off, it was like, when you're a kid, and you started working on games, like, like, like, like, cheats
and stuff from
games and things like that. Right?
That's right.
And that was, like, your new normal because suddenly you were doing that for, like, you were, like, coding for, like, two hours a day. Yeah. So I guess, like, I was well, it's kind of going. It was, like, I was curious about what the new normals are for you now, because there was, like, you found your new normal of, like, best start ups, and you're it's normal to do a startup. But then, you know, this was right before. I'm kinda curious about what your new normals are now.
It's that's a great question. No one's really asked that. So I have to think about it a little bit. I mean, I think for me, my new normal really is around family. I really feel like I'm really you know, I had my first kid, and I feel like I feel like my primary day to day job is just being a dad.
And I think that that's normal for me. And, you know, the work that I do now, whether it's, you know, my fund projects like Ghostty or some of the investing or advising, I do and and or philanthropy or volunteer work. Like, I think all that stuff is sort of just secondary. Right? Like, it's, which is not normal, I would say, in general. Like, there's not a lot of peers that I have that, are in that same situation. But, but, yeah, the the real grounding thing for me is probably the parenting.
Do you think that yeah. Sorry. We can that it get goes very off topic, I guess, in that. But, like, I was gonna ask, like, is that do you think you would have got to that anyway, like, without the startup success? Or
well, I think the the mechanics of it all would have been very different because, you know, I'm in a position right now where I don't have to work full time. And so I think that's a significant difference. So, yeah, I'm sure I would have loved parenting and I would have, found that to be the most important thing in my life, regardless of what ended up happening. But the sort of yeah. The like I said, the mechanics of it are different, and I think that's different enough that, it changes my outlook on things.
This episode is brought to you by WorkOS. If you're building a dev tool, at some point, your customers are gonna start asking you for enterprise features. WorkOS offers you single sign on, skin provisioning, and audit logs out the box. WorkOS is trusted by Perplexity and Vercel as well as Work Brew, a home brew management startup that I recently interviewed.
I just told Mike that WorkOS is the sponsor and this is what Mike said. Yeah. So WorkOS isn't paying me any money for this. I I pay WorkOS money for this, but WorkOS is like one of the best developer tools I've, like, ever used. It's it's the documentation and the experience with building with them is so, so good.
Like, I initially was almost like, okay. This seems expensive, but then I built an integration with them in about twenty minutes. So I had spent two days banging my head off the wall trying to build it directly with Okta. And then with WorkOS, I then have, like, many, many SSO providers, like, supported instead of just one. So, yeah, like, for me, WorkOS is one of the nicest developer experiences I've encountered in the last, like, five years probably.
And it's so surprising because a bunch of the developer team are ex GitHub and therefore very good at their job.
Go to workOS.com to learn more. And it it it's kind of interesting as well because, like, even you you talk about the secondary, stuff, but the with your projects, there's something different about I don't know what it is, but it's, like, almost like and I know I'm not alone here because like I see people talk about this on Twitter and stuff like David Kramer talking about like your passion for actual like building stuff is just somehow fascinating and also, like, uplifting and, I don't know. It's kind of inspiring.
Thanks. Thanks. I I do think I think, you know, it's I think I'm very genuine about my passion on building. I think I don't you know, you don't need to believe me. I think you could just see that in the work that I do.
But I think there are a lot of people out there that that I don't know. They it it feels like they act passionate about something. Mhmm. And then, you know, circumstances change or, you know, they make a lot of money or something, and then you realize they were just saying that to get to that point. And it's fine.
That's fine. I just think that, I'm the type of person that that wasn't the case. Right? Like, my I think I got lucky in a lot of ways, and I'm thankful for that. But my driving force through tech through I mean, before tech, through college was always I always just chased my passion.
And that was that thankfully worked out well for me. But, yeah, that's I think even if it you know, if my startup career didn't didn't end up being as successful as it was, I think I would still be working for companies where I was having the most fun. I mean, I think that I've always optimized for that. So that's, yeah.
I guess there's, like, there's kind of an there's probably an incentive, isn't there? I suppose, like, to people there's this not knowledge that passionate engineers are, like, better engineers and probably have more startup success. So I suppose there's there's a reason to kind of, like
Maybe.
Be perceived as that person even if you're not.
May maybe. I I think for sure that passionate hiring passionate people in any category, not just tech, is always, like, better. And I actually I tweeted about this, like, I don't know, last year sometime because, it happened with the I was fixing a garage door on my house, And, it kept breaking. I don't know why. You know, we don't need to get into it.
It kept breaking. And I finally found I finally found this garage door guy that came over. And I, you know, I had a newborn. Newborn was crying. Because it was a year ago. Newborn was crying. Newborn had to be fed. And I had this garage guy come over, and he would not stop talking to me about garages. Not about my garage, just the garages in general. He was just, like, going on and on about this spring and this type of motor and this thing.
And and I, you know, eventually I I was I was listening to be polite, but I really had to go because my baby was crying. And so finally, I was like, I'm so sorry. I have to go. But in my mind, I was like, man, this guy really loves garage doors. And so I know he's gonna do a good job. And he did he did a great job. And and, I would use him again. And and so I think that applies. I tweeted about that incident, but I think that applies to everything. Yeah.
And even when I was an employer, I felt like if you find you know, there are people that say that it's not fair to expect someone to have a GitHub resume or something because work life balance and different life circumstances. And that's totally true. But it's also true that if you find someone that has the time and makes the time to do that stuff, that they are likely better. And, you know, it's unfair because life circumstances have given someone a better chance of being better. But, like, that's just what I've practically seen throughout everything, in my life.
I I would hire, in any category again, I would hire the person that's overly obsessed with a topic over anybody else any any day of the week.
Yeah. That it it makes all the sense. And would you say that maybe you are, like, the garage door to you are a garage door guy, that you were just lucky that your your garage door was, like, a very crucial thing.
I got yeah. I am for sure in different topics, but I got lucky that the my in that metaphor, my garage door happened to be something that turned into a big industry. Because because okay. My obsession right? We could we could take it back to, like, February.
My obsession was a mixture of automation and infrastructure. Like, that was my obsession. And we were in a time where that wasn't actually that interesting. The cloud wasn't taken very seriously. Existing automation tooling that was, venture backed was not doing was not successful in the eyes of venture capitalists.
And so I've I've said this before, but, like, my time at HashiCorp, we had a really tough time raising our first couple venture rounds because it was not a good looking company. We didn't have a business plan. We had this open source that was popular but didn't make any money. We were remote. We were open source.
We were doing infrastructure. We were doing cloud. Like, all these things were not cool. And, we basically got saved because of Docker, I would would say. Docker hyped up the entire industry, like, overnight. But but I just got really lucky. Like, I think I would have done infrastructure automation as long as I could have four regardless of if it blew up. Like, I just got lucky that that did end up being something that was, that was that blew up.
Why do you think you got so kind of passionate about it? Was that is it something that you've kind of thought about, like, where it came from?
Kind of. Yeah. I mean so the automation part, I've I I think that's a common thread throughout my programming life, whether it's career or hobby. I've always loved automating things. Mhmm. So that that one is there. But the infrastructure side, I think there was, to me, what originally got me into it, there was this element of sort of mystery around it. The first job that I had, we had, I don't know, a dozen web web programmers. Like, that's how I started was Rails. So I was doing Rails.
And we we had, like, a dozen Rails people. And we had, like, one guy sitting in the corner, you know, on his ThinkPad using Linux, long hair, only wore black, and he did all our infrastructure, and he wouldn't talk to anybody. And I as a I was, like, 18 or 19 at the time. And I remember just being curious. Like, what does that guy do?
And, like, we we give him stuff to just put up and he fixes problems. And, like, how does it work? And I and I just and I think to add to the mystery, you know, I was using a Mac, and I would watch his screen sometimes. And it I had no idea what was going on because, you know, he is a tiling window manager, and he was in the terminal all the time. And it just seemed like for for me as an 18, 19 year old kid, it seemed like magic.
And so Yeah. That pulled me into infrastructure. And then my interest thereafter was sort of humanizing infrastructure. It was like, let's make this not so scary for people and and make it not as, like, mysterious. And so yeah. I think I think that's what got me into it.
Yeah. Yeah. And and on that kind of, like, making it human, I think you've got I feel like you've got quite a few different approaches to building products for developers that I've not at least I've not heard many people talk about. So for instance, you've mentioned about how you would kind of, create fake kind of, like, terminal experiences and, like, do, you know, do sleeps and stuff like that. Could you talk about some of the some of the methods that you use there?
Yeah. Well, I think I think taking a step back, I think it is very important. You know, like I said, in my job, I like to have fun. I think that using tooling, whether in your career or anything, should also be somewhat enjoyable. I I I don't always say fun because, you know, a lot of people don't like their don't like doing this stuff, but at least it should be somewhat enjoyable.
And so to that end, the ultimate benchmark for me is the human reaction to using a tool. Everything else is a means to that end, to to to me. So performance, design, functionality, all of that only matters to make the human operator happy, in my mind. You know, even functionality. Is it bug free?
Like, I think that there's I I think most engineers would say being bug free is important. And I would say it's only important if the person doesn't hit the bugs. Right? Like, if they're using the software and it works for their use case and there's bugs, but they never hit the bugs, like, who cares? The I don't think the perfection of software is that important to me.
It's the it's the impossible goal of having a perfect human experience with software that's interesting to me. There's another sort of concrete example there, which, gets which happens a lot with the current work that I'm doing with the terminal is people get really caught up in, numbers when it comes to performance. And, obviously, you can measure performance, in certain ways. But people get really caught up in the difference between, well, this number is 1% lower than that number, And so that is better than what you're doing. And to me, it's like, okay.
Like, you could argue that for sure from some angle, from a purely numeric angle. But, the big one that comes up is, like, input latency. Input latency for me is, like, use it. Does it feel fast enough? Then it's good. That's the answer. It doesn't matter what the number is. And I I don't mean that I'm not even saying that for myself. It's for everything. It's it's I I also like, we used to have a designer, at at HashiCorp that was working on some design, and and they showed me this design.
And I said, I think the padding needs to be a little bit more over here. And, he responded saying, oh, but I did that padding because it's perfectly divisible by this padding. And so it, like, mathematically flows. And I'm like, that doesn't matter at all. Like, the the mathematical balance of the design doesn't matter.
I was
like, oh, let's go take 10 people. Company was big enough by then. Let's take 10 people and just ask them a b which one they want. And I think it was 10 out of 10 that wanted more padding. And I was like, that's the answer. The the balance doesn't matter. A design is gonna be experienced by a person, and what the person feels is all that matters to a design. So yeah.
Yeah. That that's interesting. I I've said this so many times, but I always think of this, like, famous example of the lift going up. Did you you know, the one where it's, like, the slow lift I'm not sure. And people complaining about a slow lift.
And they were trying to figure out, okay, at this hotel, like, oh, can we speed up a lift, speed up the lift? Can we put in another lift? Whatever. And then someone said, oh, let's just put a mirror on the, in the in the lobby. And everyone stopped complaining about the slow left.
Yep.
And it was like, is it this sort of thing of, like, where if people are satisfied, then it's okay.
Yeah. I I think we only, you know, this is very philosophical, but it's very it's very deep, I guess, to my to my lifestyle. It's like we only exist to to strive for happiness in our experiences. Like, it it that's that's my day to day sort of mantra. And so whatever I I sort of look back, and I'm like, what made me less happy?
What made me more happy? And just keep optimizing for the branch that makes you more happy, within reason. Right? Like, that you could actually achieve. And I think that's all that really matters. I think I think, you know, there's others that strive for perfection in other forms. But but to me to me, I think, yeah, human experience will always be number one.
Yeah. It's very cool. And, I I think that maybe come brings us to Ghostty a little bit, in the, like, how did you kinda get on to Ghostty and realize this was the thing that you wanted to do? Because I guess that to setting it as well is very, this goes back to, like, I think what we like is about you is, like, you're just like, yeah. I'm just gonna go build an open source project.
Yeah. I mean, it's it's a it's a terminal emulator. It's a it's a to many people, it's a solved problem. So it is it's always surprising that I would spend any time working on it, and it's totally understandable. Yeah.
I mean, I it's it's mostly an accident. I think it's a happy accident, but we'll time will tell. But it's mostly an accident. I I was still working at HashiCorp at the time, and, I had spent ten plus years building infrastructure automation server side, primarily server side software. And I I was starting to feel just a little bit bored, I guess.
I should not bored. It was I didn't feel challenged. I felt like I felt like any anything that needed to happen in infrastructure, like, I could find a way to make it happen, whether it's good or bad. Like, it doesn't matter. Like, I just could I knew I could solve the problem in in some way, and that felt kinda boring to me.
So I wanted to challenge myself and and do something new, push myself out of the comfort zone. So I I took a look at what I was doing at HashiCorp, and I tried to just map the opposites, basically. So I was like, okay. I'm doing server side software. Let me do desktop software.
Okay. I'm using, like, a memory managed, like, language. I wanna I wanna go back to low level, like, count CPU cycles type of language. And then we're doing all this, like, API driven input output stuff. Like, look, I'm gonna go to graphics program. I just sort of picked all these opposites. The terminal as a choice was just whatever fit those properties. So, the terminal wasn't an opposite of anything. But it was just sort of like, okay. Low level systems programming, desktop, graphics.
What could I build that actually has all three so I could do all three at once? And I was like, a terminal could do that. It's like, I could try a terminal. So I started working on a terminal, totally thought that after a few months, I would just, like, learn something, have a lot of fun, and throw it away. I do that with a ton of projects.
Like, I have so many private projects on GitHub that never get anywhere, and I throw them away. And that's fine because it was just a learning for fun project. And, with the terminal, what ended up happening was I got to a point where I knew enough about all those things that I started looking at other terminals differently and realizing that well, I felt that they made trade offs that I didn't think they had to make, or or rather that they made trade offs that I didn't want to trade off. And so I had in mind this terminal that is cross platform, has a lot of features, is fast, and and not only cross platform, but also feels like it's not. Like, I wanted to build a cross platforms cross platform software that when you use the Mac version, feels like it's only made for Mac.
It was optimized for Mac. And when you use it for Linux, it feels like it was, like, made for for Linux and or whatever your environment is in Linux. It feels like the really native. And so yeah. And so I I felt like nothing really ticked those boxes. I felt like I could maybe do it, and that's what led to Ghostty. And I think, you know, we have work to do, but I think for the most part that for me, that's become a reality as somebody who uses it daily in Mac and Linux.
Yeah. It's, it it's very cool. And, I yeah. I've been using it, and it's really cool. It's really, really nice. I thought it was kind of interesting that you called it, technical philanthropy, which is like a really cool I don't know if you coined that term, but it's pretty cool.
I didn't source it from anywhere. But, yeah, it's sorta you know, it's just this idea technical philanthropy to me is this idea that, I'm I'm gonna spend some time programming anyway because it's my passion. Like, I'm gonna do it no matter what. Can I make that can I make what I work on and make my time spent benefit some sort of social good? And to me, you know, the social good here is that almost, not almost, but a lot of engineers, like, a lot, a lot use a terminal every single day.
And they're are they're all pretty much free already. But if I could still make that experience a little bit better for them and I could also give it away for free, then I could maybe make a lot of people's daily work life a little bit better. And that's sort of the social good that I'm sorta sorta aiming for with this.
Yeah. It's it's it was really cool. And I know you've also donated money to Zig and stuff like that. And it's Right.
So there's none there's also other types of philanthropy I do. I I wouldn't those are that's philanthropy. That's like financial philanthropy aimed at technical products, but not technical philanthropy the way I define it. But, yeah. I mean, I I my family is engaged in a lot of philanthropy.
Not just the technical projects. We do a bunch of, stuff in our community as stuff more globally. But, you know, we tend not to talk about it too much. But it's, I think, you know, no matter what I do, that's not my passion. Right?
Like, I don't want to spend all day pursuing those social causes. Like, that's why we donate the money because that's a way for us to sort of make an impact without me having to spend so much time on the social causes. But where I really do wanna spend time is programming. And so
Yeah.
Yeah. That's that's the the balance.
I think it's really cool. And it's like, like, kind of rogue question, but, you know, everyone talks about, like, open source sustainability. But do you think, like, kind of, if people donated more to, like, you know, Exeter founders donated more to, like, technical projects, do you think that could be one of the ways to kinda make it more sustainable?
Maybe. I think my opinion on sustainability is that that word is a really strong ideal, but it's a really high bar. Because sustainability means that it you I don't know the exact definition, but to me, sustainability means that it fully funds somebody working full time on that project, like at least one. Like, the project itself is fully self sustained. And I think that bar is so high.
I think that for a lot of open source projects, having I don't know what the right word is, but having at least some compensation for time is more realistic. Realistic. So I guess, like, you know, my though what I spend a lot of time thinking about is with something like Ghostty is I want it to be sustainable long term, but that's a really high bar. So in the short term, is there a way you know, biz outside of me, I should say, should be sustainable outside of me.
Yeah. Yeah.
And, in the short term, is there a way for me to at least you know, there's a few sort of core type contributors. Is there a way for me to allow them to bill a certain number of hours at a certain rate per month? It's certainly not a living wage. It's not enough to be sustainable for them. But it's a show of appreciation and compensation for their time.
You know, the the best description I've heard is that, a lot of the people that that do this sort of contribution are, older, have kids, and every hour they spend of every day is a trade off between who they spend it with and what they're doing. And and if they could convince their partner or something that, hey, I spend I spend a couple hours playing around with this project every night. But Yeah. At least, you know, it's
it's It's a vacation.
Allowing us to do this. Yeah. It's not total free time. Right? Like, I'm not totally just, like, giving away my time.
That's I I'm sort of more interested in that bar to get started because I think it's applicable to so many more projects. I think the sustainability bar is critical for projects like, I don't know, you know, like the kernel, FFmpeg, cURL, these core, core, core technologies. But there's so many non core open source projects out there that I can't foresee somebody being paid a competitive salary, even one person to work on it full time, that I'd rather just show appreciation.
Yeah. True. Because it's like, when you actually think about where you draw the line on that, it's like, could be so many projects.
Yeah. Yeah.
Okay. And then, so on Ghostty as well, so one of the things that you've written a lot about is, like, kind of how you take on large technical projects. And you wrote this really interesting article about like how you do it, because speaking from my own experience, it can be really easy to just get like, you as soon as you start thinking about it too much, like, it could be easy to just like get either get overwhelmed or start it and then like never really get anywhere with it, throw it away, that sort of thing. And your your article is really interesting.
Yeah. That's that's you know, for me, it comes from personal experience where one thing I learned really quickly about myself when I was a teenager was that if I took on too big of a challenge, that I would become demotivated, and never complete it. Or the the inverse is actually what I what I realized more. The inverse was that I realized when I achieved something, I got a huge amount of satisfaction in that. Call it a dopamine hit or whatever you want, but I got a huge amount of satisfaction in that.
So I started thinking, what if I broke down my projects better so that I had multiple moments where I was having that sort of achievement moment where I would feel feel happy and and it would push me to the next thing, push me to the next thing. And And so what I what I tried to write about is I feel like a lot of people, yeah, look at look at large projects like a large one. Like, take a browser, a web browser, for example, and think that they can never do it. Like, it's it's an unachievable thing that somehow somehow someone has done. And and to me, I I've taken the opposite approach.
I look at something like a web browser and I think it's made by people. I'm people, so I could do it. Right? Like, that's how I look at things. And not just I don't look at that just with tech.
I look at that with, like, a desk. When I look at a desk, I'm like, you know, that was made by a person, and I'm a person, so I could build a desk. Like, everything is sort of that sort of pattern. And it just, You can't make it easily. It's gonna require effort and time and learning and things like that, but you could do it.
And so I wrote that, from a technical perspective since that's where my expertise is, is how I break down these large projects in order to make them tractable for anybody to achieve.
Yeah. And I I think there was some kind of, like, practical interesting parts about it as well. Like, you're talking about, like, maybe writing tests, and stuff like that, at the beginning.
Yeah. There's all sorts of of things. I mean, I think the the the most important thing in terms of these instant gratification is get something get something that you could iterate on as quickly as possible. So for me, it's like get the project compiling, get the test working, and then write something that breaks it. And the point isn't to make something work.
The point is to make something break to show that you're you're influencing it in some way. And then from there, you know that you're in it. You're making change. You're making something happen. At the moment, you're making a crash or something.
But you're making something happen. And then you could go from there. And web browsers are still very intimidating. But in my experience working on the terminal emulator, my biggest source of education was probably reading the Chrome and Firefox source code because they are sort of the they've solved all of the text rendering problems that terminal has to solve. And so anytime a text rendering problem came up, the first place I would go was the browsers because they're cross platform.
They render text in every imaginable configuration. So yeah.
Yeah. And do you have, like, any kind of, I don't know, tips on, like, getting into those kind of, like, really big projects? I I think you've spoken about contributing to them, your process.
I mean, it matters what you're trying to get into. If you're just trying to learn how they work, then then I think my blog post kinda covers it well. And I don't I don't know if we need to get into that detail. But if you're trying to contribute, I think it's a higher bar. So I would say focus on understanding something.
I guess a tip is that you don't need to understand everything if you want to contribute. That is something I see people get caught up on. With a project like a browser, I'm not sure how many people in the world understand the entire Chromium source code. It could be a zero. I suspect it's less than 10.
But that's the thing, is you're not gonna probably be one of those 10 without spending years and years on the project. So if you're trying to fix in any project, if you're trying to fix a bug that's in a certain subsystem of the project, then just learn just enough to understand that subsystem, and then make the contribution. I think when I in my experience as an open source maintainer, I sort of view part of my job in patch review is understanding the larger ramifications of a localized patch. So when someone comes and says, hey, I made this feature work, and I look at it and you know, it's my job to say, you did make the feature work, but you're gonna break these other three things that you didn't think about. And also, like, our roadmap has a conflicting feature on it.
You know, it's like, it's my job to have the bigger scope than a contributor. I would say don't I would recommend don't worry about that so much. But on the flip side, don't take too much offense if, you know, your patch gets rejected because you didn't have the bigger picture.
Yeah. Yeah. How how have you, with Ghost Deep in kind of, like, thinking about, like, the big picture of, like, what you're trying to build and kinda making, I guess, the branching decisions, especially?
Yeah. I mean, there's, I think I've tried to I've tried to document our important design decisions online so that people could understand our trade offs of what we find important and what we don't find important. I've tried to document a little bit of the roadmap with the idea behind libghost c, which is an embeddable, version of a terminal. And I think, you know, with that in mind, I look at I look at pull requests or I look at feature requests and, issues with with that in mind. So I think a a good example is there's a lot of people that have some sort of angst that Ghost uses GTK on Linux.
And because it uses GTK, it doesn't look quite right on cute based platforms like KDE. You know, there's a certain amount we could do to make that better, and we're trying to make that better. But also, if you read sort of our intentions and our goals, then I think that that's you know, something where I'm not sure it's in scope for what Ghostty is trying to achieve. But it's it's a % in scope for what libghostty is trying to achieve. So, like, there is an answer.
It just may not be the one you wanna hear, but I think that's that's how I think about it. That's my job for this project. And, yeah, it's I I think that's the hardest part about open source in general, on both sides. When you're a when you're a user, you just want everything your way. And when you're a maintainer, you it it sucks to say no to things. But, you know and people give you shit for saying no to things, but you you can't say yes to everything.
Yeah. Yeah. Is there is there, like, any kinda good ways to say no? I guess it's just talking about the bigger you mentioned there about, like, oh, at least talking about Lip Ghostty for instance.
Yeah. I think, what I try to do is I try to show appreciation for them engaging in whatever way they've engaged. And then, and then offer an alternative option. You know, I that's I think that's the best I could do. That sometimes reacts in a negative way.
Depending how negative it is, I'll, you know, I'll either shut them down or, you know, disengage. My my my view on sort of negative interactions is that I do genuinely try to engage. I I try to engage genuinely with everybody, even if it's critical feedback. But if if the feedback reaches a point where, you know, you're being rude about it, then I'm a start playing with you too. Like, I'm I'm gonna I'm gonna start having fun with this too.
So, that's sort of, like, how I go about things. And that's a little bit different. Because when I worked for a business, when I did my company, I would never do that because because you sort of have corporate interests and financial interests. But, like, I'm literally doing this project for fun. So, you know, if someone if someone wants to disagree with me, awesome.
I I love talking to people like that. But if someone wants to disagree with me and then call names or say something, yeah, say something rude or insulting, then then that's the game we're gonna start playing. So that that's how I how I play.
That's so funny. Yeah. I really thought you were gonna say, like, I'll disengage. But you're like, no. I'm I'm coming back. Let's just play around.
Yeah. Like, let's just I just it it the the the yeah. It just turns into a game at that point. It's not it's not we're like, okay. Because the I think the more concrete thing here is if they're not being genuine in their interest in making something better
Yeah.
Then then it's not the end goal is that they're just trying to be rude. Like, they're being mean for the sake of being mean at this point. They're not being mean for the sake of getting something out of it. And so, those people, you know, I have I have sort of enough experience through through my my career, dealing with people like that. But I know that it's sort of nonrecoverable at that point, so I might as well just have fun with it.
Yeah. Yeah. Yeah. That's that's very cool. You mentioned libghostty a little bit. I I thought it's kind of interesting you I mean, you talk in your docs that, like, Ghostty is like a a reference Mhmm. Project that uses libghostty
Yeah.
Which I thought was really interesting.
Yeah. I I that's exactly right. I I think right now, a lot of people who care talk about Ghostty. But I think that long term, Ghostty becomes so much less important and becomes almost just a demo of what LibGosi is capable of. Lib, Libgo see is not vaporware.
It's, the macOS Ghostty app today is literally a Libgo see consumer. The macOS app is a Xcode project. The main entry point is Swift. It's It's a lot of lines of Swift, and we interact with Ghostty through a CAPI. Ghostty is written in Zig, but we interact with it through a CAPI.
We compile and link a static Libghostty library. It's fully Libghostty. Yeah, the idea is basically that there's so much work in building a good user experience on the front end that, we should allow people building terminal like functionality to focus on that aspect of it and not have to reinvent the wheel for the core part. And then the secondary benefit, but equally important, secondary but equally important, is that it makes the feature support of terminals everywhere much more rich, if if GoSee continues to be, very feature rich and and implement all the modern specifications and and things like that. So, I think a really, sort of good example of that that's out of scope for something like Ghostty, but but a great use case for libghostty is like iOS type stuff or or Android too to a certain extent.
But, like, for example, on iOS, no one's working full time in iOS. You're not editing, you know, code that much in iOS. What people really use iOS terminals for are SSH clients. Quickly getting things done through SSH, not spending a ton of time in it. That's the predominant use case.
And so, you really want to focus on making that SSH experience really good for people. So, you know, you save credentials. You save computer addresses. In one click, you're SSH'd in, keep the connection open in the background, all that sort of stuff. Right?
And that's stuff that I don't want to solve with Ghostty That's stuff I don't want to build into the desktop applications because it's not that important. But it's a lot of work. And so for someone to have to do that plus build a full terminal emulator is asking a lot. So if I could give them the terminal emulator and then you could spend, like, 95% of your time actually building the front end, then I think terminals are going to be better for everyone.
Right now, the way it works is there are a few SSH terminals on iOS. And honestly, the core terminal emulation is fairly antiquated or feature poor, I would say. You get SSH. You get things like running commands. You do get Vim to a certain extent. But any advanced features, you don't really get. And it sort of sucks that you have to make that trade off. So yeah.
Yeah. Well, like, I'm actually struggling to even imagine, like, using Verint, an iPhone.
Yeah. No. On an iPhone, I don't think anyone is, but I know there's a lot of people,
Okay. I found
Yeah.
There's a
lot of people that use an iPad with a keyboard to to to I don't know how much they're they're working, but to do some stuff.
Yeah. That that makes sense. And do I guess it's like do you it's almost like it's dogfooding in a sense. Right? Like, I guess you you if you'd have just set out to build libghostty, it probably wouldn't be as good as it is because you're facing all these, like Yeah. Difficulties head on.
Yeah. Yeah. So I'm learning dog fooding is a really important part. The other part is sort of the chicken and egg platform problem. You know, one of the biggest parts about building, a platform is that you a platform is only as good as the things that build on top of it.
You know, if you if if I built if I built Libgozi and launched Libgozi and nobody ever used Libgozi, then, you know, it might have been valuable for me to learn. I learned something. I had fun doing it. But ultimately, at the end of the day, it provided no value beyond that. Right?
Like, it just it its existence had zero effect on anybody besides myself. And that could be fine. Like, for for me, that's actually pretty satisfactory. But, I hope that Ghostty could do more than that. And so libghostty for me, GoSee the applications, the reference implementations are not just dogfooding, but it's also getting people interested in the capabilities of what this thing could do and and hopefully inspiring them to to use Libgosi versus something else.
Yeah. Yeah. It's it's very, very cool. Yeah. Mitchell, I'd I I didn't put it down there, but one of the things I was thinking is it would be interesting to ask you about I know this is, like, almost cliche, but AI stuff just because it's the thing that everyone is thinking about, like, the kind of future of programming.
And I just wondered if you would be interested in, like, talking a little bit about, like, how you see things kind of, like, the role of programmers in the future and kind of, like,
that's a that's a really big question. And I Yes. I don't know if I'm an expert enough to answer that whole thing. I'm I'm happy to share my personal opinion.
Well, yeah. Yeah. I guess maybe it's like one part of it is like why you're working on Ghostty and it's like a it's it's not like a, you know, like a at least it's it's not like an AI kind of project, I guess. It's like Yeah. In that sense, it's, like, kind of interesting.
Yeah. I think I think there's more than enough people working on AI. I, I think it's it's quite saturated. But, it's also just where my interests lie. I'm just I'm I'm a happy consumer of AI tooling.
Yeah. But I really have zero interest in in learning more about or pursuing AI as a developer. To the point where even with Go see, you know, I've I've said that I think AI does have a big part to play in terminal interactions. But I wanna enable that through plugins rather than me building it myself. Part of that is right now, it's moving so fast.
And people have such strong opinions about whether they like it or not, but whether also between what sort of AI, tooling they wanna use that I hope that a a plug in system will help give them ultimate choice about that. But another part of it is I don't wanna work on it. So, yeah, that's that's sort of part of it. It's just it's it's like I think it it's very consistent. It's just chasing chasing fun.
Yeah. Okay. Yeah. That makes total sense. And, like, do you have a do you have a view on, like, if people are still gonna be, like, you know, hiring programmers in X amount of years and stuff like that?
Yeah. I mean, I think that my opinion on that is that I you know, I'm not a historian, but at all. But it just seems like there's never been any sort of productivity tool that has resulted in less work to do. I feel like as people become more efficient at one thing, they either invent or discover other things to now spend their time working on. And, and but the flip side of that is that innovation definitely kills the need for specific types of roles.
So for example, like, if you moved from from coal based energy to nuclear energy, then obviously mining coal is no longer a job that exists. And that that's fine. I mean, that's that's important to understand because I think in the context of AI, my view is I think AI will do a lot more tasks for what programmers do today. And so the job doing those tasks will disappear. But the need for engineering mindsets in other categories will only increase.
So it's more about thinking, not my job is gone, but what does my job change into so that I could become that next person? And so
Yeah.
Yeah. I mean, AI today is not there. Right? But who knows? I mean, it's it's already I've never been an AI doomer. I'm I'm not an AI hype man either. I I I think it's valuable. I I think it's I think it's I think it every programmer should be using AI tooling today, is my opinion. I think I think it's extremely suspicious when a good engineer any engineer I mean, I think I think it's extremely suspicious when any software engineer says, oh, I don't use AI tooling. I just think it's like, why?
Like, it it it it just helps. It just helps. And so Yeah. It's not a panic. And then I the the usual reaction I get from those people is that they tried it and they tried to make it write a program and it was totally dumb. And it's so extreme. You don't need to have AI be this artificial general intelligence. AI to me right now is a very valuable auto complete, but I'm still doing a lot of creative work. And so that to me is is why it's worth it. But yeah.
Yeah. What what tools are you using, by the way?
A mixture of Copilot and, ChatGPT and and Claude Okay. Are my go tos. Yeah. I mean, I I I'm still I think I know enough about AI to be extremely suspicious of it. But in every single scenario, AI is my first line of action.
So if if if I have a someone opens an issue and says, can you do this? You know, I'll try to think of concrete example. Like, can you make the underlines in text, like, split the descenders of, like, wise or something? The first thing I'm gonna do is just go ask Claude or Chad GPT and just say, give in. I have a text renderer with these features, and I wanna do this.
How would you solve it? And, like, kinda have a conversation with it. It's gonna generate a lot of garbage, but it's gonna what it does for me is it starts giving me direction to start doing more trustworthy research on. And so, yeah, it solves a lot of problems. Sometimes you get really lucky.
There's a there's a feature in Ghostty where you could customize the macOS icon. And that code was almost completely generated by chat g p t. It was totally broken, but it got the core ideas all right. And so I just had to, like, fix the API as it didn't exist that it was calling and and make them real APIs. But the actual like order and what it was the image manipulation algorithms that it was using and everything like that was all right.
So, the macOS icon customization was never supposed to make it in for one point. O. I think I got the layers for that, like, five days before the one point o release. And I was like, I'm never gonna do it. And I was able to build that feature in four hours because ChatGPT spit out, like, 200 lines of Swift that every single line didn't compile, but every single line was directionally right.
And I just had to like fix up each line to compile. And as I got it to compile it, it worked. And I was like, well, I guess that makes it. Right? Like, I I think that is the strongest example of something saving me. It probably saved me, like, a few days worth of work. Wow. Yeah.
That is super cool. That is super cool.
Yeah.
Are there any other, developer tools that you're excited about right now? Not not necessarily AI.
I I mean, I think it's in the bubble that I'm in, but I'm super excited about the the sort of, I don't know, start the swell of editor innovation that's happening again. It's certainly not mainstream yet, but, you know, there's a there's a venture backed company out there called Zed, building a text editor that I think is really interesting. There's open source projects like Helix that are, you know, not a company that are working on new editors. There's there's others. But I just think all that stuff is we're in the in my opinion, we're in the dystopian homogeneity of Visual Studio Code right now.
And it's it feels bad to me. I think it's a pretty subpar tool. And so, you know, it's yeah. I I'm just excited for people to just explore and see what can what can an editor be again.
Very cool. To make it fun again.
Yeah. Maybe. I mean, even if even if we decide at the end of it that, no, actually, Versus Code is is the best tool for most people, that's fine. I just the thing that bothers me the most is when stuff happens and and so no one basically, all innovation stops in that thing because one mega player emerges. Like, that's the saddest thing to me because it's the unknowns that that bother me the most. It's like the what ifs. Yeah.
Yeah. I guess the extensions and stuff like that kind of locked it in a little bit.
Yeah. Yeah. Yeah. That ecosystem, that's always the that's the play. That's always the
play. What what text that it's a do you use, actually?
I use Neovim. I've been a I've been a Vim user for for a long time. And, yeah, I I I I I think I tweeted this actually. But I I, you know, they're they're gonna have to pry Neovim probably from my, like, cold dead hands. But but I'm not saying everyone should use Neovim. Right? Like, I'm just super happy with it. But I can also absolutely respect and, admire the work that other editors are doing.
But now I'm suspicious if you actually use it, if you're not telling everyone to use it. Yeah. Oh, yeah. That's that's awesome. One final question, Mitchell. If you had to, like, have, like, one kind of piece of kind of, advice that you would give to short advice to, like, a founder of a dev tool, if there was, like, one thing that they should take away from your experiences?
One thing? I mean, I think it obviously, I'm so biased, but the one thing I think all I would I would give I would tell all DevTool founders to chase the chase that human experience would be the one thing. I think that it'll be your biggest marketing tool over anything else that you ever do is if someone uses your product and finds enough joy in it to talk about it to another person and figuring out what sparks that joy. And it might be that it has to work really well. It might be that it has to be really fast, whatever it is.
But that should be the driving force is to chase the human experience. And I just feel like there's so much. We've reversed back into I'm sort of pessimistic about we've reversed back into a lot of dev tooling feeling like it's more computer friendly than it is human friendly, and it's bothering me a lot.
Interesting. How would how does it become more computer friendly than human friendly?
I like, when there's when there's a concrete example, for example, is when there aren't Sane defaults for something. When the expectation of using software is that you're gonna either configure it a ton or that you're gonna specify the right 40 command line flags or the right, you know, YAML keys or whatever. Like like, I I think it really, I guess, based on my background, a really strong example for me was the rise of Kubernetes. The rise of Kubernetes really sort of, I don't know, it really kind of deflated me on the on the human experience side because Kubernetes itself as a technical project, fine. Like, it it it solves a real problem, totally fine.
But, like, the there's probably someone I'm insulting when I say this, and I'm so sorry. But, like, the complete lack of taste in the YAML description drives me crazy. And that's the biggest thing. What happens once you submit the YAML? Awesome, fun, great.
But programming YAML and, like, getting the right indentation and the right keys and, like, there were so many keys that I felt like every one of my deployments, no matter what not literally a deployment resource, but whatever I was deploying. Every one of the things I was deploying, whether it was a mail server or a website or a back end service, like, I felt like 50% of it, and probably more, but I'm really, like, softballing it. 50% of it was identical. And the fact that I had to know what those did and keep doing it and then the insult to injury for me was then introducing Jinja templating on top of YAML as a way to make them more reusable. Obviously, that's sort of a dig at Helm, but that's there's other projects that did it as well.
It just it feels bad. It just it feels that it is sort of mean, but the the best word I could use that the reason it hurts me is taste. It just feels distasteful. It's not functionally totally works fine. There's design, technical design decisions that are completely defensible, but it's sort of, yeah, it's sort of like going to a restaurant and and getting served something that saying, like, well, it's gonna make you full and it's gonna taste okay, but you gotta, like, put it together yourself.
It's like, like, come on. Like, we could do better than this. Yeah.
Yeah. I know what you mean. It's, that thinking about, like, the human, not just it does the job, but it
it Yeah. And I hope no one takes away from this that I'm perfect at this. I'm far from perfect at this. I think it's like a it's a learning experience where I've I've made and continue to make tons of mistakes. But but I think the intention behind trying to spark that joy in the human experience, it's that's more important to me. If someone tries and and fails, that's totally fine. But I just feel like there's a lack of trying right
now. Yeah. It's actually really, really interesting that I recently spoke to, Taylor Otwell, you, and Guillermo, free of, like, the most successful DevTools people. And you all said taste was, like, one of the key things. And it's,
Well, of of of the those two people that you mentioned, I think, do an excellent job. I think that they are they are leading the charge for sure, in in that category.
Mhmm. Taste is a powerful thing. Mitchell, sorry. I realize we're out of time. But, yeah, thank you so much. That was, that was really awesome. If there's I think you I guess you haven't really got anything to plug. But, if you No. Ghostty.
I I mean, if you care. If if you care. It does it's not that important to me. I mean, I think that, I'm out here trying to have fun and I hope people got something interesting out of this. Even if you disagree, I mean, I hope it was interesting and that's good for me. Thanks for having me on.