LLMが「難しい言語」への扉を開く：RustやZigが選ばれる理由
Fast and Hard Code
LLMの登場により、プログラミング言語の選択は以前ほど重要ではなくなり、開発者は馴染みのない言語でもエージェントにコードを書かせられるようになった。その結果、高速で小さなソフトウェアを求める動きが強まり、RustやZigといった「難しい言語」を選ぶプロジェクトが増えている。CloudflareのArtifactsやVercelのfxなどがその例で、これらはLLM支援で開発されている。また、DWARFやeBPF、カスタムネットワークドライバといった高度な技術にも開発者が挑戦するようになった。
LLMのおかげで、言語の選択は以前よりもはるかに重要ではなくなった。
HNでの議論
79- qsera
> 突然、人々がDWARFファイル、eBPF、カスタムネットワークドライバ、カスタム暗号、そして非常に古いコンピューティングハードウェアで本当に印象的なことをやっているのを見るようになりました。これらの多くは以前は多くの開発者にとって手の届かないものでした。場合によっては（例：暗号）、知識のある人々によって意図的にゲートキープされていたため、押しのけられさえしました。
以前は、少なくとも一部の人は物事を理解することを強いられました。なぜなら、理解なしには本当にやりたいことをすることができなかったからです。そして、そのうちの何人かは情熱を持って掘り下げ続け、経験に基づいてさらに優れたものを作り上げることさえできました。
今では誰も何も理解する必要がなく、そして今後、より優れたものを作ることは決してないでしょう。
- willtemperley
ある程度はその通りだと思いますが、それはLLMがそのトピックについてどれだけの情報を持っているかに大きく依存します。
数学は最初からオープンソースだったので、彼らは数学が驚くほど得意です。同様の理由でアルゴリズムも得意です。Cバインディングは、先行する芸術が非常に多いため、簡単です。しかし、言語の最先端の機能を使うのは、まだデータが少ないため苦手です。
これに基づいて、彼らが何が得意かを予測するのはかなり簡単だと思います。UIデザインがなぜ苦手なのかはわかりませんが。
- noduerme
暗号について詳しくない者として、"カスタム暗号"という言葉だけでぞっとすることを知っています。
- superjose
それは場合によると思います。
ソフトウェアが進化し、使用される程度によります。
私たちが何年もかけてパターンを発見し、特別な構文を作り出してきた理由は、特定のドメインの問題により効率的に対処し、時間とともに進化できるシステムを持つためです。
唯一不変なのは変化です。
LLMはコードを生成しますが（そして非常に印象的な出力を生み出しますが）、開発者は一定のしきい値を超えるためのノウハウを持っていなければなりません。
未知の言語で書くことは最初はうまくいくように見えるかもしれません。しかし、限界に達すると、LLMが根本から取り除くのではなく回避するかもしれない、特定の癖や非効率性に遭遇するでしょう。
例えば、私はここ数週間Effect.tsを学んでいます。LLMを多用しましたが、その前に一連の手動コーディングのラウンドがありました。
構成可能性、細部、どこで壊れるか、どのように、構文がどのように形成されるか、そしてライブラリに関する観測可能性の課題をどのように構造化できるかを理解するために。
そのプロセスを経ていなければ、コードの品質は標準以下だったでしょう。最初は明らかではなかったかもしれませんが、システムが進化し、フィードバックに適応し始めると、物事はもろくなり、既存の顧客に影響を与えるなど、問題が発生していたでしょう。
私は物事を壊さずに速く動くのが好きです。
- jbstack
> 言語に慣れるという行為はもはや重要ではないということは明らかです
この記事の前提として、私はこの発言に完全に反対します。
確かに、エージェントの作業が信頼できるかどうかをまったく気にしないのであれば、言語を学ぶ必要はありません。しかし、自分の仕事を気にかけていて、100%バイブスコードを出力するだけではない開発者であれば、少なくともエージェントの出力をレビューし、コードに追従し、コミットするかどうかについて情報に基づいた決定を下せる程度には、その言語に精通しているべきです。
興味深いことに、言語の学習に対する私のアプローチは根本的に変わったことに気づきました。以前は、その時点で自分にとって重要な1つか2つの言語についての本を勉強していました。目標は熟達することでした。今では、単に私にとって新しい興味深いパラダイムを示しているという理由で、さまざまな言語について読むことを選びます（例：Haskell -> 関数型、Elixir -> 並行性）。プログラミングの本を、魅力的なノンフィクションの物語を読むように読みます：比較的速く表紙から裏表紙まで読み、それで終わりです。これにより、エージェントコーディングに役立つ「親しみ」が得られますが、すべての難解な構文やライブラリ呼び出しを学ぶ手間は省けます。私の優先事項は、深さ（1つか2つの言語を本当に上手に学ぶ）ではなく、広さ（多くの言語とパラダイムの概要を得る）になりました。