Mitchell HashimotoのGhostty、速さとnative UIを両立したterminalの再設計

Ghosttyの物語は、terminal emulatorを速くするだけでなく、OSごとの「nativeらしさ」まで取り戻そうとしたMitchell Hashimotoの技術的な選択から始まる。

Ghostty READMEは「Ghostty provides all three」と述べ、speed、features、native UIsの三者択一を終わらせる目標を掲げている。出典

速さだけでは足りない

Ghostty repositoryは2022年3月29日に作成された。

既存terminalには高速なものも、機能豊富なものもあったが、platform-nativeな操作感まで同時に満たす選択肢は限られていた。

Hashimotoはこの空白を、端末の体感とOSの作法を分けずに解こうとした。出典

共通coreとnative layer

実装はZigを中心としたshared coreに、macOSのSwiftUI・MetalとLinuxのGTKを組み合わせる。

least-common-denominatorに落とさず、「そのplatform向けに最初から作られた」感覚を各OSで目指した。出典

terminalの標準を作り直す

開発の難所は、速い描画だけではない。

ECMA-48やxterm、他のpopular terminalsを順に参照し、mainstream CLIが壊れないconformanceを積み上げた。

さらにread・write・render threadを分離し、OpenGLとMetal、SIMD parserで性能を詰めた。出典

libghosttyへ広がる

standalone appとしての実装は、libghosttyというC-compatible libraryへ切り出され、Ghostlingのような埋め込み例へつながった。

terminalを一つのアプリで終わらせず、他のprojectへ組み込める部品にする転換である。出典

OSSの次の課題

一方で、official roadmapにはGhostty-only control sequencesが未着手として残る。

標準互換を守るほど独自進化は慎重になり、platformを増やすほど保守も重くなる。

Ghosttyの現在は完成宣言というより、速度・機能・native体験を両立し続けるための設計を公開で検証する段階だ。出典

Ghosttyは、terminal emulatorに「速さ・機能・native UIのどれかを選ぶ」という不満を持つ開発者に刺さる。

公式READMEは、既存terminalがspeed、features、native UIsの選択を迫る一方、Ghosttyは3つを提供すると説明する。出典

macOSではSwiftUIとMetal、LinuxではGTKを使い、OSごとの操作感を捨てずに共通の高速coreを共有する。

この明確な痛みと技術選択が、OSSでありながら日常のterminalを置き換える理由になる。出典

moatはterminal parser、renderer、native integrationを一体で磨く技術蓄積と、標準・xterm・各terminalの挙動を比較するconformance知識。

コードはOSSだが、性能とplatform experienceの両立には実装経験が必要になる。出典

network effectは弱〜中程度。

terminalは単独で価値を提供するが、OSS contributors、issue、discussion、libghosttyを埋め込む周辺projectが増えるほど互換性検証と利用例が蓄積する。出典

毎日terminalを使うsoftware developers、SRE、CLI利用者、そしてAlacrittyの速度とmacOS Terminalのnative体験を同時に求める人向け。

GUIよりremote shell中心で、既存terminalの機能に不満がないユーザーには乗り換え理由が弱い。出典

第一は、multi-threaded architectureとGPU rendererを使い、read・write・renderを分離したこと。

第二は、Zigのshared coreとmacOS SwiftUI/Linux GTKのnative layerを組み合わせたこと。出典

第三は、terminal standardsへのconformanceを性能だけでなく互換性の基準にしたこと。

既存workflowを壊さず、体感差を作る順番がOSS adoptionを支える。出典

native UIをplatformごとに作る方針は、macOS・Linux・Windowsで実装と保守の負担を増やす。

公式roadmapでもGhostty独自のcontrol sequencesは未着手で、標準を守ることと独自機能を進めることの緊張が残る。出典

また、Ghosttyの知名度や利用者数は公式READMEに定性的な説明があるものの、売上・有料プラン・法人サポートの公開情報は確認できない。

OSSとしての継続資金と長期保守は要確認だ。

GitHub公開、download、developer word of mouth、OSS contributionを入口にするPLG。

無料で試せるため、性能差を体験した開発者が周囲へ広げる。

platform-native方針は広い互換性より体験の深さを優先するため、開発対象OSを増やすほど保守コストが上がるトレードオフがある。出典

主要チャネル: community, content, productLedGrowth, social

OSS developer toolでは、機能一覧を増やすより「speed・features・native UIを同時に満たす」という選択の不在を定義すると、技術実装がpositioningになる。

共通coreとplatform-native layerの分離は、複数OS対応で妥協を減らす設計原則として持ち帰れる。出典

日本で広げるなら、terminal初心者向けの説明より、macOSとLinuxで設定・日本語入力・フォント表示がどう自然になるかを示すべきだ。

日本語IME、縦書きではなくCLI workflow、企業の開発端末標準化に合わせた設定移行ガイドを整えると、性能比較だけでは届かない層へ入れると考える。