Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours
A new open-source terminal emulator called “shitty” claims substantially higher text rendering throughput than popular tools like Ghostty, Kitty, and GNOME Terminal, prompting debate over whether such performance gains matter in everyday use. Commenters contrast throughput with more user-visible factors such as startup time, resize behavior, and keypress latency, with many noting they rarely experience terminals as a bottleneck. The project’s provocative name, heavy use of AI-generated code, and plan to move from a GPL-based codebase to MIT licensing spark broader arguments about professionalism, licensing ethics, and long-term maintainability.
Project and Performance Claims
- New cross-platform terminal emulator focused on maximum throughput and written in C++ (explicitly “memory-unsafe,” i.e., not Rust).
- Benchmarks show significantly higher ASCII throughput than popular terminals (Ghostty, kitty, alacritty, GNOME Terminal, etc.).
- Uses a two-letter binary name
st, overlapping with an existing terminal and raising collision concerns.
Practical Value vs. Over-Optimization
- Many commenters say they rarely feel constrained by terminal performance and prioritize features, integration, and stability instead.
- Several argue the lifetime time savings from higher throughput are tiny compared to the cost of switching terminals.
- Others note workloads with extremely chatty output (build logs, debug dumps, accidentally
cat-ing huge files) can be meaningfully limited by terminal throughput.
Startup Time and Latency
- Multiple users care more about startup time and keypress-to-screen latency than raw throughput.
- Some report near-instant startup from xfce4-terminal, foot, xterm, kitty (with single-instance), while Ghostty is described as slower on some systems.
- The author claims very fine-grained damage tracking and minimal redraw work, asserting best-in-class latency based on implementation, but there are no concrete latency measurements, and this “provably minimal work” claim is questioned.
Naming and Adoption
- The name “shitty” is polarizing: some find it clever and memorable; others view it as juvenile and a barrier to corporate adoption.
- Debate over whether avoiding profanity in tool names matters; some say they wouldn’t work where this is an issue, others emphasize professionalism.
- Two-letter command naming is also criticized as unnecessary and conflicting.
AI-Generated Code and Quality
- Large portions of the code (including tests) are generated by LLMs, with human review, sanitizers (ASan/UBSan), fuzzing, and coverage tracking.
- Some see this as a highly professional, test-driven approach; others question the claim this puts the project in the “top 0.1%” and doubt how thoroughly AI output is audited.
Licensing and GPL Concerns
- The project began from a GPL-licensed baseline and aims to move to an MIT-only codebase via a dual-licensing rewrite process.
- Critics argue this is legally or ethically dubious and that the work is still GPL-derived; the author cites legal advice and insists the process is valid.
- Broader debate arises over copyleft vs. permissive licenses: whether forcing derivative openness protects community reciprocity or restricts developer freedom.
Features, Protocols, and Architecture
- Currently lacks support for modern graphics and keyboard protocols (e.g., sixel, kitty graphics/keyboard); some argue this makes comparisons with “modern” terminals incomplete.
- The terminal output parser is implemented as a large Ragel-generated finite-state machine, praised as an elegant and performant approach.
- Architecture reportedly cleanly separates parsing, terminal state machine, and rendering, making future library-style reuse possible, though no “libterminal” API is planned yet.