mitchellh

Yep, fun little demo: https://x.com/UzaAft/status/2093774764598817022

These are Ghostty GUI release notes, but I want to take a moment to highlight the libghostty progress we've made since Ghostty 1.3.

As a reminder, libghostty is the highly portable, embeddable library that provides core terminal emulation, render state, and more. I always felt that a free, high qualty, lightweight, reusable terminal emulation core would benefit the developer world more than any single GUI application. And that is playing out!

It is and always was my true purpose with the Ghostty project (I said this in my first ever talk about Ghostty!). I've jokingly said many times that Ghostty GUI is just a glorified tech demo for libghostty. That's not fair though, because GUI is great and there are really talented people working on it.

Since I started the project, Ghostty has always gotten people saying "I don't understand why you'd start a terminal emulator today." Well, the answer is libghostty. It's truly unique and its enabling something special (imo!).

Highlights of libghostty since 6 months ago (none of the below was true 6 months ago):

- Libghostty has nearly 100% coverage of all of Ghostty's core (and you can compile with flags to remove any of these features for size/safety): https://libghostty.tip.ghostty.org/

- Libghostty now builds and is tested (in CI) for: Apple (macOS, iOS, visionOS), Windows (MSVC and GNU), Linux, FreeBSD, Android, WebAssembly, and freestanding (i.e. direct on hardware with no OS).

- Libghostty has bindings in pretty much every popular programming language: C, Zig, Go, Swift, Python, Rust, .NET, etc.

- Libghostty's memory requirements have dramatically shrunk to enable the portability above. There's still work to do but a single empty terminal now takes 90% less memory. And at scale I've proven 10,000 active (input/output happening) terminals on a Linux server with 4 cores and 8 GB of RAM.

- Libghostty powers all JetBrains IDE terminals, over 12.5 million active users. https://blog.jetbrains.com/platform/2026/10/jetbrains-termin...

- Libghostty is the most popular core behind the wave of venture-backed "agentic" terminals and editors, such as Herdr, cmux, and many others.

- Libghostty is being discussed and has been verbally accepted to replace the terminal core in Neovim: https://github.com/neovim/neovim/pull/39773 (work still to be done)

- Libghostty powers a really popular and powerful terminal emulator for emacs (Ghostel): https://github.com/dakra/ghostel

- Libghostty's speed is used by Antithesis to fuzz popular terminal programs and has directly led to hundreds of bug fixes sent upstream to programs such as tmux, btop, shells, and other terminal emulators. :)

- And so much more: https://github.com/Uzaaft/awesome-libghostty

Libghostty is really successfully turning into the tide that raises all boats. As it becomes more popular, Ghostty itself gets more performant and stable, and so does everyone else. It is also a vehicle for delivering modern terminal emulation to the widest source possible.

I plan on tagging libghostty 1.0 in the next few months and declaring ABI stability at that point!

The distinction between those semantics died a long time ago by others I'm sorry to say, and I'm continuing to persist that.

