Mitchell Hashimoto: Ghostty, Zig и философия терминала

10.07.2026 · 5 мин

Знаешь, что меня всегда удивляло? Терминал — такая древняя штука, а мы до сих пор спорим о том, как его улучшить. Недавно наткнулся на интервью Митчела Хасимото — человека, стоящего за Terraform, Vault, Nomad и кучей других инструментов, которые сейчас у всех на слуху. Он рассказал, зачем написал свой терминал Ghostty и почему выбрал для этого Zig.

Меня это зацепило. Не потому что Ghostty — это что-то революционное (хотя может и революционное), а потому что за этим стоит интересный подход к инженерии. Давайте разберёмся.

Кто такой Mitchell Hashimoto и почему его мнение важно

Митчел — один из тех людей, которые не просто пишут код, а проектируют экосистемы. Он сооснователь HashiCorp — компании, подарившей миру Terraform, Consul, Vault и Nomad. Это не просто инструменты, это стандарты индустрии.

После ухода из HashiCorp он мог бы отдыхать на пляже. Но вместо этого занялся Ghostty — эмулятором терминала, и Vouch. То есть человек с бэкграундом в распределённых системах и облачной инфраструктуре внезапно решил погрузиться в десктопную разработку и низкоуровневое программирование.

Почему это интересно? Потому что такие переходы редко происходят без причины. Когда инженер уровня Хасимото говорит «мне захотелось разобраться, как работает терминал», это сигнал, что в нише терминалов есть нерешённые задачи уровня серьёзных инженеров.

Почему Ghostty? история с продолжением

Митчел рассказывает, что 15 лет занимался CLI-приложениями. Через этот процесс он случайно научился работать с цветами, курсором и прочим. Но при этом не понимал, как работает сам терминал.

Перед уходом из HashiCorp он хотел «заточить» свои технические навыки, которые притупились от работы на высоком уровне абстракции.

Первоначальная цель была скромной: запустить в терминале vim и компилятор, собрать терминал самим собой, а потом выбросить. Но в процессе он понял, что ниша «быстрый, фичастый, кроссплатформенный нативный терминал» пуста.

Ghostty начался как личный проект. Митчел поделился им с друзьями в Discord — те попросили разрешения пригласить ещё людей, потому что реально стали использовать терминал каждый день. Так группа друзей превратилась в комьюнити.

Интересный момент: он долго не хотел публиковать проект публично, потому что его публичное имя привлекло бы слишком много внимания. Приватная бета длилась долго.

Zig и философия контроля

Отдельная тема — почему именно Zig. Митчел не упоминает конкретные технические детали, но контекст говорит сам за себя. Zig позиционируется как язык системного программирования с ручным управлением памятью, без hidden аллокаций и с прямым контролем над оборудованием.

РАЗВИТИЕ НАВЫКОВ МИТЧЕЛА ХАСИМОТО
────────────────────────────────
Распределённые системы        →  Однохостовое ПО
    (сети, контейнеры)            (кэш, векторы)
            │                           │
            ▼                           ▼
    Terraform, Consul        ←  Ghostty, Zig
        (high-level)              (низкий уровень)
Траектория развития: от облачной инфраструктуры к десктопу

Ghostty написан на Zig, что для терминала логично: нужен контроль над памятью, предсказуемая производительность и минимум runtime. Никаких виртуальных машин или интерпретаторов, замедляющих работу.

Терминал как платформа: мысли о будущем

Вот где начинается самое интересное. Митчел размышляет о терминале не как о «окошке для командной строки», а как о платформе для приложений.

Он не сторонник идеи «давайте запихнём в терминал всё»: браузер хорош для своего, десктоп для своего, терминал — для своего. Но у текстовых приложений есть уникальные свойства: скорость реализации, простота взаимодействия, прозрачная модель безопасности.

TUI-приложения менее composable, чем классические CLI, но CLI-инструменты часто имеют механизмы для использования как функции — философия UNIX «делай одно дело». Neovim и AI-тулкиты развивают это с новыми флагами командной строки.

Проблема? PTY использует in-band сигналинг — поток байтов с управляющими последовательностями. Неструктурированный формат затрудняет парсинг и расширение протокола. Nushell пытается добавить слой абстракции, но это полумеры.

ПРОТОКОЛЫ ТЕРМИНАЛА
───────────────────
PTY и байты
┌──────────────────────────┐
│ данные ▶ ESC-секвенции   │
│ данные ▶ управляющие коды│
└──────────────────────────┘
            │
            ▼
Проблема: нет структуры
Текущий терминальный поток мешает расширяемости

Два протокола, которые кричат

Митчел упоминает две вещи, которые ему хотелось бы видеть в терминалах:

N-screen API — вместо двух экранов (основной с историей и альтернативный на весь экран) возможность создавать неограниченное количество экранов, оверлеить их, менять размеры сетки. Представь, что табы Neovim рендерятся как нативные окна терминала, а не как визуальные сплиты. Это фундаментальное улучшение.

Button protocol — по аналогии с OSC 8, но для кнопок. Сейчас mouse protocols уведомляют о кликах по текущей сетке. Но когда что-то уходит в историю — ты теряешь возможность интерактивности. Claude Code как пример main screen приложения страдает от этого: ссылки и кнопки перестают работать при скролле назад.

Баланс между вижном и реальностью

Митчел высказывает мысль, которая мне очень близка: open source мейнтейнеры не обязаны пользователям ничем. Первая строка лицензии — «как есть, без гарантий». Это соглашение.

Но он сам чувствует обязательство делать хороший софт. И тут важный баланс: иногда нужно погружаться в issues и чинить чужие проблемы, иногда — фокусироваться на большом вижне и игнорировать всё.

Его аналогия хороша: можно построить идеальный город в небесах, а потом вернуться и увидеть хаос в реальном мире. Приходится переключаться.

Главный поинт: если только разбирать issues — получишь стабильный, но стагнирующий софт. Если принимать все PRы — получишь изменение без вижна. Только один человек за несколько лет может по-настоящему «понять» проект.

Митчел приводит пример: на дизайн фичи у него ушёл час, но до этого он год думал о ней в фоне. Не специально, просто она всегда была на периферии мышления.

Bloat vs фича: минимализм Ghostty

Конфликт вокруг поиска в Ghostty показателен. Search — одна из самых запрашиваемых фич, Митчел её реализовал. Но кто-то пожаловался, что поиск «раздул» терминал и сломал минимализм.

Митчел ответил интересно: он рекламирует Ghostty как «фичастый», но не как «раздутый». Разница в том, что неиспользуемые фичи не должны влиять на производительность. Поиск занимает место на диске и в RAM, но если не используешь — ничего не выполняется.

Идея «riceable» терминала позволяет терминалу оставаться быстрым по умолчанию, но раскрывать возможности по запросу. Работает из коробки, но прячет глубину до востребования.

Практические выводы

Если хотите посмотреть само интервью и услышать мысли Митчела в оригинале — там обсуждаются и технические детали, и баланс между вижном и поддержкой.

Ссылки

Дмитрий Полухин — продуктовый дизайнер. Пишу про разработку, AI и дизайн интерфейсов. Обо мне, контакты и профили.

Что почитать дальше