Awesome to see! Let's replace the Alacritty core with libghostty-rs. If there are any shortcomings in the libghostty API I'll address them immediately. I know some view Ghostty as competitive to Warp at a GUI level, but the goal was always to empower other terminal apps via libghostty and there was no other vehicle to get that out than to build a GUI too (similar to Alacritty and their vte crate). I don't think I've ever talked negatively about Warp online (except maybe the login thing they fixed ages ago), I've always respected that they're trying something different. I know Warp has moved on to being a much bigger vision than "just" a terminal, but let's modernize that terminal core. :) https://t.co/9IZZch7FSm

Had to denounce one person because they had a really low quality AI generated avatar. If their AI generated avatar is bad, their AI generated code is surely bad. No shirt, no shoes, no service, buddy.

Observations from writing Go again, exacerbated by agents but not unique to them. First, its far too easy to allocate and agents (probably people too) do it too often. For example, to "undo" work on error, its enticing to keep track of the work done but that's a mistake. If an error case is rare (and they usually are), you should pessimize the error case and optimize the success case. Don't allocate unnecessarily on the happy path if its going to succeed 99+% of the time. Let the error case be slower. On error, just redo the work but do the undo step instead of the apply step. This doesn't work if the apply step had a ton of side effects but it works more often than you think. Real world example of that not in Go, but the Zig compiler: when it parses, it doesn't store any file/line/col info, because its a waste of memory when parsing succeeds most of the time. And memory is speed in modern CPUs since cache locality owns everything around us. If an error happens, Zig just reparses the file from the beginning in a slow path that does collect error information. That pattern is generally useful.

Simdutf released v9 which includes the ability to use it without libc++ at runtime (via a cleanup of my work). Really glad I could help get this upstream, a big win for all libghostty-vt users as we eliminate a major dependency for free. https://github.com/simdutf/simdutf/pull/962

As @fat once told me, "you know its serious when @mitchellh starts putting markdown in the commit messages." And I think of that moment everytime I write markdown in some commit messages and nod my head.

I’m excited about the AllBirds AI pivot because this is the first completely pure act of retardmaxxing in the public markets and I’m so on board with watching that journey play out.

I've contributed a patch to the venerable simdutf library by @lemire so that it can now be used with no dependency on libc++ at all. Libghostty is already updated so it now only depends on libc. I blogged about it here: https://mitchellh.com/writing/simdutf-no-libcxx

Traded in my 2020 Model S for a brand new plaid X before they discontinue it. Car is amazing, but the FSD hype is real. It blew away my expectations coming from the 2020 hardware. 95% of my miles are self driven in LA over the past month. I wouldn’t have even believed myself lol. Even my wife who HATED autopilot on my prior car is totally blown away. She’s asked multiple times “did you drive?” And I say “not at all.” And she’s just like… wow. Great job @Tesla for real. I’ve owned a Model S since 2013. This is my 3rd, first X (for me personally). Just fantastic.

I shook off some of the dust and wrote Go for the first time in 3 years and built some libghostty bindings for Go. Its cgo but since libghostty can be fully static and only depends on libc, mixing cgo + Zig as the C compiler lets you cross compile easily. https://github.com/mitchellh/go-libghostty

Updated the libghostty-vt CMake files to make cross-compilation as easy as one (or a few lines). Since libghostty only depends on libc/c++ and Zig bundles libc when used as a c/c++ compiler, you can get full cross-compilation easily. The Zig toolchain is paying huge dividends! This would've been true even if libghostty wasn't written in Zig, its just a fun coincidence that its written in Zig too. But Zig the C/C++ compiler on its own is amazing (a frontend for clang but with a ton of extra work done by the Zig team to make cross compilation easy). More details in this commit: https://t.co/Aq5Qprci0j

Now I understand the full picture. The cleanest fix is... But actually, the real fix simpler... Actually wait. The best fix: Now the real fix. Actually, let me reconsider. OK Key finding: Wait I need a hardware device I can physically punch to stop the agentic session.

