What really caught my attention was this: "So from the start, I took inspiration from C libraries I enjoyed working with and designed the API to have a strong, stable ABI that allows for future additions." What are good examples of this? I feel like I just don't have enough experience with well-designed C libraries to know what to look for.
If you have structs that might need to be extended, you can use "versioned structs". One popular technique is to include the struct size as the first field. The struct size is set to `offsetof(mystruct, lastmember) + sizeof(lastmember)` and the receiver of the struct can use this to check if a member exists. The ARA API is a good example: https://github.com/Celemony/ARA_API/blob/65ec5c43b943a48cb54...
PS: FMPOV Mitchell is a relentless performance addict. I have been seeing this since the vagrant days (this also makes me sad because it reminds me I am getting old)
Can anyone give a comparison to libvte? There are many terminals that are just thin wrapper around that (gnome-terminal, xfce4-terminal, mate-terminal, lxterminal, sakura, …). It is tied to GTK, so it has a much narrower scope. But still it feels related in spirit.
libvte provides terminal emulation complete with a gtk UI.
In terms of terminal emulation, libghostty implements several protocols that libvte does not. For example kitty keyboard, kitty graphics, and desktop notification.
can i just get you people to slow down a bit and explain: why are you guys building your own terminal? whats the deep pain here?
(i'm not at all being skeptical, i respect you guys enough to understand that there's something here I don't get and it's my skill issue, so I am trying to learn)
It's like a better alternative to xterm.js, and better than existing terminal emulator libraries.
similarly, a terminal conceptually consists of a terminal engine, which handles text rendering and interaction, and then a terminal which handles tabs, splits, sessions, etc.
now one key point is that you can get a terminal engine right according to a bunch of reasonably objective criteria, so it's a problem well worth solving once and for all. the terminal itself is a lot more subjective and idiosyncratic; different people want different things out of their terminals and the reason is very often that it fits the way they work, or they enjoy some particular features, and even the absence of other features. it is wonderful that libghostty can solve the part that everyone agrees needs to be objectively correct, and lets people concentrate on building the subjective part in the way they like best.
Occasionally I'll check out other terms people rave about. Tried kitty, wezterm, and a few others a while back, but wound up coming back to iterm.
Still, really happy to see things like this gaining traction. An easy way to implement high performance terminals in any application is a boon
- Font rendering (and cell size control) is still better on iTerm2, although Ghostty has been rapidly gaining
- Compact theme with thin titlebar tabs
- Profiles
- Window arrangements
- In-terminal API (which Mitchell has acknowledged as a useful feature)
No shade to ghostty btw, it's an amazing product that I use every day. I just have to accept the lack of some of this usability polish.
https://lib.ghostty.org/vt/example-programs.html
It also looks useful for testing and developing text interfaces (TUI), like file navigator, editor, dashboard, etc.
Thank you, Mitchell!
Kwi's (a KDE embedder) CI/CD and its Flatpak builds/repo have moved to the new version.
But I wasn't entirely sure, but Mitchell kept evangelizing it and his podcast interviews sealed it for me. I was going to use libghostty, along with Kitty Graphics Protocol to realize my vision.
It's been a pretty amazing 9 months. I've been as deep as assembly language trampolines and garbage collector debugging and as high as fixing cursive connections in Arabic script, with a lot of BubbleTea and hardening in between.
Here's some of the libghostty warez:
ntwebterm [1] , originally Coder's ghostty-web, is an xterm.js compatible browser embedder. I've added WebGPU rendering and soooo many UX enhancements; I finally forked it to keep it cohesive with our platform.
booba [2] uses ntwebterm to remote Golang programs over WebTransport or embed them in browser. All the demos on NimbleTerminal.com use it.
ntrecord [3] uses go-libghostty to make an improved version of Charm's vhs. The most important difference is it supports Kitty Graphics Protocol, but of course has all the compatibility that libghostty provides.
gloss [4] is 'less' for graphics. The hardest part of 'gloss' is forgetting to type 'less'. If you have Rex, run "gloss skill install rex" and you'll have a new "grex" command to view files in a side block, also command-shift-G will open a Gloss block. There's too much to write about, including how agents can use it... coincidentally released a new version yesterday.
I made a Golang 3D game engine that targets Kitty Graphics [5]. Started at 4fps but got it to 120fps! And once you are there, you can add yummies like Gaussian Splatting.
Everything in the Nimble Terminal Platform is layered, so you can grab the parts that fit your needs.
Thank you Mitchell and the libghostty team for empowering and inspiring us!!!
[1] https://nimbleterminal.dev/ntwebterm
[2] https://nimbleterminal.dev/booba
[3] https://nimbleterminal.dev/ntrecord
They are two very different setups, the former being covered by the likes of zhcon, jfbterm, fbpad, and my virtual terminal system; and the latter being a wide range of things depending from what one's desires are on the client.
- Noctty (~517 stars)
- GhosttyWin3
- ghostty-windows (~79 stars)
(I have formed no opinion, positive or negative, on WinTTY yet, BTW, so don't take this as either an endorsement or a... whatever the right word for anti-endorsement would be).
Ghostty is simpler and faster
Haven’t gone back since.
iTerm just feel less buggy. For example I was running Claude in a container the other day and the slash command complete wasn’t rendering properly with Ghostty but worked perfectly fine with iTerm.
I want to switch to Ghostty because I prefer how simple Ghostty is overall and I think the project itself is very cool and an important piece of software (libghostty) but it doesn’t quite get there for _for my use cases_.
If you thought building a terminal emulator too hard to add for your project, you no longer have an excuse, libghostty makes it very easy to implement
What I'm working on now is close to what libghostty enables: a daemon that runs foot's terminal core headless, so programs keep running when the app quits or crashes, and windows come back with their scrollback. Next I want to attach to sessions on other machines over SSH.
1) A non-profit company that has full-time employees but supported via sponsorships: (gnu project, mastodon, omarchy, zig)
2) Multiple for-profit companies that each have full-time employees contributing to an open source project that they all use: (ocaml, linux, rust)
3) An ultra high net worth individual that has full-time contributors to open source and supported via a non-profit (signal, ghostty)
4) A for-profit company that has dedicated full-time employees that have full support and own the direction of the open source project (go, swift, java)
5) VC funded open source projects (Herdr, Bun, Deno, Burno, Atuin)
All other options such as low donations like "buy me a coffee", ko-fi, are completely unsustainable, now that AI agents exist.
I think this has not been the case for Java in quite a while. It is a community project now.
why won’t people write their own subset of terminal emulators, just for their own need?
Probably faster without waiting for 3rd party to fix bugs and merge patches, no?
I do agree in case of terminals this subset of people might overlap a lot with the entire market -> developers.
I see the future a bit different as in many people/companies will offer to the market some kind of building blocks that will be extra configurable by agents and then we are combining them.
In this case libghostty is such a component that can be integrated in a lot of things and people building those things want to work at a higher level of abstraction than building the terminal emulator. To be honest is among the best example of such a component that I see in the future that I think about.
It’s time for the industry to realize that the weights may have shifted toward build vs. buy, but the general SaaS calculus is still in effect.
Mitchell could have easily snuck his competing product Rex in there but resisted. Respect.
I'm still interested to check it out though none of these things have ever interested me too much so far.
Does this mean Apple might nuke those capabilities next year? It would not surprise me, but for right now, it’s really freaking good what they managed to put together.
It’s worth downloading the beta just to study their onboarding flow.