Why Mitchell Hashimoto Chose Zig to Rebuild the Terminal

The terminal is a developer's primary interface, yet architecturally, it remains a house built on sand. For decades, terminal emulators have been treated as dumb pipes rendering unstructured byte streams over pseudoterminals (PTYs). While modern web browsers ship dozens of features a year, terminal innovation has largely stalled, trapped in a cycle of legacy escape sequences and rigid grid layouts.

Ghostty, a terminal emulator created by Mitchell Hashimoto, represents a deliberate attempt to break this stagnation. Best known for building foundational infrastructure tools like Vagrant, Packer, Consul, and Terraform, Hashimoto turned his focus to desktop systems programming after leaving HashiCorp.

Ghostty is not just another fast terminal. Its design offers a masterclass in modern systems-level tooling decisions, highlighting why Zig is emerging as a formidable competitor to Rust, how to architect truly native cross-platform applications, and how we might finally fix the terminal's broken protocol layer.

The Language Choice: Why Zig Over Rust?

When building high-performance developer tools today, the default choice is almost always Rust. Rust powers modern terminal projects like Alacritty, offering memory safety and a mature ecosystem. Yet, Hashimoto chose Zig for Ghostty. This decision highlights several practical trade-offs in systems programming.

First, Zig provides explicit memory allocation. In a terminal emulator, handling high-throughput rendering (such as running a DOOM fire animation at 480 to 500 frames per second) requires strict control over latency. While Rust's borrow checker ensures safety, its implicit allocations can introduce unpredictable overhead. Zig forces developers to pass allocators explicitly to functions that require memory. This makes the memory footprint, cache locality, and vector operations highly predictable, which is critical when writing low-level code that interfaces directly with the GPU.

Second, Zig offers unparalleled C interoperability. Terminals must interface heavily with OS-level C APIs for PTY handling, system font rendering, and windowing. While Rust requires complex foreign function interface (FFI) bindings, unsafe blocks, or build scripts to talk to C, Zig can import C header files directly and compile C code natively. This drastically simplifies the build pipeline and reduces the friction of integrating with legacy desktop environments.

Finally, Zig lacks hidden control flow. There are no operator overloads, no implicit conversions, and no hidden allocations. For a developer looking to sharpen low-level systems programming skills, Zig provides a level of mechanical sympathy that is harder to achieve in Rust's highly abstracted type system.

The Architecture of Native: libghostty and Platform Frontends

Most cross-platform desktop applications make a painful compromise. They either use heavyweight runtimes like Electron, which consume hundreds of megabytes of RAM, or they use custom rendering engines that ignore native OS widgets. For example, Alacritty spawns a new process for every window, and Kitty uses custom non-native widgets for tabs.

Ghostty bypasses this compromise through a modular, split-core architecture centered around libghostty. The core terminal emulation engine, state machine, and parser are written in Zig and compiled as a library.

+--------------------------------------------------+
|                  libghostty (Zig)                |
|  - Terminal Emulation State   - Parser & Grid    |
|  - PTY Communication          - GPU Rendering    |
+-----------------------+--------------------------+
                        | (Native Bindings)
         +--------------+--------------+
         |                             |
         v                             v
+------------------+         +---------------------+
|   macOS Frontend |         |    Linux Frontend   |
|  - Swift/AppKit  |         |  - GTK/C Bindings   |
|  - Native Tabs   |         |  - Native Windows   |
+------------------+         +---------------------+

This architecture allows the frontend to be written in the native language of the host operating system. On macOS, Ghostty's GUI is written in Swift using AppKit and SwiftUI, allowing it to support native window tabs and native split views. On Linux, it uses GTK to integrate with the desktop environment.

By decoupling the terminal engine from the presentation layer, Ghostty achieves the performance of a compiled systems language without sacrificing the pixel-perfect, low-overhead integration of native OS user interface components.

Beyond the Dumb Pipe: Rethinking Terminal Protocols

Performance is only half the battle. The deeper issue with modern terminals is the PTY's in-band signaling. Because data and control commands are mixed into a single unstructured byte stream, building rich, interactive terminal applications is incredibly difficult.

While modern shell projects like Nushell attempt to solve this by passing structured tables between commands, Hashimoto argues that we need fundamental protocol-level improvements. He points to PowerShell as an ecosystem that got structured data right, and proposes two specific protocol additions to modernize how terminal applications behave:

1. The n-Screen API

Historically, terminals have only supported two screens: the main screen (your standard shell with scrollback) and the alternate screen (used by full-screen applications like Neovim, which disables scrollback).

An n-screen API would allow applications to create and populate an unlimited number of background screens, overlaying them with separate grid sizes. The terminal emulator would handle line wrapping, selection, and mouse routing. This would allow a terminal application to open native window tabs or floating panels directly, managed entirely by the emulator.

2. The Button Protocol

Currently, mouse protocols only notify an application when a user clicks a specific grid cell. If the content scrolls, those coordinates become invalid.

By extending the concept of OSC 8 hyperlinks, a button protocol would allow applications to embed interactive elements that send a specific message back to the program when clicked. Crucially, these buttons would remain active even after they scroll back into the terminal's history. This is particularly relevant for modern CLI tools like Claude Code, where users frequently need to interact with historical output.

The Developer Takeaway

Is Zig ready for production developer tooling? The language is still pre-1.0, meaning early adopters must tolerate breaking compiler changes and a shifting standard library.

However, Ghostty demonstrates that Zig is no longer a niche academic project. For high-performance, single-node systems programming where memory layout and C integration are paramount, Zig is a highly productive alternative to Rust.

By separating the core engine into a reusable library (libghostty) and building native frontends, Ghostty provides a blueprint for the next generation of developer tools: fast, feature-rich, and deeply integrated into the operating system.