Libghostty now fully exposes the Kitty Graphics Protocol. This may be the first native embeddable terminal to support this. I added a full Kitty graphics renderer to Ghostling (the libghostty demo project) in ~270 LoC. Ghostling PR: https://t.co/HXs9vxCgmY Ghostty GUI has supported Kitty graphics since version 1.0 and I believe we have one of the most comprehensive Kitty graphics protocol implementations besides Kitty itself. For example, we support unicode placeholders which lets the protocol work in tmux, which is -- I think -- only supported by Ghostty besides Kitty. Now this robust, real world proven implementation is available to anyone embedding Ghostty. Enable it with a few lines of code and build a renderer with a couple hundred as shown in Ghostling. Amazing.

I've been working on making the WebAssembly build of libghostty a bit more ergonomic. Here's a weird API I've never written before, but libghostty-vt now has an API to dump its exported structs as JSON with size/alignment/type info to help bindings: https://t.co/e4uMJFeiiz The data is generated at compile-time and stored in read-only memory so you're not paying any runtime cost to generate this and libghostty itself doesn't need to embed any kind of machinery to encode JSON. The `example/wasm-vt` example in the Ghostty project shows how its used: we call this after loading libghostty, decode and cache the data, and then use it with some helpers to set struct fields by byte offset. This is necessary because WebAssembly doesn't have a formal struct system. And we don't want to expose a bunch of functions we have to promise ABI compatibility for.

Had a wonderful evening last night reuniting with so many early HashiCorp folks! It was a great moment to share memories and be grateful for the experiences we all shared, the highs and lows!

libghostty for Rust! Some Ghostty maintainers came together and made a really high quality Rust crate in front of libghostty-vt. The repo includes a full port of Ghostling (full terminal in a single Rust file!). The API is beautiful. https://github.com/Uzaaft/libghostty-rs/

Here’s what I’d do if I was in charge of GitHub, in order: 1. Establish a North Star plan around being critical infrastructure for agentic code lifecycles and determine a set of ways to measure that. 2. Fire everyone who works on or advocates for copilot and shut it down. It’s not about the people, Im sure theres many talented people, youre just working at the wrong company. 3. Buy Pierre and launch agentic repo hosting as the first agentic product. Repos would be separate from the legacy web product to start since they’re likely burdened with legacy cross product interactions. 4. Re-evaluate all product lines and initiatives against the new North Star. I suspect 50% get cut (to make room for different ones). The big idea is all agentic interactions should critically rely on GitHub APIs. Code review should be agentic but the labs should be building that into GH (not bolted in through GHA like today, real first class platform primitives). GH should absolutely launch an agent chat primitive, agent mailboxes are obviously good. Etc. GH should be a platform and not an agent itself. This is going to be very obviously lacking since I only have external ideas to work off of and have no idea how GitHub internals are working, what their KPIs are or what North Star they define, etc. But, with imperfect information, this is what I’d do.

Every. single. day. It's increasingly becoming difficult to do real work with GitHub. Git isn't the issue, since I can work offline. Its issues, PRs, CI, etc. Imagine going to work and your workstation randomly restarts a few times a day. That's what it feels like using GH.

Big day for Windows + libghostty-vt: - We now run the full unit tests on Windows in CI - We now build libghostty-vt in CI - We fixed a ton of issues related to MSVC with libghostty-vt - CMake now supports building libghostty-vt as a static lib on Windows

I think the funniest recent interaction was standing in line for coffee in SF and someone stops and goes "WAIT. WAIT HERE." (no other context yet). I'm in line so I'm not going anywhere. He runs back with his open laptop to show me Ghostty riced the fuck out. It was beautiful.

Funny, but when someone recognizes me in public, I can guess with really high accuracy what they recognize me for based on their perceived age. Young people: "you're the Ghostty guy", older people: "Terraform guy". I get stopped in public more often these days for Ghostty.

