発生日：2025年8月22日。
Goプログラミング言語に対する新たな批判が注目を集めているのは、新しいバグを発見したり代替言語を提案したりしたからではなく、Goの簡潔さには当初から不必要なコストが伴っていたのかという長年の論争を改めて取り上げたためだ。2025年7月に発表され、より広範な開発者の議論で再浮上した論考で、トーマス・ハベッツは、変数のスコープからリソースの解放、移植性に関する癖、メモリ効率に至るまで、この言語には今なお複数の基本的な点で不足があると主張している。[出典16848]
この記事は明確に意見記事であり、提供された証拠もそのように報じることを裏付けている。ハベッツは10年以上にわたってGoを批判してきたと述べ、今回の投稿を一時的な反応ではなく、その主張の継続として提示している。彼の中心的な不満は、Goの問題点の多くが状況によって強いられた困難なトレードオフではなく、ソフトウェア業界がすでに回避方法を知っていた設計上の選択だったというものだ。[出典16848]
抜粋にある最も具体的な例の一つは、変数のスコープとエラー処理に関するものだ。ハベッツは、Goでは多くの場合、`err`変数が必要以上に長く有効なまま残るため、経験豊富なプログラマーであっても、スコープ外にあるように見える値が後で再利用されていないか立ち止まって確認しなければならず、コードが読みにくくなると主張する。彼の見方では、これは単なる構文上のいら立ちではなく、バグを探すためにコードを読む際、繰り返し曖昧さを生み出す要因である。[出典16848]
論考は構文からシステムの挙動へと議論を広げている。ハベッツは、Goにおける`nil`の扱い、ファイルコメントを介した条件付きコンパイル、リソース解放を`defer`に依存している点を批判する。より統一的なパターンに頼るのではなく、どのオブジェクトに明示的な解放が必要で、その解放がどのように動作するかを開発者が覚えておくよう強いられていると主張している。抜粋ではまた、この言語は従来の意味での例外を持たないものとして売り込まれることが多いにもかかわらず、Goプログラマーは依然としてパニックが発生しても安全なコードを書かなければならないとしている。ハベッツにとって、この不一致は、自身がより使いやすいと考えるモデルを提供しないまま、例外型の制御フローが持つ欠点に開発者をさらしている。[出典16848]
批判の別の部分では、データ処理とインフラコストを扱っている。ハベッツは、自身の経験を踏まえ、任意のバイナリデータを文字列として扱うことが、UTF-8ではないファイル名を巡る気付かれないデータ損失の一因になり得ると述べている。また、メモリ使用量はもはや深刻な懸念ではないという考えにも反論し、メモリがコストへ直接転換されるクラウド環境やコンテナが高密度で展開される環境では、RAMは今なお重要だと主張する。抜粋によると、Go版のメモリ消費量が時間とともに増えたため、一部のサービスを別の言語で書き直したことさえあるという。[出典16848]
提供された証拠では、こうした主張のいずれについても独立したベンチマーク検証はなく、Goのメンテナーによる反論もない。そのため、通常のニュース報道として踏み込める範囲には限界がある。確実に裏付けられているのは、広く受け入れられているGoの側面が、ベテランのシステムプログラマーの視点から見るとなお設計不良であると主張する、詳細かつ辛辣な批判が強い反響を呼んだということだ。
したがって、この投稿の重要性は技術面と同じくらい文化面にもある。Goはクラウドツール、バックエンドのインフラ、開発者向けプラットフォームに深く定着している。そうした状況で発表された批判的論考は、この言語が失敗していることを証明するものではないが、Goで称賛されるミニマリズムが明快さなのか、それとも積み重なった妥協なのかを巡る議論が、普及によって決着してはいないことを浮き彫りにする。ハベッツの答えは明白だ。業界はもっと良い方法を知っていたのに、Goには今なおその問題が表れている。[出典16848]
