■ 1. C代替言語の現状
- 乱立するC代替言語:
- 自身もC3というC代替言語を開発中であり、他にZig、Odin、Jai、eCといった言語が存在する
- C++の代替に目を向ければD、Rust、Nim、Crystal、Beef、Carbonなどがある
- 本稿の問い:
- Cを置き換えることは本当に可能なのかを、反対側の論拠から検討する
■ 2. Cを捨てられない理由
- Cのツールチェーン:
- Cは言語そのものだけでなく、開発された全ての開発者向けツールを含む存在である
- 静的解析、メモリリーク検出、データレース検出などのツールが多数開発されている
- 新言語が標準でより良いツールを備えていても、Cのツール群の厚みには及ばない
- マイナープラットフォームへの対応:
- 特殊なプラットフォームを対象とする場合、Cが使われる前提になっている可能性が高い
- Cが今日のコンピューティングの共通語である地位:
- ツールを書く価値が高いため、多くのツールが継続的に生み出されている
- 乗り換えコストの壁:
- 動作しているツールチェーンがあるなら、言語を変える危険を冒す理由がない
- 「より良いC」は新たなツールチェーン構築の時間に見合う生産性向上をもたらす必要がある
- 新言語の不確実性:
- 成熟前の言語はバグを抱えやすく、意味論上の問題解消のため大きく変わる可能性がある
- 「高速なコンパイル」「Cより速い」といった宣伝が、機能追加に伴い達成困難になる場合がある
- メンテナの継続性リスク:
- オープンソースならフォークできるが、将来自社で保守を強いられる言語を使いたい企業は少ない
- 新言語に賭けることは大きなリスクである
- 言語が十分に良くない可能性:
- Cの本当の痛点に対処しているとは限らず、痛点が何かについて人々の意見は一致しない
- メモリ確保、配列、文字列の扱いは厄介だが、適切なライブラリと健全なメモリ戦略で最小化できる
- 上級者が気にしない問題を解いているなら、実際の価値は期待よりはるかに低い
- C固有機能の欠落リスク:
- Cの上級プログラマが依存する重要な機能を、新言語が省いてしまう危険がある
- 設計者がCの使用経験に乏しくC++やJavaの出身である場合、この危険は高まる
- 経験ある開発者の不在:
- 新言語は経験者の母数が小さく、中規模以上の企業にとって重大な問題となる
- 企業は採用可能な開発者が多いほど好むものである
- C開発者の採用経験はあっても、新言語での採用方法は分からない
- 相互運用の標準としてのC ABI:
- Cコードを容易に呼べない、あるいは呼ばれない言語では、外部コードとの接続の度に追加作業が生じる
- これは潜在的に極めて大きな不利である
■ 3. 「Cより良い」は決め手にならない
- 言語設計者の過大評価:
- 追加した機能がもたらす利点の大きさを、設計者はしばしば過大に見積もる
- より良い構文:
- Cより優れた構文かどうかは大部分が主観の問題である
- 構文が異なること自体が大きな不利であり、Cからコードを流用できず全行の書き直しが要る
- 構文がわずかに良いという理由で言語を採用する企業は存在しない
- Cより安全:
- C代替言語は性能面でCと同等であることを当然に期待される
- Cには実質的に検査が存在しないため、競合言語が加える安全検査は実行時コストとなり、しばしば受け入れられない
- 結果として検査は「セーフモード」限定となり、「高速モード」はCと同じく安全でないものになる
- 例外としてforeachは境界検査の手書きを不要にし、自動的により安全になる
- スライスもポインタと長さの組、あるいはより悪いヌル終端配列と比べ、検査を書きやすくする
- プログラマの生産性:
- ほぼ全ての言語が「生産性が高い」という中身のない主張を掲げる
- ビジネスにとって主要な時間の消費先はプログラミングそのものではない
- 実際に時間を要するのは、課題が本当は何であるかを見極める作業である
- 10%や20%の生産性向上は認識すらされず、100%の向上でさえ表面化する保証がない
■ 4. 採用を決めるのはキラー機能
- ビジネスの判断基準:
- 欠点を差し引いてなお収益に貢献するか、すなわち欠点を上回る価値があるかが問われる
- キラー機能の必要性:
- 決め手となるのはCが真似できない独自の売りを持つことである
- Java登場時の八つの売り:
- オブジェクト指向を綺麗に実現した点、当時は珍しかった標準搭載のスレッド機能
- 「一度書けばどこでも動く」、ブラウザ上でのコード実行
- 組み込みのガベージコレクション、ネットワークプログラミング
- 優れた標準ライブラリ、無償での利用
- C代替言語が持つ独自の売りは、少なくともJavaの八つには及ばない
- 独占的用途による普及:
- 言語は、何かを使うための唯一の手段となることで採用を獲得する場合が多い
- Flutterを使うためのDart、ブラウザのスクリプトのためのJS、アプレットのためのJava、MacとiOSアプリのためのObjCが該当する
- その独占が時とともに消えても、言語が知られ使われる状態は残る
- フレームワーク経由の普及:
- フレームワークの人気が言語を押し上げた例としてRubyとPythonがある
- Jaiの戦略:
- ゲームエンジンを同梱する方針は有効であり、利用者は必然的にJaiを学ぶことになる
- エンジンが十分に良ければ、人々は言語も習得する
- 他のC代替言語の欠如:
- Jai以外にキラー機能を追求している言語は見当たらない
- キラー機能がなければ、Cから乗り換える価値を証明することはできない
■ 5. 結論
- 「作れば人は来る」という考えは魅力的だが、信じるに足る根拠は乏しい
- Cが到底及ばない重要な独自機能や製品を持たない限り、Cを捨てる理由はほとんどない
- 人気と熱意は助けにはなるが、証明された価値の代わりにはならない
- 最終的に問われるのは、Cの用途の大部分において開発者により多くの具体的価値を生めるかである
- 開発者が新言語に興奮したとしても、その熱意がビジネス上の価値に転化することはない
- どれほど魅力的に見えるC代替言語であっても、おそらく失敗する