- Atomを作ったチームは、軽量でありながらIDE級の機能を備えたエディタという同じ目標を、Zedで Rust・GPUアクセラレーションUI・CRDT・Tree-sitter を基盤に再び実現しようとしている
- 2017年のAtomの限界は、チームの力量よりもElectronとJavaScriptの メモリ・レンダリング制御の不足 によって大きく表面化し、このとき「再び始めなければならない」という判断につながった
- Rustは、Zedが共有メモリとマルチスレッドをより安全に扱えるようにし、copy-on-write B-treeと
Arcベースのrope構造により、バックグラウンド処理に必要な O(1)スナップショット を可能にする
- ZedはGPUI、Tree-sitter拡張、
editor crate、multi-buffer、SumTreeのような中核レイヤーを自ら所有することで細かな制御を得る一方、開発速度とオンボーディングコストを受け入れている
- ユーザーにとって最も重要な結果は高速なエディタであり、Rustと
cargoベースの構造は、オープンソースのコントリビューターがビルドや変更を試しやすくし、マージへの信頼性を高める
AtomのビジョンがZedへ引き継がれた方法
- Zedの目標は、Atomが当初追求していたビジョンをより洗練させた形に近い
- 軽量でミニマルで、テキストエディタのように感じられるツール
- 必要なときにはIDEレベルの機能を提供しつつ、UIと使用体験が遅く重くならないツール
- 拡張可能でスクリプト化できるエディタ
- Emacsの拡張性は初期のビジョンに影響を与えたが、単に文字単位で操作する方式よりも、より豊かなテキスト表現 にアクセスする方向を望んでいた
- Tree-sitterは、テキストを文字よりも構造的に扱えるようにする基盤であり、Zedはまだスクリプト化可能ではないが、その方向を目指している
- AtomはWeb技術を基盤に始まり、当時はRustがなく、CやC++でネイティブエディタを作ることも難しいと判断していた
2017年に「再び始める」と決意した理由
- Atomは2017年にTeletypeをリリースした後、チームの未熟さよりも プラットフォーム上の制約 の方が大きなボトルネックだと感じ始めた
- JavaScriptの配列はオブジェクトポインタの配列のように動作し、走査時にポインタ追跡コストが発生し、メモリ配置やガベージコレクタの停止を直接制御することが難しかった
- 行レイアウトを高速に作ろうとする作業でも、iframe、Canvas、テキスト計測APIを迂回的に組み合わせる必要があり、カーソル位置や行配置のように単純に見える作業も複雑になった
- ElectronはAtomを作るために生まれたが、コードエディタが求める水準の制御を提供するのは難しかった
- より単純なアプリには使えるが、メモリフットプリントが大きいという欠点がある
- コードエディタでは、レンダリング、入力、テキスト処理において、より直接的な制御が必要になる
- 2017年のある時点で、Atomでは望むレベルまで到達できないと見て、Rustで中核を書きつつElectronをプレゼンテーション層として維持するというアイデアから出発した
RustとGPUアクセラレーションへ移行した過程
- Zedの技術選択は、最初から固定された青写真があったわけではなく、一段階ずつ制約を取り除くなかで定まっていった
- まずRustで中核を書く方向を検討した
- その後Electronを諦め、独自のUIフレームワークを作ることになった
- Pathfinderを使ったが遅すぎたため、独自シェーダーとsigned distance fieldを学んで適用した
- GPUアクセラレーションは「GPUアクセラレーションエディタ」というスローガンから出発したというより、画面上の各ピクセルの色を並列に計算できるハードウェアを直接使えば、より速くできるという判断から選ばれた
- ZedはDOMノードを調整する方式ではなく、画面のピクセルをどう描画するかに近いレベルでレンダリングを制御する方向を選んだ
- 性能改善の例として、
find-all-matchesは従来約1秒かかり、Sublime Textは約200msに近かったが、内部APIを呼び出す高水準コードだけで、リリースビルドでは 4ms まで短縮された
- Rustのコンパイル時間は不満点として残っているが、高水準の抽象化の上でも性能を期待できる点が、Zedの開発に有用に働いている
JavaScript/C++境界とRustのマルチスレッド
- AtomでもC++を多用していたが、JavaScriptのアプリケーションコードとC++ライブラリコードの間の境界が大きなコストとして働いた
- 処理をバックグラウンドスレッドへ移すには、関連するサブシステムをC++側に下ろす必要があった
- 共有メモリを使うためにC++レイヤーを作り、改めてJavaScript APIを設計しなければならなかった
- JavaScriptらしく見せながら既存の属性を維持することも必要だった
- Rustはマルチスレッドに親和的な設計を持っており、Zedが望む方式によりよく合っている
- 初期には親ポインタがあり変更可能なsplay treeをRustで実装しようとしてborrow checkerと衝突し、実際にシステムを作れるのか疑うほどだった
- その後copy-on-write B-treeを作る中で
Arcを使い、この構造は自然にマルチスレッドに適した形になった
- Zedの基本的なテキスト保存構造である rope は、バックグラウンドスレッドにスナップショットを渡す際に
Arcの参照カウントを増やす程度で処理できる
スタック全体を自ら所有する選択
- Zedは、パースを担うTree-sitterからGPUアクセラレーションUIフレームワークであるGPUIまで、大きなブロックを自ら所有する方向を選んだ
- 自ら所有する構造により、必要な動作を自分たちで決定し実装できる
- 言語拡張でWASMを使いたいとき、Tree-sitterにその機能を追加できた
- テキストエディタに重要なテキストレンダリング方式を、外部UIフレームワークに任せなくて済む
- GPUIは2019年に始まり、当時存在していたUIフレームワークはZedに必要な動作を満たせないか、チームが十分に理解していない状態だった
- 下位プリミティブを直接理解してシステムを構築する方式は、GPUIでは 生存戦略 に近かった
- コストも明確である
- 自分たちで作るには時間がかかる
- 開発速度が遅くなる
- 広く知られたフレームワークを使わないため、新しい人材は約30万行のコードベースを最初から学ばなければならない
- 同時に、そのコードを書いた人が内部にいるため新メンバーに説明でき、時間が経つほど自ら所有するコストは減り、利点は蓄積され得ると見ている
- loungyのように、GPUI上に別のアプリが作られた事例も出ている
完成度を高める場所と素早く済ませる場所
- Zedチームの基準は、必要なものだけを作り、その範囲内でできるだけ良く作ることだ
- 将来必要になるかもしれない機能を推測して時間を使うより、実際に必要になったものに意図と注意を払って実装する
- 完成度の基準は、コードが位置するレイヤーによって変わる
- GPUIのようにアプリ全体が依存するレイヤーには高い完成度が必要
- SumTreeのようにコードベース全体で使われ、性能が重要なデータ構造も慎重に扱う
- 端の特定の性能改善は、過度に磨き込むより目的を達成する水準で処理する
- SumTreeはエッジケースを確認するために ランダムテスト を使用する
- 完璧主義が学習を妨げてはならず、自分たちで作ったコードを長く運用し、妥協も経験した後で書き直す場合には、学習を反映した再実装の根拠が生まれる
CRDTとバッファ構造から得た教訓
- Atomの初期バッファはJavaScript文字列配列、つまり行配列だった
- Zedのバッファはマルチスレッドに親和的でスナップショット可能なcopy-on-write B-treeであり、必要な複数の項目をインデックス化する
- CRDTは最初から当然の選択ではなく、複数の論文を読む研究期間を経て現在のアプローチに整理された
- CRDT実装は2、3回書き直されたが、アプローチ自体はおおむね維持された
- 初めてのコードエディタだったAtomでは、より速く粗い「worse is better」アプローチを使い、その経験から実際の痛点がどこにあるのかを把握した
- もう一度始めるなら、バッファを単純な行配列にはしないだろうし、過去の遅かった事例とエッジケースが、より多くの設計を求めることになる
Zedで特に力を入れたレイヤー
- GPUIは全体を書き直した分、高い完成度を追求した領域である
editor crateは、生のバッファテキストを画面上の行へ変換する複数のレイヤーを含む
- タブ展開
- ソフトラップ
- ブロック装飾の挿入
- 折りたたみ処理
- これらの変換レイヤーは、プロパティベースのランダムテストを用いる一貫したテスト戦略を持つ
- multi-bufferは、異なるバッファの一部を1つに結び合わせる構造であり、これも中核として扱われている
- 2021年には、ランダムテストが見つけたエッジケースを縮小しデバッグするために、何日も丸ごと費やしたことがある
- Rustで書かれたこのレイヤーが誤ると、単にエディタの隅にスタックトレースが表示されるのではなく、プログラムがpanicで終了する可能性があるため、正確性が重要になる
- 大きなファイルを開くとき、ユーザーが何のフィードバックも受け取れない状態を減らすため、よりストリーミングに適した入力と読み込みの改善も議論され、関連する最適化がpreviewに入る予定である
ユーザーとコントリビューターに残る違い
- 最終ユーザーは結局、エディタが速いかどうかを最も重視する可能性がある
- 開発者ツールとエディタでは、ユーザーがコードベースに直接貢献する可能性が高いため、実装言語とビルド方式が貢献のしやすさに影響する
- ZedがC++で書かれていたなら、自分で変更しようとするユーザーは減っていたかもしれない
- Rustと
cargoはプロジェクトのビルドや変更の試行を容易にし、CMakeやGypを学ぶ必要を減らす
- Rustコンパイラの厳格さは、外部からの貢献を受ける立場では マージの信頼性 を高める助けになる
- Zedはフレームを 3ms未満 に保ちたいと考えており、この性能要件のためにCPUラスタライズではなくGPUアクセラレーションUIフレームワークを選んだ
- Zigにも関心はあるが、サーバーとフロントエンドがどちらもRustである単一言語構成には利点がある
1件のコメント
Hacker News の意見
Zed の カスタム UI フレームワークは今は面白く見えるかもしれないが、アクセシビリティを実装しなければならないと気づいた瞬間に状況が変わりそうだ。
パフォーマンスを犠牲にせずにカスタムフレームワークでアクセシビリティを実装するには、プラットフォームごとに泥臭い作業が大量に必要になる。Zed は単に使わなければいいエディタではなく コラボレーションツールとして位置付けられているのだから、チームのすべての開発者が使えるようにすることが必須だ。
スクリーンリーダー利用者として、VoiceOver には空のウィンドウしか見えない Rust ベースの「モダン」なツールにはうんざりしている。ボタンに aria ラベルをいくつか付けてフォーカスを整理すればよい Web アプリより、すべてのコントロールをすべての OS に公開しなければならないカスタム UI のほうがはるかに難しい。
幸い https://accesskit.dev/ のような AccessKit が登場して作業は多少楽になるかもしれないが、エディタのような大規模アプリにどれほど適しているかは分からない。
GPUI をゼロから作ったため、Swift や Web ベースのアプリが持つアクセシビリティ機能をそのまま使えず、Zed 側の作業と GPUI の機能拡張が同時に必要だとしている。
ところがアクセシビリティ議論へのリンクとして貼られている https://github.com/zed-industries/zed/pull/1297 は戻る/進むボタン関連の GitHub issue で役に立たない。おそらく https://github.com/zed-industries/zed/discussions/6576 をリンクしたかったのだろう。
関連ドキュメント: https://zed.dev/docs/themes
アクセシビリティは考慮されてはいるが、まだ実装段階には至っていない。
つい最近まで、既存の C フレームワークのバインディングか、概念実証レベルの GUI ライブラリしかなかった。今後は良くなっていくだろうが、アクセシビリティ機能に依存する立場の苛立ちも理解できる。
ただ、多くのプロジェクトはまず堅牢な GUI ライブラリを作り、その後でアクセシビリティ機能を追加しようとする可能性が高い。
多くのスタートアップが、差別化要因でもないきらびやかな機能にリソースを注ぎ込んで失敗してきた。
非ネイティブ UI で成功した製品は、たいてい Web 技術や Qt のような成熟したフレームワークを使っているか、あるいは 30 年の歴史を持つ Blender のような例外だ。Apple も iTunes で似たことをしたが、Windows 向け iTunes はひどいもので、それでも人々は iTunes を使っていただけだ。
GPUI のようなフレームワークを作りたくなる魅力は理解できるが、この記事ではそれが Zed が解こうとしている問題とどう関係するのかを説明していない。
ピクセルだけを見て人のように理解し、OCR でテキストを解析するようなツールのことだ。
VoiceOver のような技術は、実際のウィンドウ定義や要素をプログラムレベルで理解してそれを活用しているものだと理解している。
GPU レンダリング速度を求めた結果、VoiceOver には「空のウィンドウ」にしか見えないプロジェクトに対しては、この方式が少なくとも最低限の代替になるのではないかと思う。
だとすると、ゲームのように GPU でレンダリングされるすべてのコンテンツはアクセシブルではないということなのかも気になる。
iPhone で「GPT Explains」という Apple ショートカットを作っていて、背面を 2 回タップするとスクリーンショットを撮って OpenAI に送り、表示内容の説明、英語以外のテキストの英訳、ミームの主張への反論などを返すようにしてある。
API キーを抜いたコピーはこちら: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
新しいテキストエディタの流行に飛びつく前に、ユーザーが同意しなければならない ライセンスを一度見てほしいという意味で残しておく。
「Solution の使用中に生成されたユーザーコンテンツで構成される Customer Data は User Content に分類される。User Content は、Editor でプロジェクト共有を選択して他の Zed ユーザーと共同作業する場合にのみ、ユーザー環境から送信される。」
「[...] 当該 User Content への Zed のアクセスは、デバッグおよび Solution 改善に限定される。」
あえて解説はしないので、各自で結論を出してほしい。
コラボレーションのためにプロジェクトを他人と共有することを自分で選んだのなら、そのプロジェクトの内容が自分のマシンの外に送信されるのは当然だ。そうでなければどうやって動くのか。
この記事をきっかけに Zed を試してみたが、かなり有望に見えた。だが リモートホスト/devcontainer をサポートしていないので使えない
VSCode のこの機能は自分のワークフローの中核だ。実際のところ Mac 上で開発したいわけではなく、Mac は自分がコーディングする VM やコンテナへ入るためのポータルのように使いたい
プロジェクトの分離に大いに役立つし、実ホストマシン上に開発環境や依存関係を置かなくて済むので、セキュリティ面でも良い
普通のリモートセッションと比べて、VSCode のリモートホスト/devcontainer にはどんな利点があるのか気になる
開発者たちがさまざまな角度から開発をどう捉えているか、その考え方をよくのぞき込める素晴らしいインタビューなので強くおすすめする
ただ、一点だけ異論がある
「Zig 製テキストエディタにぴったりの名前はもう Zed に取られていた」ではなく、その名前は「Zag」だ ;)
zedにはedが入っている。edはex、vi、edlinの先行者であり、今も残る Unix 系の ラインエディタ だhttps://en.wikipedia.org/wiki/Ed_(text_editor)
一方で
ag、つまり the silver searcher も素晴らしいが、Zed はコード検索よりコード編集に近いと思うhttps://geoff.greer.fm/ag/
Zed は使っていないが、José Valim がライブコーディングで使っているのを見た。普段は VSCode を使っているが、Zed で見たある機能がかなり魅力的だった
「Find All」をすると、VSCode のように一致したすべてのファイルの断片が結果パネルに表示されるのだが、そこで 検索結果の断片を直接編集 でき、マルチカーソルのような通常の編集機能もそのまま使えた
VSCode では検索結果をクリックしてファイルを開き、そこで修正しなければならないので、かなりクールで印象的だった。乗り換えるほどではないが、VSCode にうんざりするたびにたまに思い出す
occurとmulti-occurがあり、こういうことができる。本当に素晴らしい最近では ripgrep のようなツールのインターフェースも 編集可能モード を提供していて、リファクタリングにとても便利だ。もちろんファイル名も一括編集できる
https://www.masteringemacs.org/article/searching-buffers-occ...
https://rgel.readthedocs.io/en/latest/
https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...
ばかげて聞こえるかもしれないが、VSCode の代わりに JetBrains を使う主な理由の一つは、ディレクトリを検索してナビゲーションパネルで開けることだ
このコメントを見て忘れていたことを思い出したので、また使ってみるべきだな
https://marketplace.visualstudio.com/items?itemName=jakearl....
自分が好きなコツの一つは、マルチカーソルで編集し、行末や次の単語への移動ショートカットを使って大量修正することだ
それを複数ファイルにまたがってできたらいいのに
Windows や Linux では動かない。対応したらまた知らせてほしい
素晴らしいインタビューだ
何を 磨き込みすぎるか について深く考えている点がよかった。自分の最高の仕事も、たいてい 2 回目、3 回目、4 回目あたりのラウンドで生まれていた気がする
設定をスクリプトとして扱う機能にはどんな計画があるのか気になる。まだ Zed はあまり使っていないが、今でも可能なのだろうか？ Neon のようなものが VSCode と昔の Atom ユーザーの間の溝を埋める助けになるだろうか？
https://github.com/neon-bindings/neon
— Brooks, Mythical Man-Month
v2 を見るのはいつも興味深い。機能過多で惨事になるケースも見たし、簡潔で引き締まって素晴らしくなるケースも見た
最近の Web アプリ分野にはツールがあまりに多いので、このリスクが v2 だけでなく v1 にも同じように当てはまるのか気になる。最近は v1 でも驚くほど肥大化しているものをよく見かけるし、あえて「少ないことをする」ツールを探さなければならないことが多い
Zedを使ってみたが、VSCodeに近いと感じた。Live Shareより優れたマルチプレイヤー機能があるのは分かるが、見た目だけでは乗り換えるだけの説得力がもう少し必要だった
ZedがXcodeを置き換えられるなら、もっと使ってみたいと思う。derived dataの削除やbuild folderの整理からランダムなクラッシュまで、Xcodeを使うのはつらい
Android Studioの開発者体験と比べるとまったく違う。iOS開発でもずっとAndroid Studioのような体験を求めてきた
ネイティブアプリは本当に好きだが、今はVS Codeに縛られている。VS Codeでカーソルの点滅にさえ電力がかなり使われているのを見るとつらい
Zedを少し使ってみたが、自分のワークフローには合わせられなかった。軽くて速い点は良かった。VS Codeのプロセス群は3GBほどだがZedは300MBなので、メモリ10分の1は意味のある差だ
ただ、VS Codeが提供するJupyter Notebook対応がどうしても必要で、MacからUbuntuボックスへリモート開発するやり方にも慣れすぎている。VS Codeはこれを非常にうまくこなす
Zedが十分長く持ちこたえて、自分のワークフローをサポートするようになることを願う
たぶんみんなもっと多くの拡張機能を有効にしているのだと思う
Lindy効果 https://en.wikipedia.org/wiki/Lindy_effect によれば、何かが見られるまでさらに1年はかかりそうだ
Aboutページを見たが、ライブコーディング機能は役に立ちそうだ。開発者たちもわくわくしていそうだ。アルゴリズムを使い、性能を最適化し、GPUプログラミングもできる面白いプロジェクトだからだ
だが、Vimとターミナルマルチプレクサの機能同等性におそらく永遠に到達できない、また別のテキストエディタを誰が必要とするのだろうかとも思う
VS Codeは比較的最近になって急に現れ、多くの人に使われているのだから、Vimの後にも新しいエディタのチャンスがあったことを示している
Zedがほかの開発者たちのロングテール需要を支えられるだけの勢いを得られるかは見守る必要があるが、ユーザー獲得を目指して競争する製品がもっと出てくるのはかなり楽しみだ
Vimを真似る必要はなく、Neovimとすべてのプラグインをそのまま活用できる
JetBrainsが、Vimユーザーから出来が悪いと言われるVimもどきプラグインをいまだに維持しているのは残念だ。IDEにNeovimフロントエンドをネイティブ実装すれば、「Neovimとそのエコシステムを完全にサポートする」という、はるかに強い利点になるはずなのに、今は「Vimっぽいプラグインがある」にとどまっている
気に入っていて、仕事を終わらせてくれる道具を使えばいい。Vimもその一つだが、Vimを使うことが代えのきかない祝福であるかのように振る舞うのにはうんざりしている
より良い思考者になることの方が、どんな道具よりもプログラマーとしての生産性を指数関数的に高めてくれる
すでにかなり機能が豊富で、人々が満足している、あるいは少なくとも慣れているエディタがある。新しいエディタはどこに居場所を見つけられるのだろうか？
「マルチプレイヤー」はクールだが、エッジケースに近い
ビジネスモデルにも確信が持てない。人々は本当にチャンネル、通話、チャットがコードエディタに統合されることを望んでいるのだろうか？ 個人的にはほとんど本能的に拒否感があるが、自分だけかもしれない