Ghostty just surpassed Terraform in stars (my previous most-starred project I started). It took Terraform 12 years to reach 48K. Ghostty did it in 1 year. It's bigger than Terraform in active usage, too. I take it personally when people doubt I can outdo my past. I can take credit for starting both, but not for ongoing development (for the successes and failures). Neither project is a solo endeavor. I'm still extremely actively involved with Ghostty, but there's also a team of a dozen maintainers. Terraform I stepped back and stopped working on it directly like 6 or more years ago. I consider stars a vanity metric and I don't care about it at all except in this narrow case. I'm a super competitive person (in general), but particularly/especially against my past self. There's no one I like "winning" more against than my past. So, this is my one exception for caring about stars.

Btw, for Ghostling (libghostty demo), I didn't write a single line of... anything. Agents wrote 100% of everything you see incl. Nix flakes, CI jobs, etc. I reviewed every line of code manually and constantly nudged the agents in the right direction. I used a mix of Opus+Codex. Note: libghostty itself is of course heavily hand written (with agent assistance all over too, though). I'm just talking about Ghostling itself. Even for CI setup (GitHub actions), I had the agent sit in a `gh` CLI loop watching failures, fixing, pushing, fixing, pushing, etc. Doing GHA with agents are the only way I stay sane, honestly. I just re-read the full main.c from top to bottom and I'm very satisfied. I would've done some things differently but if an engineer I worked with PRed all this, I would've accepted it. Its good enough. Some people have pointed out the commenting is over the top and indicative of AI. This is actually my personal comment style, and I told the agent to comment heavily (its even in the AGENTS.md, look for yourself!). Anyone who has worked with me professionally or in OSS knows that I comment everything all the time.

libghostty is FAST! Here's a look at vtebench with Ghostling. Reminder: Ghostling is single threaded + blocking render + blocking IO. The point is, you get comparable speed to the fastest dedicated terminals in an embeddable lib! Had to pull out iTerm2 because its so slow. Warning: Ghostling is purple in the first chart but green in the second. Sorry for the confusion. Also, the Unicode results are not correct for Ghostling because Ghostling is getting stuck on worst case "glyph not found" since we only embed one font. So the results are wildly skewed poorly. A result integrator of libghostty would have significantly better performance here. I haven't fully profiled the libghostty C API yet. I think there will be obvious wins to be had. This was just my first check and I am very happy with the results. Comparing libghostty/Ghostling to dedicated terminals is a bit unfair, since dedicated terminals can get away with a lot of performance tricks to go faster that a reusable general purpose terminal emulation library can't do as well. But, I wanted to show this comparison to show that despite that, libghostty still does SUPER well, comparable, and even best-in-class in a couple categories. This is all to say, every embedded terminal experience on earth can be nearly as fast as the fastest native desktop terminals. There are no more excuses. The tide will rise! Full Ghostling source (single ~600 line C file): https://t.co/kPJ1aPHwKi

Some huge libghostty C API updates the past couple days: almost the full terminal state is now available, the render state API for building high performance renderers is now available, and you can now integrate libghostty-vt with CMake in ~10 lines.

Excited to share that I've joined Vercel's Board of Directors. Vercel is made up of builders and tastemakers that continually ship things that deeply impact how developers work: Next.js, AI SDK, v0, etc. I can't think of a more exciting place to be. Let's fucking ship. ▲ My relationship with Vercel goes back to the earliest days. HashiCorp was an early adopter of NextJS and Vercel (~10 years ago!) and it remains my default tech stack and deployment platform to this day. Ghostty's website is all on Vercel, too! Beyond that, I've been continually impressed with the teams relentless focus on shipping meaningful software. And importantly, software that has incredible taste. Now we are in the age of agentic software development. Vercel is building agentic infrastructure that I think every app and agent will need (I certainly need it!) and I can't think of a more exciting place to be. Huge thanks to @rauchg , Jeanne, Marten, @cramforce, @tomocchino and the entire Vercel team for the warm welcome. Time to work.

It's so insanely disrespectful for an AI agent to talk to real people without consent or at least disclosure. This is the type of stuff I'm hugely supportive of government regulation. The FCC must expand the definition of robocalling and TCPA-style regulation to online AI.