はじめに
2015年頃、私は「エンジニアとして活躍し続けるためには、新しいプログラミング言語を学び続けなければならない」と思っていました。
技術系の記事を読んでいると、次々に新しい言語の名前が出てきました。JavaScriptはもう古い。次は別のAltJSです。Javaの次はScalaです。Web開発では関数型プログラミングを学ぶべきです。システム開発ではRustが来る。そんな話を見かけるたびに、自分も新しい言語を学ばなければならない気がしていました。
もちろん、当時の予測がすべて間違っていたわけではありません。Go、Rust、Kotlin、Swift、TypeScriptなどは、その後も開発が続き、現在では多くの現場で使われています。
しかし、今回振り返りたいのは、それら成功した言語のランキングではありません。
当時は注目を集めていたものの、GoやTypeScriptのようなメジャー言語にはならなかった言語もあります。Scala、PureScript、Elm、Nim、Idrisなどです。
これらは「消えた言語」ではありません。現在も開発されているものがありますし、特定の分野では価値を持ち続けています。
では、なぜメジャーにならなかったのでしょうか。そして、メジャーにならなかった言語が持っていた考え方は、その後どこへ行ったのでしょうか。
まるでカンブリア爆発のようだった
この時期を振り返ると、私は少し大げさですが、生物学でいうカンブリア爆発のようなものを感じます。新しい言語や処理系が一気に現れ、それぞれが異なる設計思想を試していました。
1980年代の8ビットパソコンにも、似た印象があります。パソコンの機種やOS、BASICの方言、雑誌のプログラムなどがまだ統一されておらず、限られたハードウェアの上でさまざまな可能性が試されていました。
2015〜2020年頃も、Web、クラウド、モバイル、組み込み、関数型プログラミング、型システムなどの境界で、複数の方向性が同時に試されていたように思います。
もちろん、当時の言語の増加を本当の意味でカンブリア爆発と呼ぶつもりはありません。これは、私がその時代を振り返ったときの感覚です。ただ、だからこそ面白いのです。すべてが主流になるわけではないと分かっていても、どの考え方が残り、どの言語が別の道へ進むのかを調べてみたくなります。
2015〜2020年に期待されていたこと
まず、当時注目されていた言語を簡単に振り返ります。
Goは、クラウド、API、CLI、DevOpsのような領域と相性のよい言語として広がりました。2020年のGo公式調査では、回答者の76％が職場でGoを使い、API／RPCサービスやCLIが代表的な用途として挙げられています。Go Developer Survey 2020
Rustは、CやC++が担ってきた領域で、性能を保ちながらメモリ安全性を高める言語として期待されました。2015年のRust 1.0発表でも、信頼性と効率的なシステムを構築する言語であることが前面に出ています。Announcing Rust 1.0
KotlinはJVMとJavaとの相互運用性を持ち、2017年にAndroidで公式サポートされ、2019年にはAndroidの推奨言語になった。Kotlinの歴史
SwiftはAppleのプラットフォームに接続された言語として登場し、2015年にはオープンソース化された。2019年のSwift 5では、AppleプラットフォームでABI安定性が実現した。Swiftのオープンソース化、ABI Stability and More
TypeScriptは、JavaScriptのエコシステムを捨てずに静的型を導入する道を示した。TypeScript 2.0ではstrictNullChecksが追加され、JavaScript開発で長く問題になってきたnullとundefinedを型で区別できるようになった。TypeScript 2.0
この時期に注目された言語を、入口と現在地で整理すると、次のようになります。
| 言語 | 2015〜2020年頃の主な期待 | 2026年の見え方 |
|---|---|---|
| Go | クラウドやAPI、CLI向けのシンプルな実装 | 大きな既存需要に接続して普及 |
| Rust | C／C++に代わる、性能とメモリ安全性の両立 | システム開発などで存在感を拡大 |
| Kotlin | Java／Android開発をより書きやすくする | AndroidとJVMの主要な選択肢 |
| Swift | Appleプラットフォームの新しい標準言語 | Apple開発の中心的な言語 |
| TypeScript | JavaScriptに段階的に型を加える | Web開発の大きな入口の一つ |
| Scala | Javaの次のJVM言語、関数型との融合 | 特定領域で使われる主流外の言語 |
| PureScript | JavaScript上で純粋関数型と強い型を使う | 小規模ながら継続する専門的な選択肢 |
| Elm | 安全性と学習しやすさを重視したWeb開発 | 安定性を重視して継続する言語 |
| Nim | Python風の記法とネイティブ性能の両立 | 機能は豊富だが普及には課題が残る |
| Idris | 依存型で仕様をプログラムに表現する | 依存型のアイデアを考えるための言語 |
ここでいう「現在の見え方」は、単純な人気順ではありません。開発が続いているか、どの分野で使われているか、導入時の周辺環境がどうなっているかをまとめたものです。
この5言語に共通しているのは、言語機能だけでなく、既存の大きな入口があったことです。クラウド、C／C++資産、Android、Apple OS、JavaScriptといった、すでに大きな需要が存在する場所に接続していました。
一方、今回の中心に置く言語は、別の魅力を持っていました。
Scalaは、JVM上でオブジェクト指向と関数型プログラミングを融合しました。PureScriptは、Haskellに近い純粋関数型と強い型システムをJavaScriptへ持ち込もうとしました。Elmは、純粋性と、学習者を助けるコンパイラエラーを重視しました。Nimは、Python風の記法、ネイティブコード、マクロを組み合わせました。Idrisは、依存型によってプログラムの仕様を型に表現する可能性を示しました。
どれも、単なる流行の名前ではありませんでした。プログラミングの考え方を変える可能性を持っていました。
Scalaは「Javaの次」になったのか
Scalaは、今回の5言語の中ではもっとも大きな利用基盤を持っています。
JVM上で動作し、Javaとの相互運用性を持ちながら、関数を値として扱い、高度な型システムやパターンマッチングを利用できます。Scala 2.12ではJava 8との相互運用性がロードマップの中心に置かれ、Scala 3では型システムやマクロなどが大きく整理されました。Scala: Next Steps、Scala 3
2010年代には、「Javaの次の言語」としてScalaに期待する声がありました。しかし現在のScalaは、Javaを置き換えたメジャー言語というより、JVMやデータ処理、Web／APIなどの領域で利用される主流外の言語と見る方が近いです。
Scala公式の2025年の記事は、Scalaが主流言語のすぐ外側に位置し、過去10年間の順位をおおむね維持していると説明しています。同時に、IDE、学習容易性、ツール、互換性、移行コストを課題として挙げています。Evolving Scala
これは興味深い現在地だと思います。
Scalaは、技術的に価値がなかったから普及しなかったわけではありません。むしろ、他の言語より先に多くの機能を取り込みました。その結果、表現力が高い一方で、学ぶべきことや選択肢も増えました。
Scala 3への移行もその一例です。2022年の公式調査ではScala 3の利用が増えている一方、Scala 2系も大きく使われていました。新しい言語機能を得るには、既存コード、ライブラリ、ビルド、IDEとの互換性を考えなければなりません。Scala Developer Survey 2022
Scalaは「メジャーになれなかった失敗例」というより、先進的な機能と導入容易性のトレードオフを示す言語です。
PureScriptはJavaScriptに接続できなかったのか
PureScriptは、かなり野心的な位置にありました。
強い型システムと純粋関数型を持ち、JavaScriptへコンパイルします。つまり、JavaScriptの巨大な世界に参加しながら、Haskellに近いプログラミングモデルを使おうとしました。
PureScriptの公式サイトは、既存のJavaScriptコードを再利用できること、代数的データ型、row polymorphism、高階型などを利点として説明している。PureScript公式サイト
2015年頃には、PureScript Conf、書籍、Google Summer of Codeなどの活動があり、関数型プログラミングやAltJSに関心を持つ人々から注目されていました。現在もコンパイラやドキュメント、パッケージ関連の活動は続いています。PureScriptの履歴資料
それでも、TypeScriptのように広く普及したわけではありません。
ここで、「JavaScriptとの接続がなかったから」と説明することはできません。接続は明確に存在しました。問題は、その接続の上に、十分大きな普及循環を作れたかどうかです。
PureScriptを使うには、JavaScriptだけでなく、PureScriptの型システム、純粋関数型の考え方、FFI、パッケージ管理、ビルドツールも学ぶ必要があります。これは高度な表現力の対価でもあります。
TypeScriptは、JavaScriptの書き方を大きく変えず、少しずつ型を追加できます。そのため、既存プロジェクトに導入しやすいです。PureScriptは、より大きく異なる考え方を持ち込む代わりに、チーム全体が学ぶ量も増えます。
PureScriptから得られる教訓は、優れた機能と既存エコシステムへの接続だけでは十分ではないということです。導入する人が、既存の開発者、ライブラリ、ツール、教育資料を同時に得られる必要があります。
Elmは親切な言語だった
Elmは、言語を学ぶ体験そのものを設計しようとしていました。
2015年の公式記事では、NoRedInkやPreziなどでの利用と、コミュニティの拡大が紹介されている。New Adventures for Elm
Elm ArchitectureはWebアプリケーションの構造を単純化し、Elm 0.15では非同期処理のためのTasks、Elm 0.17ではsubscriptionsが導入されました。Elm 0.15、A Farewell to FRP
また、Elmはコンパイラエラーを学習支援として扱いました。2019年の公式記事では、構文エラーに例や説明を含め、「教師」のように振る舞うことが目標として語られています。The Syntax Cliff
既存JavaScriptへの導入方法も考えられていました。2016年の公式記事は、既存のJavaScriptプロジェクトに小さな単位でElmを導入し、うまくいけば徐々に広げる方法を説明しています。How to Use Elm at Work
それでもElmは、ReactやTypeScriptのような主流のWeb開発基盤にはなりませんでした。
ここで考えたいのは、親切なエラーメッセージや安全性が無意味だったということではありません。実際、それらはElmの明確な価値でした。ただ、Web開発の主流になるには、それ以外にも必要なものが多くあります。
JavaScriptのライブラリをすべてそのまま使えること。既存の人材を採用できること。新しい開発者が十分にいること。会社が長期的に採用しても不安がないこと。Elmの設計上の一貫性は、場合によってはJavaScriptとの距離にもなりました。
2026年のElm公式Newsには、0.19.2とElm 1.0へ向けた小さな非破壊リリースの方針が掲載されています。Elm News
Elmは止まったのではありません。むしろ、安定性や設計上の一貫性を優先しているように見えます。速い市場拡大と、長く壊れにくい言語を作ることは、同じ方向を向くとは限りません。
Nimに足りなかったもの
Nimは、別の意味で魅力的な言語です。
Pythonに近い読みやすい記法を持ちながら、ネイティブコードへコンパイルできます。CやC++との相互運用性、マクロによる拡張性もあります。Nim 2.0の公式発表では、ORCメモリ管理、型推論、C++相互運用、NimbleやAtlasなどが紹介されています。Nim 2.0
しかし、言語機能が豊富であることと、採用しやすいことは別です。
2016年のNim公式調査では、利用者が魅力として実行速度、開発速度、可読性、メタプログラミングを挙げる一方、不満としてデバッグツール、ドキュメント、テストツール、IDE、ライブラリ、コミュニティ規模などを挙げている。Nim Community Survey 2016
2024年の調査でも、Nimを使わない理由として、本番利用への不安、必要なライブラリの不足、学習資料の不足、リスクが挙げられている。さらに、調査チームは新しい利用者を十分に集められていない可能性にも触れている。Nim Community Survey 2024
これは、今回の企画にとって重要な資料だと思います。
Nimは、機能が足りなかったから普及しなかったという単純な例ではありません。むしろ、十分に面白い機能があっても、開発者が安心して選ぶための周辺環境が揃わなければ、普及の循環は始まりにくいことを示しています。
言語を選ぶとき、私たちは構文や性能だけを見ているわけではありません。困ったときに検索できるか。IDEで正しく補完されるか。ライブラリが保守されているか。会社で採用した人を見つけられるか。数年後も更新できるか。
Nimの例は、「良い言語なのに普及しない」という感覚を、かなり具体的に分解してくれます。
Idrisと依存型のその後
Idrisは、今回の5言語の中でもっとも理論寄りの期待を背負っていました。
依存型を使うと、値に関する条件を型に含められます。たとえば、長さが3のベクターと、長さが不明なリストを別の型として扱えます。関数の型が、単に入力と出力の型だけでなく、満たすべき条件まで表現できます。
Idris公式は、Type-Driven Developmentを掲げ、型を言語の第一級の構成要素として説明している。Idris公式サイト
これは、型安全性をさらに推し進めた考え方です。当時、依存型を使ったプログラミングは、将来のプログラミング言語が向かう方向の一つとして注目されました。
しかし、依存型は強力であるほど、型を設計する負担も大きくなります。型エラーを解決するには、単なる構文知識ではなく、型の等価性、推論、証明、コンパイラの挙動を理解しなければならない場合があります。
Idris 2は現在も開発されています。2025年には0.8.0が正式リリースされ、パッケージ管理や学習資料も整備されています。Idris 2のDownloadページ
では、依存型のアイデアは普及しなかったのでしょうか。
ここでLeanを見ると、少し違う風景が見えます。Leanは依存型理論を基盤に持ちながら、定理証明、数学の形式化、形式検証のエコシステムを大きく発展させています。Lean公式も、Leanを定理証明器であると同時に関数型プログラミング言語として説明しています。Lean公式Learn
これは、IdrisがLeanに置き換えられたという話ではありません。Idrisは汎用プログラミング言語として依存型を扱う方向が強く、Leanは数学や証明を中心に利用されています。
同じような考え方でも、接続する利用者層、ライブラリ、ツール、需要が違えば、進む方向は変わります。
Idrisから見えるのは、先進的な言語機能が必ずしもメジャーな汎用言語になる必要はないということです。あるアイデアは、研究、教育、形式検証、別の言語の機能へ移りながら残っていきます。
既存言語は新しい言語に置き換えられなかった
ここまで、メジャーにならなかった言語を見てきました。
では、なぜJava、JavaScript、Python、PHP、Ruby、C#などは、次々に登場する新言語に置き換えられなかったのでしょうか。
一つの答えは、既存言語の側が変化したからです。
JavaScriptには、let、const、arrow function、module、Promise、async／awaitなどが入りました。かつてのcallback中心のコードから、より構造化された非同期処理へ移行できるようになりました。MDN: JavaScript Modules、MDN: Using Promises
Javaにはlambda、Stream、var、record、sealed class、pattern matchingが追加されました。C#にもasync／await、nullable reference types、record、pattern matchingが入りました。Pythonにもtype hints、dataclass、async／await、structural pattern matchingが導入されています。OpenJDK JEP、C# nullable reference types、Python PEP
これらをすべて、ScalaやHaskellやMLの直接的な影響だと断定することはできません。機能の設計者がどの言語を参照したか、一次資料ごとに確認する必要があります。
ただ、関数を値として扱う考え方、型による安全性、nullを減らす設計、非同期処理、パターンマッチングといった考え方が、既存言語の中へ取り込まれたことは確かです。
新しい言語は、既存言語を置き換えませんでした。その代わり、既存言語が新しい考え方を吸収するきっかけになった可能性があります。
ここまでの話を、言語そのものの優劣ではなく、普及の条件として整理すると次のようになります。
| 観点 | 広く普及した言語に見られる条件 | 主流にならなかった言語に見られる傾向 |
|---|---|---|
| 導入の入口 | 既存の大きな基盤や需要に接続している | 接続はあっても、学ぶ範囲が大きい場合がある |
| 移行のしやすさ | 既存コードや知識を段階的に利用できる | 設計思想の転換をチームに求めることがある |
| ツールと資料 | IDE、ライブラリ、教材、採用人材が揃う | 機能に対して周辺環境の規模が追いつかないことがある |
| 変化への対応 | 既存言語側も新しい考え方を取り込む | 新しいアイデアが言語の外へ移ることがある |
| 現在地 | 多数の利用者と継続的な需要がある | 特定分野、教育、研究、個人開発などに価値が残る |
もちろん、これは因果関係を証明する表ではありません。今回調べた言語を比較するための仮説の整理です。ScalaやNimの公式調査、ElmやPureScriptの公式資料などを読むと、言語機能だけでなく、移行コストやツール、教材、コミュニティが繰り返し課題として現れます。
AI時代に言語を学ぶということ
AIによって、プログラミング言語を学ぶ方法も変わり始めています。
以前は、知らない言語を試すには、公式ドキュメントを探し、環境を作り、サンプルを読み、エラーを検索し、ライブラリの使い方を覚える必要がありました。今は、AIに質問しながら小さなコードを書き、別の言語へ変換し、エラーの意味を説明させることができます。
GitHubも、新しい言語を学ぶためにCopilotを使う方法を公式に紹介しています。GitHub Copilot: Learn a new language
ただし、これはマイナー言語が自動的に有利になることを意味しません。
Goの2025年公式調査では、多くの回答者がAI開発ツールを情報検索や反復作業に使っている一方、品質への懸念も示されています。Go Developer Survey 2025
AIは、公開コード、質問、ドキュメント、学習資料が多い言語ほど答えやすい可能性があります。GitHubの2025年Octoverseでは、TypeScriptがGitHub上でもっとも使われる言語になり、PythonはAI関連リポジトリで特に強いと報告されています。GitHub Octoverse 2025
一方で、AIはマイナー言語の入口を低くする可能性もあります。構文の確認、古いコードの読み解き、別言語からの移植、エラーメッセージの説明などは、利用者が少ない言語ほど助けになるかもしれません。
ここで重要なのは、コードを生成できることと、そのコードを評価できることは別だということです。
型は何を保証しているのか。副作用はどこで起きるのか。非同期処理はどの実行モデルに従うのか。ライブラリのAPIは安定しているのか。生成されたコードは、性能、セキュリティ、保守性の面で妥当なのか。
こうした問いに答えるには、言語の構文を暗記する以上に、その言語の思想、型、実行モデル、エコシステムを理解する必要があります。
おわりに
10年前、私はエンジニアとして活躍し続けるためには、新しい言語を学ばなければいけないと思っていました。
しかし10年経って振り返ると、すべての新言語を完全に習得する必要があったわけではなさそうです。実際の仕事では、既存の知識を使いながら、必要な範囲を新しい言語へ広げていくことが多かったです。
一方で、新しい言語を学ぶ価値がなくなったわけでもありません。
Scalaからは、型と抽象化を使って大きなプログラムを設計する方法を学べます。PureScriptやElmからは、純粋性、型、エラー体験、状態管理について考えられます。Nimからは、記法、性能、コンパイル、メタプログラミングの組み合わせを考えられます。Idrisからは、型が仕様をどこまで表現できるかを考えられます。
言語そのものがメジャーにならなくても、そこで試された考え方が別の場所へ移ることがあります。あるいは、少数の人にとって長く使える道具として残ることもあります。
AIによって、知らない言語を試す障壁は下がるかもしれません。けれど、どの言語を選び、生成されたコードをどう評価し、数年後も保守できる設計にするかという責任は残ります。
これからの「プログラミング言語を学ぶ」とは、すべての構文を頭に入れることではなく、異なる言語が提示した考え方を理解し、必要なときに使い分けられることなのかもしれません。
10年前の不安への答えは、まだ完全には出ていません。ただ、新しい言語を追いかけることと、そこから新しい考え方を学ぶことは、分けて考えてよかったのだと思います。