C言語の代替品はなぜ失敗するのか 「より良いC」では不十分
The case against a C alternative (2022)
C言語の代替を目指す言語が数多く登場しているが、それらがCに取って代わるのは難しいと筆者は論じる。その理由として、CのツールチェーンやABIの優位性、新言語の不確実性、開発者不足などを挙げる。さらに「より良い構文」「より安全」「生産性向上」といった利点は企業にとって決定的な価値にならず、重要なのはCにはない「キラー機能」を持つことだと主張する。Javaが登場時に8つの独自機能で普及した例を挙げ、C代替言語が成功するには、Cでは実現できない独自の製品や機能が必要だと結論づける。
「どんなに魅力的なCの代替言語でも、おそらく失敗するだろう」
HNでの議論
77- friendzis
この記事の中心的な議論は、鶏が先か卵が先かという類のものだ。
> 4. 経験豊富な開発者がいない
うーん、C言語では、C言語に精通した経験豊富な開発者が必要だ。コンパイルは通るが、さまざまな形で間違っている、たいていは微妙に間違っているCコードを書くことはできる。正しいコードを書くのを手助けしてくれる、あるいは間違ったコードをコンパイルしようとしない（ここでRustをほのめかしている）新しい言語は、この卵を少し割ってくれる。
> 対象とするニッチなプラットフォームがあるなら、おそらくC言語を使うことを前提としている。
一部の（おそらくほとんどの）ニッチなプラットフォームは、GCCのフォークを提供している。LLVMを使えば、フロントエンドの重要性はますます低くなる。この特定の鶏と卵の問題は、C言語の後継があるなしにかかわらず、打ち破られつつある。
> どんなC言語の代替品も、C言語と同等のパフォーマンスを持つことが期待されるだろう。問題は、C言語には実質的にチェックがないため、競合言語に組み込まれる安全性チェックには実行時コストがかかり、それがしばしば許容できないということだ。これは、「安全」モードでのみチェックを行うという戦略につながる。「高速」モードはC言語と同じくらい「安全でない」。
この議論は循環している。確かに、アセンブリのマクロシステムを使って変なことをしなければならないシナリオもあるが、それは通常、プロジェクト全体の中では比較的小さな部分だ。アンセーフモードはこの小さなニーズに対処するのに役立つ。この議論は、プロジェクトの一部にC言語的な言語が必要だからといって、プロジェクト全体にC言語的な言語を使う必要があるかのように読める。
> 3. プログラマーの生産性
この議論全体が奇妙に焦点を絞っている……
- palata
私にとって、C言語の価値は相互運用性のストーリーだ。
C言語をこの目的で置き換えられる、ABIの安定性を持つ現代的な言語はあるだろうか？つまり、C言語のAPIを持つものなら何でもラップして、他のどの言語からでも簡単に呼び出せると確信できるような言語は？
- leni536
全体的に説得力のない議論だ。ほとんどが「どんな新しい言語も、最初は新しく未成熟なものから始まる」という点に帰着する。C言語の設計空間における「キラー機能」を軽視している。C言語の代替としてすでに確立されたC++があることを無視している。
しかし明らかに、C言語が存在しなくなるという意味で、C言語に取って代わるものは何もないだろう。
- netdur
私もある意味で罪を犯している。私はC+という新しいプログラミング言語を始めたが、その柱の一つとして、C言語（または他のどの言語）の代替にはならないと決めた。実際、コンパイラとしてClangを使っている。記事の指摘の多くは依然として当てはまるが、この分野で新しいアイデアを思いつき、実際に実装する人々を止めるものではないことを願っている。次に大きなものになる必要はない。素晴らしいことであり得るからだ。
- hanneshdc
> 問題は、C言語には実質的にチェックがないため、競合言語に組み込まれる安全性チェックには実行時コストがかかり、それがしばしば許容できないということだ。
この問題は誇張されている。ここに安全性とパフォーマンスのトレードオフはない。Rustは、広範な安全性チェックをコンパイル時に適用でき、実行時オーバーヘッドがゼロであることを示している。
具体的な例として、配列アクセスが範囲内であることを実行時にチェックすることには、確かにパフォーマンスのペナルティが伴う。しかし、配列インデックスが決して配列の境界を超えないことをコンパイル時に証明することも可能だ。そして、それを静的に証明できないのであれば、そのコードのセキュリティを真剣に疑問視すべきだ。