Mitchell Hashimoto on Ghostty, Zig, and the Future of Terminal Emulators

Ghostty: Bridging GPU Programming and Terminal Emulation

Mitchell Hashimoto created Ghostty to sharpen his technical skills in areas that had grown dull during his time at HashiCorp, specifically targeting GPU programming, single-node systems programming, and the Zig language. After 15 years of building CLI applications, Hashimoto realized he lacked a deep understanding of how terminal emulators actually functioned.

Ghostty was born from a desire to build a terminal that is fast, feature-rich, and natively cross-platform. While it began as a private project for friends, it evolved into a public tool designed to be "riceable" and customizable without introducing bloat. Hashimoto defines "bloat" as features that cost performance when not in use; he architects features like search to occupy disk and RAM but remain dormant unless explicitly triggered.

Reimagining Terminal Protocols and APIs

Hashimoto argues that the current terminal ecosystem relies on a hodge-podge of legacy specs and "de facto" standards based on what popular terminals happen to do, rather than a cohesive vision. He identifies the PTY's in-band signaling—an unstructured byte stream with escape sequences—as a fundamental problem.

To move the terminal forward, Hashimoto proposes two specific architectural shifts:

The n-screen API

Currently, terminals typically support only two modes: a main screen (with scrollback) and an alternate screen (used by TUIs like Neovim). Hashimoto proposes an "n-screen API" that would allow for an unlimited number of background screens with separate grid sizes. This would enable the terminal emulator to handle line wrapping and mouse events while allowing screens to be rendered as standalone native windows.

A Structured Button Protocol

Existing mouse protocols only notify the terminal when a cell is clicked on the current screen. Hashimoto suggests a protocol similar to OSC 8 (hyperlinks) that allows programs to define buttons that remain functional even after the content has scrolled into history. This would be particularly useful for modern "main screen" applications like Claude Code, where the ability to open files or links from historical output is currently lost.

Philosophy on Open Source and Maintenance

Hashimoto maintains a strict stance on the relationship between open-source maintainers and users, emphasizing that the "as is, no warranty" clause of most licenses is the primary agreement.

• Agency and Forking: He encourages users to fork projects rather than requesting features or fixes that only serve a specific niche. He views the reluctance to fork as a "disempowering mindset" and argues that if users want specific guarantees or stability, they should pay for commercial software.
• Holistic Design vs. Feature Requests: Hashimoto warns against the "mountain of code" that results from accepting every PR. He advocates for a holistic approach where a single, well-designed feature solves multiple individual problems simultaneously, rather than patching symptoms.
• The Role of AI: While acknowledging the "trash" quality of AI-generated code, Hashimoto uses AI for rapid prototyping ("sloppifying demos") to test directions. He believes AI will eventually reduce the pain of breaking changes in languages like Zig by automating the migration from state A to state B.

Language Choice: Zig and the "Culture" of Development

Hashimoto has heavily invested in Zig for Ghostty, praising its focus on compilation tooling and the BDFL's (Andrew Kelley) willingness to make necessary breaking changes to improve the API.

However, his choice of language is as much about culture as it is about technology. He expresses a strong preference for "unapologetically weird" projects that maintain a distinct identity rather than languages that strive to be the least common denominator. In a point of contention noted in community discussions, Hashimoto explicitly stated he does not like the "Rust culture," despite respecting the language's technical merits.

"The philosophy behind the language and the language itself is really good. I just don’t want to use it... I really like the fact that certain languages lack certain features other languages enjoy, because these constraints breed creativity and culture."

Technical Learning and API Design

For those learning systems programming today, Hashimoto suggests that the specific language (C, Zig, or Rust) is less important than understanding the underlying hardware. He recommends studying CPU scheduling, memory cache hierarchies, and file systems.

His approach to API design is grounded in "porting concepts" from diverse ecosystems. By using libraries across different languages (e.g., exploring the builder pattern from Java in Ruby), he aims to incorporate the most enjoyable ergonomic patterns into his own work. He emphasizes the importance of "nouns" in API design, noting that Vagrant succeeded because its configuration and CLI revolved around development-focused nouns rather than deployment-focused ones.