Rust歴7年の開発者がZigでJSONPathを再実装して感じたこと
What Zig felt like, coming from Rust
Rustを7年間使い続けてきた開発者が、RFC 9535準拠のJSONPathライブラリをZigで再実装した体験を語る。IDEサポートの薄さ、フラットなファイル構成、手動メモリ管理など、Rustとの違いを実例を交えて比較。関数型パラダイムの不在やallocatorの扱いに戸惑いつつも、CLI中心の開発スタイルやテストの書き方に新たな発見があったと振り返る。
Zigでは、イミュータブルとコンビネータに頼るRustとは対照的に、その場でのミューテーションと命令型の世界で最も自然なパターンへと押しやられた。
HNでの議論
316- torginus
個人的には、Rustについてはある程度現実主義的な立場なのだが、現在他のどの言語も埋めていないニッチを埋めていることは認めざるを得ない。つまり、高性能でランタイムメモリ安全性を持つ言語というニッチだ。
メモリ安全性と言っているのは、基本的な「クラッシュや破壊が起きない」というバージョンの話で、これはJavaやGoなどが実現しているが、C++やZigは実現していない。
私はC++開発者でもあるのだが、経験上はっきり言えるのは、C++を初心者開発者（スマートポインタを正しく使うような人でも）に渡して、メモリ関連のクラッシュや問題が一切ないアプリを期待するのは無理だということだ。
この理由だけでも、私は一般的にC/C++/Zigは典型的なプロフェッショナルなプロジェクト/アプリケーション（最近では通常GC言語で書かれる）向けの言語だと思っている。
これは厳しい線引き基準だと思う。ほとんどのプログラマーや組織は、メモリ安全でないソフトウェアでは単純にやっていけない。商用のC++コードベースのほとんどはリークしている。
これは基本的にソフトウェア開発において最も重要で一般的な「ニッチ」なのに、なぜかある程度無視されてきた。そして私はRustがここに完璧に適合するとも思っていないが、除外するような欠点は何もない。
Swiftももう一つの良い選択肢だろうが、この言語はAppleエコシステムに非常に縛られているようだ。
（Apple以外で）こうした人々が正確に何を求めているかを理解していた唯一の言語は、90年代から2000年代初頭のObject Pascal/Delphiだったと思うが、残念ながら廃れてしまったようだ。
- Syzygies
私は様々な目的で、CやGo、Zigといった後継候補を含む言語比較プロジェクトに取り組んでいる。一つの問題は、32ビットK&R Cで書かれた1980年代の数式処理システムをアーカイブ目的で移植する際にどの言語を使うかだ。Zigは優れたデバッグコンパイラだが、アーカイブ目的の最良のターゲット言語になるにはまだ十分に安定していない。
https://github.com/Syzygies/Compare
さて、あなたは言葉が通じないレストランにいて、メニューも読めないが、名物を使った定食に3つの価格帯があるのが見える。（例えば、雲南の「過橋米線」など。）どれを選ぶ？私のツアーガイドであり著者でもあるフクシア・ダンロップは、後で私にこれは明らかだと言った。真ん中の選択肢だ。
つまり、K&R Cの後継候補としてGoとC23のどちらを選ぶか。どちらも「王家の血統」を持つ。一方が名前を得た。それ以上何も知らないとして、どちらを選ぶ？
答えは同じく明らかだ。名前を得た方は、欠点も得たのだ。
- csense
セクション見出しの一つに「Mutation vs. immutable monad is the core difference」とあるが、これは正しくない。
そのセクションのコードは目的と大まかな流れが明確だ。「関数とデータを渡してくれ。データが裸なら関数をそれに適用し、データがコンテナなら中の各項目に関数を適用する。」
これはZigでも不変データ構造で完全にできる。単に関数にアロケータを渡せばいいだけだ（つまりdata.flat_map(f)を呼ぶ代わりに、data.flat_map(a, f)を呼ぶ。ここでaはアロケータ）。
Zig版のコードがミューテーションを行うのはプログラマーの選択であり、言語によって強制されているものではない。
（それに、モナドがここで何の関係がある？）
- weinzierl
追加の2点：
1. ツール（言及されたIDEサポートの点の延長として）。ZigとRustはどちらもツールが称賛されていて、それは正当だと思う。ZigのC/C++相互運用とクロスコンパイルの話は素晴らしい。しかし実務家の立場からすると、Rustの方がずっと進んでいると思う。Zigがずっと若いことを考えれば驚きではないが、心に留めておくべきことだ。
2. コンパイル時機能：ここではZigが称賛され、Rustはあまりそうでない。これは不当だと思う。Rustはコンパイル時機能に対してはるかに高い目標を持っている。つまり、コードがいつ実行されても結果が同一でなければならないというものだ。これは非常に有用な特性だが、タスクをはるかに難しくし、Zigのcomptimeとは根本的に比較できないものにしている。
- computerfriend
> Zigは、それに比べてシンタックスハイライトと基本的な自動補完以外はほとんど提供していなかった。
Zigには言語サーバーがあり、「LSP機能の大部分がサポートされている」(https://github.com/zigtools/zls#features)。
- Panzerschrek
> Rust：Dropはスコープ終了時に自動で実行されるので、この特定のバグは単に存在しない。
だから自動デストラクタがないのは行き止まりなんだ。これはZigやOdinのような言語の最大の過ちだ。
- plqbfbv
私はプログラミングにそれほど深くないのかもしれないが、Zigの熱狂が理解できない？
Rustを少しやったことがあり、専門家とは言えないが、私の見解ではRustはメモリ管理の問題をコンパイル時にGCなしでほぼ解決しており、非常によく機能する。これまで繰り返し聞いてきた最大の欠点とコストは「コンパイルが遅い」ことで、それは理解できる。250クレートを超えると最終の--releaseリンクが目立つようになるが、インクリメンタルコンパイルの改善はあった。
一方で、この記事の構文を見ると、ZigはJavaScript、Python、Goの構文を混ぜたように感じられ、それでもメモリ管理が必要だ。つまり、Cのすべての問題を継承した、より書きやすいC？記事から：関数型プログラミングなし、データのミューテーション、メモリリーク、二重解放、メモリ破壊。
個人的には、これが他の選択肢なら、毎回最終リンクに数分かかる方を選ぶ。
- sharktheone
> 最初に面食らったのは——そして正直、これが記憶に残る部分になるなんて誰が予想しただろう——IDEサポート、あるいはそのほぼ完全な欠如だった。
そう、これは私も初めてZigを試したときに驚いた。
ZLSは存在するが、最後に使ったときは不安定で頻繁にクラッシュした。
小さなおもちゃのJVMを書いた。興味があれば：https://github.com/Sharktheone/yeeeeem
- tialaramex
2020年代を振り返るとき、私たちはアロケータへの執着に驚かされるだろう。
Handmadeの「C後継」言語はすべてこの執着を持っているようで、ZigだけでなくOdin、C3、Jaiもそうだ。
おもちゃの問題では、賢いアロケータのトリックで大きな性能向上が得られる。例えばJaiとOdinはどちらも、定期的に「per-frame」アリーナを捨てることができるコードを書くことを強く望んでいるようで、アリーナ内の割り当てを追跡するコストを払わないようにしている。なぜならそれらはすべて同時に捨てられるからだ。
しかし現実世界のソフトウェアの多くはそれほど単純ではない。これはそうした機能が無価値だという意味ではなく、経験豊富な開発者がツールキットに欲しがる千のツールの一つに過ぎず、見出しになるほどではないということだ。
- janden
このような記事を読むと、自分が何をしているのか全く分かっていないことがよく分かる。そしておそらく永遠に分からないだろう。