The post introduced a new terminal emulator, “shitty,” positioned as a very fast text terminal with benchmark charts against terminals like Ghostty, Alacritty, Kitty, Foot, and GNOME Terminal. The author also leaned into two other hooks: it is written in C++ rather than Rust, and the direct code production was done entirely with an LLM under human review. That combination got attention, but the substance people focused on was narrower. The speed claims looked plausible as an engineering feat, especially around parsing and screen updates, yet most readers did not buy throughput as the deciding metric for choosing a terminal in 2026.
Where people landed was practical. For normal use, keypress-to-screen latency and startup time matter more than how fast a terminal can blast through a giant
ASCII dump. Several people said they only notice terminal performance when opening a new window feels sluggish or when log-heavy workloads block on
stdout. In those cases, the bottleneck is often not user reading speed but the producer getting slowed by terminal rendering. That made some of the throughput work feel real, but also pushed the conversation toward smarter behavior like minimizing repaint work, buffering aggressively, or skipping frames instead of rendering every line live.
The author argued that the terminal does the minimum possible redraw work through exact damage tracking and careful buffer reuse on
Wayland, and claimed flicker-free resizing on
macOS as a concrete differentiator. Readers pushed back on the jump from “minimal work” to “best latency,” noting that no latency measurements were provided and that implementation details alone do not prove the critical path. That skepticism extended to the AI angle. Some treated “100% LLM-generated according to spec” as fine if the tests,
fuzzing, sanitizers, and review are strong. Others saw it as a trust problem, especially paired with bold claims and casual answers about design choices.
A separate thread zeroed in on licensing. The project started from a
GPL codebase and the author said the goal is to end up with an
MIT-only version by having contributors dual-license rewritten code and then extracting the MIT-covered portion later. That did not settle the matter for everyone. Some accepted that this is a known legal path if done carefully. Others thought it cuts against the spirit of
copyleft even if a lawyer says the mechanics work. The author’s reason was straightforward: a GPL terminal library is far less usable by downstream projects.
A few concrete technical points stood out. One commenter highlighted the parser as the most interesting part of the project, since it uses
Ragel to define the terminal parser as a generated finite-state machine rather than hand-rolled parsing logic. Another noted that feature coverage changes how meaningful the benchmarks are, because graphics and keyboard protocols like
Sixel and Kitty’s extensions are absent for now. There were also reports that Ghostty’s performance on its main branch is already much better than the released version used in the benchmark, and at least one user claimed
urxvt under
X11 still beats all the newer
GPU-heavy terminals on raw ASCII throughput.
The mood was amused, skeptical, and impressed in that order. People liked the sheer nerd-sniping energy of making a terminal absurdly fast. They just did not see a strong reason to switch unless the project proves itself on the boring stuff that users actually notice every day.
github.com