The fastest terminal emulator won't run on your laptop
A new C++ terminal beats Alacritty, Kitty and Ghostty on throughput. The speed comes from GPU compute, not from the language — and the dependency list locks most of us out.
The fastest terminal emulator I have read a benchmark for this week is written in C++, and it almost certainly will not run on your laptop. The project is Shitty — github.com/pg83/shitty — a hard fork and rewrite of the Zutty terminal, posted to Hacker News with the tagline "Memory-unsafe and faster than yours."
It beats Alacritty, Kitty and Ghostty on the author's own throughput tests. I care much less about who won than about why, because the reason is not the one the tagline is selling.
🔍 What the numbers actually claim
Two benchmarks are published in the README. The first pushes printable ASCII through the terminal and scrolls it. The second feeds it random bytes, which is really a parser stress test.
Printable ASCII throughput:
| Terminal | Wall time | Throughput |
|---|---|---|
| Shitty | 0.81s | ~118 MiB/s |
| Alacritty 0.17.0 | 0.96s | ~99 MiB/s |
| Kitty 0.48.2 | 1.28s | ~75 MiB/s |
| Ghostty 1.3.1 | 1.49s | ~64 MiB/s |
Random bytes (parser stress):
| Terminal | Wall time | Throughput |
|---|---|---|
| Shitty | 1.88s | ~51 MiB/s |
| Alacritty 0.17.0 | 3.07s | ~31 MiB/s |
| Ghostty 1.3.1 | 4.63s | ~21 MiB/s |
| Kitty 0.48.2 | crashed on invalid UTF-8 | — |
These are the project's own numbers, run on the author's own machine, published by the author. That is not an accusation, it is just how self-reported benchmarks work. Nobody independent has reproduced them.
⚡ The speed is architecture, not the memory model
"Memory-unsafe and faster than yours" reads as a jab at Rust. But look at the closest competitor: Alacritty, written in Rust, sits about 19% behind on the ASCII test. That is a real gap, and it is nowhere near what you would expect if bounds-checking were the whole story.
What Shitty actually does differently, per its own README:
- Vulkan on Linux, Metal on macOS as native compute backends, rather than conventional draw-call rendering.
- Terminal state kept on the CPU, with the GPU doing the pixel work.
- Lazy glyph rasterisation — glyphs are only turned into pixels when first needed.
- A persistent GPU glyph cache, so the same character is not re-rasterised every frame.
- Damage-driven rendering — only the region that changed gets recomputed.
Every one of those is a design decision available in Rust, Zig, or C. None of them depends on being allowed to write past the end of an array.
Key takeaway: When a benchmark is framed as a language war, check the architecture first. The winning design here is GPU compute plus caching plus damage tracking. The language is a footnote that got promoted to the headline because it makes a better headline.
If you are a student trying C++23 features for the first time and you do not want to fight a local toolchain, you can poke at the language in the browser with our online C++ compiler before you commit to setting up Clang.
🖥️ The dependency list is the part that matters here
This is where the story gets local. Read the build requirements before you get excited:
| Platform | What you need |
|---|---|
| Build (all) | Clang with C++23, Python 3, Ragel 6, glslangValidator, librsvg, pkg-config, utf8proc 2.9+ |
| Linux | A working Vulkan driver, a Wayland compositor, FreeType, HarfBuzz, Wayland headers, xkbcommon, wayland-scanner, Vulkan headers and loader |
| macOS | Apple silicon as the primary target, plus SPIRV-Cross, CoreText, Cocoa, Metal, IOSurface |
| Optional | Brotli, simdutf 6.5+ |
Now map that onto the machines people I know actually use. A large share of working developers and university students in Sri Lanka are on second-hand ThinkPads and Dell Latitudes bought precisely because they are cheap, running whatever desktop the distro shipped. That very often means X11, not Wayland, and an old integrated GPU with a Vulkan driver that is either missing, partial, or crashy.
Bottom line: If you are on X11 or a GPU without a solid Vulkan driver, this terminal is not slow for you. It simply does not run. And the "primary native platform" is Apple silicon, which is a hardware purchase, not a download.
That is not a criticism of the project. Picking Vulkan and Wayland and refusing to carry X11 compatibility is a legitimate call, and it is exactly why the thing is fast. It just means the frontier of terminal performance has quietly moved onto hardware a lot of us do not have. Meanwhile Alacritty at ~99 MiB/s is already far past anything a human can read.
🛡️ The crash is more interesting than the win
Kitty failing the random-byte test on invalid UTF-8 is the detail I would actually act on. This is not an exotic scenario. You hit it the first time you cat a binary by accident:
# accidentally cat a compiled binary or a .bin file
cat ./build/myapp
cat firmware.bin
Every terminal has to survive arbitrary garbage arriving on a pty, because arbitrary garbage arrives on a pty all the time. A parser that dies on malformed input is a correctness bug that a throughput chart happens to expose.
Warning: If you want to test your own terminal's tolerance, redirect to a file first and use a bounded amount of data. Dumping tens of megabytes of random bytes straight into a live session will also mangle your scrollback and possibly your shell state.
The general lesson, and it applies well outside terminals: your hot path and your hostile-input path are the same path. Any parser you write — log ingestion, CSV import, a webhook handler taking someone else's JSON — will eventually get bytes that violate its assumptions. Benchmark that case, not just the happy one.
📜 The licence move is worth stealing
One quiet detail with real value for anyone here shipping open source. Shitty is a fork of Zutty, which is GPLv3. The project is moving toward MIT, and it is doing it the only honest way:
- Original Zutty code stays GPLv3. You cannot relicense code you did not write.
- New Shitty contributions are dual-licensed under GPLv3-or-later and MIT.
- Over time, as GPL-origin code gets replaced, the MIT half becomes usable on its own.
That is the correct pattern if you ever fork a copyleft project and want a permissive licence later. The wrong pattern — quietly slapping an MIT LICENSE file on top of GPL code — is a legal problem you hand to every downstream user, including yourself if you later want to sell something built on it.
💡 What this means for you
- Don't switch terminals over this. The gap between the fastest and second-fastest here is invisible in daily work. Your build times, your network, and your test suite dominate.
- Read benchmark framing critically. "Memory-unsafe and faster" is a claim about a language; the evidence is a claim about GPU compute and caching. Those are different arguments.
- Check hardware assumptions before you get invested. Vulkan plus Wayland, or Apple silicon, is a real gate. Confirm your own machine qualifies before spending a Saturday on dependencies.
- Steal the ideas, not the binary. Damage-driven redraw, caching expensive work, and lazy rasterisation are portable to whatever you are building, including web UIs.
- Test your parsers with garbage. The Kitty result is the most transferable finding in the whole post.
The interesting thing here was never C++ versus Rust. It is that a small project can still beat well-funded, well-known tools by picking a sharper architecture and refusing to support everything. That is a strategy available to a two-person team anywhere, including here.