Rust歴7年の開発者がZigでJSONPathを再実装して感じたこと
What Zig felt like, coming from Rust
Rustを7年間使い続けてきた開発者が、RFC 9535準拠のJSONPathライブラリをZigで再実装した体験を語る。IDEサポートの薄さ、フラットなファイル構成、手動メモリ管理など、Rustとの違いを実例を交えて比較。関数型パラダイムの不在やallocatorの扱いに戸惑いつつも、CLI中心の開発スタイルやテストの書き方に新たな発見があったと振り返る。
Zigでは、イミュータブルとコンビネータに頼るRustとは対照的に、その場でのミューテーションと命令型の世界で最も自然なパターンへと押しやられた。
HNでの議論
241- csense
セクションの見出しの一つに「Mutation vs. immutable monad is the core difference」とあるが、これは正しくない。
そのセクションのコードは、その目的と大まかな流れが明確だ。「関数とデータを渡せ。データが裸なら関数をそれに適用し、データがコンテナなら中の各要素に関数を適用せよ」というものだ。
Zigでもイミュータブルなデータ構造でこれは完全に可能だ。ただ、関数にアロケータを渡す必要があるだけだ（つまり、data.flat_map(f) と呼ぶ代わりに、data.flat_map(a, f) と呼ぶ。ここで a はアロケータだ）。
Zig版のコードがミューテーションを行うのは、プログラマの選択の問題であって、言語によって強制されているものではない。
（それに、モナドがここで何の関係があるんだ？）
- Syzygies
様々な目的で、私はCやその候補となる後継言語（Go、Zigなど）を含む言語比較プロジェクトに取り組んでいる。一つの問いは、32ビットK&R Cで書かれた1980年代の数式処理システムをアーカイブ目的で移植するのにどの言語を使うかだ。Zigは素晴らしいデバッグコンパイラだが、アーカイブ目的の最適なターゲット言語となるにはまだ安定していない。
https://github.com/Syzygies/Compare
つまり、あなたは言葉が通じないレストランにいて、メニューも読めないが、名物料理のセット meal に3つの価格帯があるのが見える。（例えば、雲南の「過橋米線」など。）どれを選ぶ？私のツアーガイドである著者のフクシア・ダンロップは、後でこれが明らかだと同意してくれた。真ん中の選択だ。
つまり、あなたはK&R Cの後継候補としてGoとC23のどちらかを選ぼうとしている。どちらも「王族の血統」を持つ。一方が名前を得た。それ以上何も知らないとして、どちらを選ぶ？
答えは同じくらい明らかだ。名前を得た方には、欠点もついてきた。
- weinzierl
追加のポイントが2つある：
1. ツール（言及されたIDEサポートの点の延長として）。ZigとRustはどちらもツールが素晴らしいと称賛されており、それは正当だと思う。ZigのC/C++相互運用の話とクロスコンパイルの話は素晴らしい。しかし、実務家の立場からすると、Rustの方がずっと進んでいると思う。Zigがずっと若いことを考えれば驚くことではないが、心に留めておくべきことだ。
2. コンパイル時の機能：ここではZigが称賛され、Rustはあまり評価されていない。これは不当だと思う。Rustはコンパイル時機能に対してはるかに高い目標を持っている。つまり、コードがいつ実行されても結果が同一でなければならないというものだ。これは非常に有用な特性だが、タスクをはるかに難しくし、Zigのcomptimeとは根本的に比較できないものにしている。
- jauco
著者がhelixを使っていることと、zigがより大きなファイルを推奨していることに触れているので、helixでこれらのファイルをどうナビゲートしているのか興味がある。私がhelixを使わない理由はコード折りたたみがないことだ。大きなファイルをナビゲートするときに、全体を俯瞰するために頻繁に使っていることに気づく。
- plqbfbv
私はプログラミングにそれほど深くないのかもしれないが、Zigの hype が理解できない？
Rustを少し書いたことがあり、専門家とは言えないが、私の見解ではRustはコンパイル時のメモリ管理問題をGCなしでほぼ解決しており、非常によく機能する。これまで何度も繰り返し見てきた最大の欠点とコストは「コンパイルが遅い」というもので、250クレートを超えると最終的な--releaseリンクが目立つようになるのは分かるが、インクリメンタルコンパイルの改善もあった。
一方、この記事の構文を見ると、ZigはJavaScript、Python、Goの構文を混ぜたように感じられ、依然としてメモリ管理が必要だ。つまり、Cのすべての問題を継承した、より書きやすいCなのか？記事からは、関数型プログラミングなし、データの変更、メモリリーク、二重解放、メモリ破壊。
個人的には、これが他の選択肢なら、毎回最終リンクに数分かかる方を選ぶ。
- spider-mario
> 最初に面食らったのは——正直、これが記憶に残る部分になるなんて誰が予想しただろうか——IDEサポート、あるいはほぼ完全に欠けていることだった。
それは完全に予想していただろう。
- tialaramex
2020年代を振り返るとき、私たちはアロケータへの執着に驚かされるだろう。
Handmadeの「C後継」言語はすべてこの執着を持っているようだ。Zigだけでなく、Odin、C3、Jaiも含めて。
いくつかの玩具問題では、巧妙なアロケータトリックで巨大なパフォーマンス向上が得られる。例えば、JaiとOdinはどちらも、定期的に「フレームごと」のアリーナを捨てることができるコードを書くことを本当に望んでいるようで、アリーナ内の割り当てを追跡するコストを払わないようにしている。なぜならそれらはすべて同時に捨てられるからだ。
しかし、多くの実世界のソフトウェアはそれほど単純ではない。これはそのような機能が無価値だというわけではなく、経験豊富な開発者がツールキットに欲しいと思う千のツールの一つに過ぎず、見出しになるほどの価値はないということだ。
- elendilm
> 単純なCLIツールに頼ることがどれほど簡単か、すっかり忘れていたようだ。
よかったね。
CLIツールは直感に反して、特に非常に速く動いているときには、摩擦が非常に少ない。