APC is far less supported overall by terminals (for example, Terminal.app on macOS would simply dump APC to the screen, ignore the framing, and treat the APC data as normal pty data, and Terminal.app is used by a LOT of people). Plus, its anything-goes format makes it hard to ship safe protocols that overlap with others (APC was always meant afaik for _one_ protocol -- the application's, not multiplexing many).

Compare this to OSC which is well supported, has a well defined multiplexing format (the first number), and has a well defined framing that all terminals I know of ignore for unknown values. That's perfect.

As the Arcan project so eloquently stated[1]: "Terminal emulators emulate a machine that has never existed, a fantasy computer." More details in the link by people I respect who have worked on this problem far longer than I have.

[1]: https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...

Creator of Ghostty here.

We run on a 6 month release cycle as noted in our release notes. The 1.4 release was scheduled for the last week of September (~a week ago), but it had to be pushed to October due to personal family travel as well as some lagging localization PRs. After we release in October, there won't be another release until March.

I'm actually working on the 1.4 changelog right now and I put out a call for help for the translations yesterday on X. The only risk now is that my 3 year old became very sick today and my wife is out of town, so I'm solo parent and that's now impacting things.

There's been literally over a thousand changes on main between March and today and if you look at our commit history we're extremely active with commits almost every day. So I'm not sure what anyone is trying to imply by sharing this with this title, but please don't read into it in any weird way.

Creator of Ghostty here. Always a fan of new terminals. I noticed your benchmarks are against Ghostty 1.3.1, which is fair, since its the latest released, but our IO throughputs in particularly the areas you tested have improved by more than double on some machines, so if you get a chance, I would ask you rebenchmark on `main`.

I don't know if it'd be faster than your terminal or not, but it'd be significantly faster than 1.3.1. On my M4 MacBook Pro, ASCII processing improved by about 2.8x, if that holds in your benchmarks, it would be faster than shitty. But, who knows. I'd prefer you ran it yourself.

No idea

> Good news is that modern compilers are more than capable of emitting SIMD code even if original source is nothing but.

They're really not (I have a whole section on it in the blog post). This example in the post doesn't auto-vectorize, for example. And its a pretty big part of the overall throughput for plain text runs (ascii or unicode). Really, the point of that section is that almost nothing auto-vectorizes, backed up by LLVM docs and published research.

Instead, writing 12 lines for a 5x gain is way easier than crossing your fingers and hope someone else pays your bills.

Bigger picture, the real point is that this stuff isn't complicated. You wouldn't copy and paste 100 lines because you hope the compiler "lifts this into a for loop", you just write the for loop cause you know how and its simple.

Similarly, the common case of "process N values in parallel" is very simple. Write a dozen lines of code you're comfortable with. No need to pray the compiler people saved your bacon.

> i've found that zig tends to extend my vectors to the native width of the platform and then operate on them there

oh interesting. though i suspect that isn't zig and thats llvm.

> mitchell, i know you hang around some of these comments sometimes

hi im here

> i noticed that in ghostty you bring in some c++ libs to do the simd heavy lifting for you. any plans to port that to zig? anything missing from the language or libs that's preventing it?

No plans to port it. For others, this is referencing highway: https://github.com/google/highway

The major limitation of Zig's vectors is that they're compile-time only. So if you're building redistributed software that compiles for a baseline CPU target, it won't be as optimized as it could be for YOUR possible machine.

Highway compiles our SIMD modules for different hardware configurations and at startup does a CPUID fingerprint to figure out which to load. That way even baseline has AVX512 etc. implementations, and we just activate the right one at runtime.

We only use Highway for our hottest hot paths that we feel benefit from that specialization.

No plans to port that (although, I spent hundreds of dollars and slop-forked it into Zig with the help of this good boy GPT and it worked great actually, but I didn't want to maintain it).

Case-in-point, the example in my own post doesn't auto-vectorize with LLVM or GCC at highest optimization levels. Basically, compilers will never auto-vectorize loops with an early loop break afaik.

> If you assume Hashimotos net worth is one billion dollars, a $400k donation is equivalent to a $400 donation if your net worth is one million dollars.

1. Net worth is significantly less than that (taxes + heavy philanthropy)

2. $400K donation is orders (plural) of magnitude off our actual philanthropic giving in total. This is just one donation.

> How is it out of touch? I donated much more than Hashimoto did relative to our net worths, but I cannot deny that I would have felt much more satisfied making a 1000x impact if I was a billionaire.

You have no way of possibly knowing this. And I bet you its not true.

I'm no longer a billionaire, partially because I paid an astronomical amount in taxes (I don't play the tax avoidance games). And partially because we're donating a whole lot more than $400K per year. This is ONE donation. We don't publicize most of our giving because it attracts armchair critics like you, and its distracting from the goals.

(I make an exception for Zig and technical things because my influence for better and worse usually is net positive for the initiative)

But, more importantly, I don't think playing these "my donation is worth more than yours" games is productive. If you want to think that way thats fine, I won't defend myself or my family any further than this post.

I'm the creator of Ghostty. This isn't right. It should idle at 0 to 1%, as supported by sibling comments. If you can collect more details about your system please open a discussion on the main Ghostty repo. Same with memory.

In terms of speed, same thing: if you can provide some kind of objectively measurable thing, we can look into it. Everything we've measured so far firmly places Ghostty in the "fast" camp (with friends such as Kitty).

We're sometimes faster, sometimes slower, but in any case not noticeably so. You wouldn't pick Ghostty vs Kitty for example for performance, it'd be something else. But you would pick Ghostty over say... iTerm2 for performance (but you may pick iTerm2 for features, its extremely feature rich!).

probably just been long enough that he doesn't give a shit

source: most of the bullshit i surface up nowadays

As with all things, the horror stories just get the most attention. People love to rage. There are plenty of boring (good, even!) VCs out there. They just work more quietly, professionally.

I'll share a story, but its about a close friend and not me so I won't name any explicit actors and I'm going to round out the numbers. You either trust me or you don't, but this is a very direct relationship I have to both the founder and VC.

The story is this: the founder started their company outside of SV, so the lawyers weren't super familiar with startups and messed up the initial incorporation and stock plan stuff (actually super common: use Stripe Atlas or pay a startup-aware lawyer!). Went under the radar through years. This company ended up being bought for nearly $1B (with a B) after many rounds and a large board.

During the legal work to close the acquisition, they found out this messed up stock plan. Without going into the details, the effect was that instead of taking home $200M, the founder would take home ~$75M. The mistake the lawyer made almost a decade earlier was about to cost him $125M.

Most of the board basically said "too bad so sad, law is law." But one VC (the one I know, the one I'm talking about) basically strong armed and politicked the whole thing and eventually convinced everyone around the table to give up an equal share of their own holdings to make the founder whole.

Letter to the law: they didn't have to.

Spirit of being founder friendly: this VC went to bat hard and got everyone to yield to make things "right."

Also, look, you might argue $75M vs $200M is just "rich vs rich." Who cares? Sure. That's not the point.

You don't hear about stuff like this because honestly its not a big enough deal and feel good stories get way less clicks than pitchfork stories.

Correct. I use AI a ton and I'm having more fun every day than I ever did before thanks to it (on average, highs are higher, lows are lower). Your characterization is all very accurate. Thank you.

Here's some other topics I've written on it:

- https://mitchellh.com/writing/my-ai-adoption-journey

- https://mitchellh.com/writing/building-block-economy

- https://mitchellh.com/writing/simdutf-no-libcxx (complex change thanks to AI, shows how I approach it rationally)

Yep!

To be more specific, Open Source only promises the four fundamental freedoms (https://en.wikipedia.org/wiki/The_Free_Software_Definition).

It promises literally NOTHING else, including zero cost. Free and open source software can and should cost money! (The "free" in "free and open source" is not about money, people!)

I'm actually very enthusiastic about these OSS "supply chain" attacks that have been happening in various communities. Because optimistically I hope it'll help people realize that OSS _is not a supply chain_ (more details here: https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...). Unless you're paying your vendor AND/OR have a contract in place with them with certain guarantees, you do not have a supply chain.

One term thats in almost every FOSS license is "this software is provided with no warranty." A supply chain implies a warranty. Therefore, FOSS is not a supply chain.

I know this is ridiculously dramatic, but its the truth: I actually cried writing this blog post (tears hit my keyboard, I'm embarrassed to say).

Nobody should cry over a SaaS, of all things. But GitHub has meant so much more to me than that (all laid out in the post). I have an unhealthy relationship with it. Its given me so much and I'm so thankful for it. But, it's not what it used to be. I don't know.

We've been discussing it off and on for months, really started seriously discussing it a couple weeks ago, and made the final decision a few days ago. Putting metaphorical pen to paper and hitting "publish" makes it so very real.

I'm sure folks will make fun of me for this. It is a stupid thing. But I truly love GitHub, and I hope they find their way.

Of most things, really, he was on Jeopardy for a reason! https://thejeopardyfan.com/tag/ted-nyman

Cmd+F "Kubernetes".

Oh Jesus Christ.

Well, I originally used C23's #embed directive (https://en.cppreference.com/w/c/preprocessor/embed) but GCC in Nixpkgs doesn't support C23 (or I'm holding it wrong) so I dropped back to this. The better long term solution is #embed.

Just noting that Ghostty shows a preview in the bottom corners just like a browser.

Im touched that “Ghostty but for X” is a marketing point but what does it mean in this case? I thought this might be based on the architecture I did for Ghostty. But it’s not. Or it might be full native UI, but it’s not (it’s GPUI). Not trying to be rude or unappreciative but as the creator of Ghostty here… what do you mean?

I'm not concerned with it.

The real goal isn't for Alacrity or Kitty or WezTerm or any other terminal to use libghostty. I think over the long term, terminal emulator user bases dwindle down to niche (but important) use cases.

The real goal is for higher-level tooling (GUI or browser) that utilizes terminal-like programs to have something like libghostty to reach for. I think this represents the much, much larger ecosystem out there that likely touches many more people. For example, Neovim's terminal mode, terminal multiplexers, PaaS build systems, agentic tooling, etc. You're seeing this emerge in force already with the awesome-libghostty repo.

libghostty would still be useful for traditional terminal emulators to replatform on, and for example xterm.js is seriously looking into it (and I'm happy to help and even offered their maintainer a maintainer spot on libghostty). But, they're not the goal. And if fragile egos hold people back, it's really not my problem, it's theirs.

Probably not. I don't know. Who cares.

Not at all. Give it tools and skills and it figures it out very quickly. Must be an agent. Don't use chat.

Yes, LLMs with Zig are absolutely useless without agentic behaviors. Throw an agent in the mix and it's totally fine. Bonus points if you pair it with some basic agent skills so it knows how to look up language references, stdlib files, etc. then it does even better.

New stable release in 1 to 2 weeks.

It's been extremely good. I should really blog about it in more detail because I do get asked this question regularly. It's been very good.

The large language changes are a burden, but it's something I knew going into it. And so far in every case, it's been well worth it. For example, 0.15 introduced the std.Io.Writer overhaul, but I really love the new API. I haven't started the std.Io change yet for 0.16. We'll see. And honestly, LLMs make this all way less painful... even though they're not trained on it, agents are able to run builds, reference docs, and work their way through the upgrade with huge success.

I thought that finding contributors would be an issue, but it hasn't at all. There's a lot of people out there eager to use Zig, the language isn't hard to learn (as long as you're already familiar with systems concepts), etc. It has been good.

I'll think about more to say if I write about this more but overall, I'm very happy with the language, the community, and the leadership. All good.

Overall I would describe it as "amusing."

If you told me 3 years ago that terminal usage would _increase_ I would've laughed. Beyond that, I'm now having regular conversations with the frontier agentic coding companies (since they're far and away the largest terminal users at the moment) and if you had told me 2 years ago that that would be happening because of a terminal, I would've laughed even harder.

So, it's amazing. But overall, its amusing.