結論から言えば、
Python は「万能なツールボックス」、Go は「高性能バックエンドに特化した手術用メス」
このエコシステムの“広さ”の違いが、一般的な接触頻度と普及度を大きく分けています。
私は Python を12年以上使ってきた開発者ですが、今回はあえて Python を持ち上げる話ではなく、なぜ Go が大衆的な人気を得にくいのかという視点から考えてみます。
TIOBE ランキングが示す、言語の「定着」の難しさ
1990年を境に見てみると、
TIOBEランキングのトップ10に入り、かつ長期的に定着した言語は Java だけと言っても過言ではありません。
Java がなぜ成功したかについては意見が分かれますが、少なくとも現在の Java は
-
圧倒的な開発者人口
-
膨大なサードパーティライブラリ
を抱えており、「Java を置き換える」という発想自体が現実的ではありません。
一方で、トップ10に一時的に入ったものの定着できなかった言語も数多く存在します。
Ruby などがその代表例です。
これらの言語に共通するのは、
当時は先進的な機能を持っていたが、それ自体が高い参入障壁にはならなかったという点です。
より普及している言語が「ライブラリ」で同等の機能を実現できるようになると、
言語固有の優位性は急速に薄れていきます。
Perl が示す「言語組み込み機能」の寿命
Perl は、正規表現を言語機能として強力に統合したことで一時代を築きました。
しかしその後、正規表現はライブラリとして多くの言語に取り込まれ、Perl の優位性は失われていきます。
現代において、新人に Perl を勧める人はほとんどいないでしょう。
本当に重要なのは「何ができるか」
プログラミング言語の価値は、
どれだけ多くのことを“すぐに”実現できるかで決まります。
つまり、
サードパーティライブラリの量 = 言語の実用範囲
歴史の長い言語ほど、多数のライブラリを通じて新しい分野に適応し続けてきました。
特に C 言語系のライブラリは、OS レベルの API を含め、今なお圧倒的な存在感を持っています。
新しい言語を設計する際、
既存の C ライブラリをいかに素早く利用できるかは極めて重要です。
純粋性を重視し、C ライブラリとの互換性を拒否した言語は、
初期ユーザーを獲得できず、早期に消えていくケースが少なくありません。
かつての言語は、もっと C に必死だった
1990年以前の言語は、
-
C と同じ obj ファイルを生成できる
-
C のオブジェクトと直接リンクできる
-
動的ライブラリを前提に設計されている
など、徹底して C との互換性を追求していました。
近年の新しい言語で、ここまで現実的に C との連携を重視しているのは Lua くらいでしょう。
他の多くの言語は、C 拡張への対応が弱いか、事実上放置されています。
Java ですら、初期は純粋性を追求していましたが、最終的に JNI を導入しました。
Go と Python の比較
ここで、Go と Python を冷静に比較してみます。
1. サードパーティライブラリの量
これは比較になりません。Python の圧勝です。
2. C ライブラリとの連携
Python は完璧ではないものの、比較的扱いやすい部類です。
Go の cgo は合理的ですが、文法的に扱いづらく、Python における Cython と同程度の「使えるが快適ではない」レベルです。
3. 軽量スレッド・非同期処理
Python でも eventlet、gevent、Twisted など、多数のライブラリが存在します。
これらを総合すると、
Go が Python の普及度を超えるのは容易ではないと考えられます。
過去に現れては消えていった多くの言語と同じ道を辿る可能性も否定できません。
ライブラリで解決できる問題に、無理に新しいコンパイラを書く必要はない。
設計思想の違いが、流行の差を生んだ
Go と Python は、そもそも設計思想が根本的に異なります。
Python の設計目標
-
開発者の生産性
-
学習コストの低さ
-
迅速な試行錯誤
その代償として、
-
実行速度は遅い
-
GIL による並列処理の制限
-
動的型による大規模開発時のリスク
を受け入れています。
この割り切りが、
小〜中規模開発、非性能クリティカルな領域での爆発的な普及につながりました。
流行度と価値は別物
最後に重要な点を補足します。
「流行していること」と「価値があること」は同義ではありません。
Go と Python は競合関係ではなく、
異なる領域でそれぞれ最適解として輝いている言語です。
どちらが優れているかではなく、
どの問題に、どの道具を使うか
それが、エンジニアに求められる判断なのだと思います。
