Go言語はAI支援ソフトウェア開発に最適な理由

コンパイラがLLMによる変更の結果としてソフトウェアの別の部分を誤って無効な状態にするのを防げないなら、LLMがGoを書くのがどれだけ得意かは私にとって重要ではありません。

何を言っているのか？Goでは、nilや部分的に構築された構造体の生成を防ぐことは不可能です。

確かに、範囲が限られた小さなプログラムなら、目をつぶって見ればおそらく大丈夫でしょう。しかし、私が働くチームは、広大で進化し続けるソフトウェアに取り組んでおり、コンパイラが「ねえ、それは有効なWidgetではないよ」と言ってくれると非常に役立ち、多くの心痛を救ってくれます。

LLMは他の使用箇所を「チェック」し、すべてが正しく機能するかどうかを「チェック」するのに優れていますが、おそらく私たちはコンパイラが実際に検証できるようにコードに概念を委ねているはずです。そしてGoは意図的に構造体の無効な状態を許可しています。これにより、GoはLLMがあろうとなかろうと、私がチームと取り組む種類のソフトウェアにとって根本的に問題のある言語選択となっています。

このブログ投稿がやろうとしている手品が大好きです。Goが書いていて楽しくないのは、AIがやってくれるから問題ない、ということですね！ええ、過去20年間それが嫌だったのは？主な主張は、Goはソフトウェアエンジニアリング全体として優れているので、プログラミング言語としての弱点が最小化されるというものですね。コーディングエージェントが他のソフトウェアエンジニアリングの側面に負担を移すという同様の議論を私もしたことがあります。しかし、私たちは皆、Googleがここで何をしようとしているか見えていますよね？彼らはルールが変わったと宣言して、Goの弱点が強みに変わるようにしたいのです。私はそれを信じていません。

これはGo言語の作者以外の誰かから出ていたら、もっと信憑性があったでしょう。

私は個人的にLLMにはRustを選んでいます。あの細かいコンパイラとコンパイル時に表面化するエラーは、LLMにとって理想的だと思います。コンパイルをトークンで叩く方が、実行時にどこで失敗するかを推測してテストで捕捉しようとするよりもはるかに優れた戦略です。

トークンは安価ですが、実行時の驚きは高価です。だから、超細かいコンパイラが欲しいのです。私はLean4も論理的な次のステップとして検討しましたが、LLMをそのために十分に導ける自信はありません。

私は同意しません。

LLMは非常に単純なケースでもバグのない並行コードを生成できません。

Goにはまともな抽象化を構築する能力が欠けており、自明ではないマイクロサービスに必要な追加ツールやライブラリの無法地帯は言うまでもありません。

私にとっては、LLMが人々により多くの悪いGoコードをより速く生成できるようにするのは危険信号です。これは、Goで些細な問題を解決するために必要な過剰なコードをレビューできる十分なソフトウェア開発者を雇える企業にとってのみ最適化です。それらの問題は、まともなプログラミング言語やフレームワークには組み込まれています。

LLMを使い、正しいプログラミング言語を使いましょう。それはGoかもしれませんが、おそらくC#、Java、Python、Ruby、あるいはPHPでしょう。（またはRust、C、D、...）

最近の私の判断基準は非常にシンプルです：

パフォーマンスを気にするならRust。

開発速度を気にするならTypeScript。

スクリプトや数値計算が必要ならPython。

LLMはRustと相性が良いです。なぜなら、より表現力豊かな型システムが、特にマルチスレッドコードを書く際に強力なガードレールを提供するからです。GoはLLMにとってほぼ最悪のプログラミング言語設計です：強力だがガードレールが弱い。CとC++だけがもっと悪いでしょう。

LLMは人間のように低レベルのライフタイムに苦労しません。彼らは限られたコンテキストウィンドウのために高レベルのビューに苦労します。だからこそ、グローバルな制約を強制する強力な型システムが必要なのです。Goはそれには該当しません。

私はGoが好きですが、これらの「利点」のいくつかは、エージェントの規模と典型的な使用パターンを考慮すると薄れてしまいます。

| Goは読みやすい / Goは保守しやすい

Goは魔法が少ない言語であり、プロジェクト間で非常に似たような見た目になる傾向があるのは事実で、依存関係のソースコードを確実に理解するのに素晴らしいです。そしてそのツールはワールドクラスです。私はこの点が大好きです。

しかし実際には、複数のチームでモノレポで作業していると、クロスチームの可読性を優先しない貢献者はとにかくずっと多くのコードを書くことがわかりました。そしてビジネスロジックでは、コードを行ごとに読めるという事実は、広いコンテキストを理解していなければ、何かが遠隔作用を引き起こすかもしれないことを知る助けにはなりません。

エージェント以前から、私は大部分を頭の中で保持できたコードベースから、大部分が書き直されて私には認識できないものへの急速な移行を目撃しました。今やエージェントが登場し、彼らはまだ大規模なソフトウェアエンジニアリングが得意ではないため、逆方向への意識的な努力がなければ、コードベースにおける知識負債（そしてもちろん技術負債）の蓄積プロセスは10倍に加速します。Goが読みやすいということは、本質的にそれを助けにはなりません。

Goは「パレートフロンティア」上にないと主張します。プログラミング言語のさまざまな属性をどう評価しても、公正な評価は決してGoを選ばないでしょう。

簡単な例：言語の人気を重視するなら、Goは最も人気があるわけではありません。エラーを捕捉する型システムを重視するなら、Goの型システムは他のものよりも捕捉するエラーが少ないです。などなど。Goを選択する属性の加重和は存在しません—それが私の主張です。

私はこれらの言語固有の宣言を何度も見てきましたが、それらは迷惑で、未熟さがにじみ出ています。

私はZigでLLM支援コーディングを楽しんでおり、それは仕事で行う一般的なTypeScript/Reactと同等のようです。

シンプルさと優れたプログラミング言語設計が利益をもたらすことは疑いませんが、みんなのお気に入りの言語が新しいLLM世界の銀の弾丸であるはずがありません。物事はうまくいきません。Erlang、Gleam、Lisp、C、Rust、Go、TypeScript、Pythonなどで同じ主張を見続けています。

そしてGoを少し批判すると、GoにはLLMにとって優れている独自の品質はないと思います。コンパイラを活用し、より多くの正しさの保証を強制する新しい機能を提供する他の現代言語については、その主張ができるかもしれません。

私はどこかのプロダクトマネージャーやチーフエバンジェリストからの言語アドバイスは受け入れません。特にGoogleからのものはなおさらです。

そうは言っても、私の意見では、LLMはタイトなループで動作することで成長します。人間とは異なり、彼らはより多くの、より厳しい制約で成長します（そしてより良いモデルは明らかにこの点ではるかに優れています）。

私は人間の限界のためにコードを書きやすくしたものを捨て、LLMがより良い結果のために活用できるものを受け入れたいと思います。私にとってそれは：特に豊かな型システム、（理想的には純粋な）関数型コード、効率的なシステムレベルのパフォーマンスと軽量さ。LLMを段階的に導く良いエラーメッセージ。

Goはそれらの3つの欲求の多くを提供しないので、逸話だけで「理想的」と呼ぶのは説得力がありません。