Rustはエージェント開発に最適だが、まだ改善の余地がある
What agents mean for Rust (and vice versa)
LLMの台頭でプログラミング言語設計者の役割はどう変わるのか。著者は、エージェントによるコーディングがRustの型システムやガードレールと相性が良いと主張する。型チェックがエージェントを正しい方向に導き、証明システムと組み合わせることで、安全性を保ちながら性能を追求できる。Rustは「コンパイルが通れば動く」という信頼性をさらに強化すべきだという。
型システムはバグの不在を示せるが、正しさの存在は示せない。
HNでの議論
52- gregwebs
Rustには一つ際立った弱点がある。コンパイル時間だ。LLM時代には、Rustが達成したものを高性能と優れた型安全性で実現しつつ、高速コンパイルもより良くサポートする言語、あるいはRustの再設計のようなものが台頭してくるのではないかと思う。
RustのコードベースでVerusの証明を書くのにエージェントは優れているとわかった。しかもこれらの証明は通常のコンパイル経路にほとんど悪影響を与えない。Verusを使うためのスキルを公開している: https://github.com/gregwebs/skills-sdlc/blob/main/skills/rus...
- kubb
Haskellのような「難しい」言語がLLMによって復権するのではないかと思う。言語を学ぶ短期的なコストは、型システムやより良い構造による長期的な利益と比べて、もはやそれほど重要ではないからだ。
- xscott
一度立ち止まって、LLMがコードを書くのに役立つ、あるいは害になるプログラミング言語の機能をリストアップしてみるべきだと思う。完全なリストはないが、考えたことを挙げる：
コンパイル時の役立つエラーメッセージ
エラーを反復して修正するための高速コンパイル
実行時の効率的なメモリ、CPU、そしておそらくGPU
トレーニングデータに馴染みがあること [0]
一つの明白な／好ましいやり方
明示的な型
Rustはこれらのいくつかを満たしているが、すべてではない。すべてを満たす言語は思い浮かばないが、多くの人は自分のお気に入りの言語が最良の選択である理由を正当化するのが大好きだ。LLMはシンタックスシュガーやその他の便利機能を必要としないし、実行時まで先延ばしにされたエラーはモデルではなくあなたの負担になる。
結果への信頼性を高め、将来の変更やモデルの切り替えをより良くするために、あまり見かけない機能をいくつか追加することもできる：
必須の事前条件と事後条件
関数やメソッドの長さの強制制限
必須のテストケース
強制された命名規則
Leanスタイルの正しさの証明？ （おそらくない）
メモリ管理のための線形／アフィン型とガベージコレクションのどちらが良いかについては決めかねている。明らかにメモリ安全性は欲しいが、それを得る方法は一つではないし、単純なデータ構造を構築するために無理な歪みを強いるべきかどうかはわからない。
[0] LLMはこれまで見たことのない言語でのプログラミングも非常に得意だ。自分のおもちゃのコンパイラを使ってプログラムを書かせたこともある […]
- Depurator
Rustを書き始めて6年ほどになるが、LLMが登場する前に始めて、借用チェッカーなどと格闘しなければならなかったことをとても嬉しく思っている。
今ではRustとLLMで非常に生産性が高く、新しい言語に書き直す必要がないとわかっているのも心地よい。Rustはすでに最高だ。
有名なスウェーデンのコメディアンがヘロインを「最高のドラッグ」と語っていた。人々が普通に行き着き、やめたくなくなるものだ。
- antoineMoPa
最近、エージェントとRustでいくつかのアプリを「コーディング」していて、target/フォルダが恐ろしく巨大になりうることに気づいた。そしてcargo cleanを実行すると、ディスクはきれいになるが、コンパイルはまた永遠にかかる。定期的にディスク容量が足りなくなる。
全体的にはこの体験が大好きだが、その部分だけは除いて。