Creator of Ghostty talks Zig over Go

Mitchell Hashimoto frames Ghostty’s long-term bet as a split between a cross-platform terminal emulator library (libghostty) and a “platform-native” terminal app experience—then argues that the emulator core should stop being reinvented by every terminal project. The priority isn’t chasing iTerm2-style feature sprawl inside the app; it’s building a reusable emulator foundation so other developers can focus on higher-level terminal behaviors and UI, avoiding years of duplicated work across terminals like iTerm2, Kitty, and others.

Hashimoto’s roadmap centers on stabilizing the Ghostty app feature set so users can choose based on what they value: speed, feature richness, and platform-native integration. He’s confident iTerm2 will remain ahead on raw feature count, but positions Ghostty as the better fit when the terminal’s “feel” matches the operating system—updates, UI conventions, and security behaviors included. A key example is macOS “secure entry” mode, which blocks other apps from stealing keystrokes while sensitive input (like passwords) is entered. He contrasts this with Linux’s fragmented ownership across kernel, desktop environment, and windowing layers, arguing that such cross-layer features are harder to implement in open ecosystems.

The conversation also turns into a product philosophy lesson: loud feature requests are a signal, but not a blueprint. Hashimoto describes how corporate product managers often treat “N customers asked for X” as a scientific mandate, even when the real need is different or when the feature could harm the product’s long-term shape. For Ghostty, feature requests flow through discussions rather than direct issues, partly to uncover what people actually want and to evaluate whether the request fits the project’s vision.

On the engineering side, Hashimoto says Ghostty began as a learning project—Zig, GPU programming, and desktop software—before becoming something worth shipping. He credits Zig with making Ghostty easy to compile from source and with giving him the kind of control and enjoyment that keeps the project moving. His dislike of Rust is personal and practical: he finds Rust’s traits and navigation model frustrating day-to-day, while Zig’s compile-time approach reduces the need for runtime interfaces and dynamic dispatch. He also argues that interfaces aren’t always “missing”; they can be replaced with compile-time polymorphism, and he claims Ghostty avoids vtable-based dynamic dispatch entirely.

Sustainability and motivation remain open questions. Hashimoto says he can personally fund the work, but wants a path for others to take over eventually—likely through a foundation-style structure and corporate sponsorship tied to libghostty’s ecosystem potential. He calls the project “technical philanthropy,” treating the terminal as a widely used developer tool and aiming to make it free and useful.

Finally, he addresses open-source friction and AI tooling. He reads negative feedback for the truth inside the emotion, avoids blocking critics, and treats the internet’s anger as something to process rather than personalize. He uses Copilot and other AI tools, describing them as strong autocomplete for Zig-level patterns but not reliable for higher-level reasoning. He also raises licensing uncertainty around training and code reuse, noting Ghostty’s MIT license and the need for clearer legal precedent—while saying that if AI-generated code ever became a real issue, he would rewrite affected parts.