Skip to content
Published on

ニッチ & 新興プログラミング言語 2026 — Crystal / Nim / V / Carbon / Mojo / Pony / Hare / Roc / Hylo / Vale / Koka / Tcl 9 / Fortran 2023 徹底ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

1. 2026年のニッチ & 新興言語マップ — システム / FP / 安全性 / ドメインの 4 分類

2026年5月現在、主流(Python、JavaScript/TypeScript、Java、C#、Go、Rust、C/C++、Swift、Kotlin)の外側には、依然として豊かな言語エコシステムが生きている。本稿で扱う「ニッチ & 新興」言語は、GitHub 利用者比率では 1% 未満、TIOBE 30 位圏外、RedMonk グラフのちょうど中間帯に集まっているが、特定のワークロードや思想ではメジャー言語より良い回答になることがある。

4 軸で分類すると一望できる。

分類代表言語中心的価値
システム / ネイティブCrystal, Nim, V, Carbon, HareC/C++ または Ruby/Python 風の構文 + ネイティブコンパイル
安全性 / 所有権Pony, Hylo, Vale, Inko, Kokaborrow / region / capability / effect など新しい安全モデル
関数型Roc, Racket, Common Lisp(SBCL)強い型または強いマクロ、研究志向
ドメイン / 歴史Mojo, Fortran 2023, Tcl 9, OpenSCAD, J, Forth, Modula-3AI 加速、科学計算、組込み、3D、配列

この 4 分類は排他ではない。Mojo はシステム + AI ドメイン、Roc は関数型 + 安全性、Hylo はシステム + 安全性にまたがる。しかし出発点としては十分に役立つ。

最初に誤解を 3 つ整理しておく。

  • 「ニッチ = 死んだ言語」ではない。Common Lisp は SBCL とともに 1980 年代から現在まで生きており、Fortran は 2023 年に新標準が確定した。
  • 「新興 = より良い」でもない。V(Vlang)は 2019 年の公開から 7 年目もベータのままだ。
  • メジャー言語が持つライブラリの厚み、採用市場、AI 支援ツールのカバー範囲を、ニッチ言語が上回ることはほぼない。それでも「この領域ではこれが正解」というケースはある。

2. Crystal — Ruby-like compiled(1.14)

Crystal は「Ruby の構文、C の速さ」を掲げて 2014 年に初公開され、2021 年に 1.0、2024 年 11 月に 1.14 がリリースされた。2026 年 5 月時点で 1.14 ラインが安定版、1.15 が RC 段階にある。

主な特徴:

  • LLVM ベースの AOT コンパイラ、静的型 + 強力な型推論
  • Ruby 風の構文(ブロック、シンボル、ただし未定義メソッドは NoMethodError ではなくコンパイルエラー)
  • グリーンスレッド(fiber)と Channel — Go によく似た並行性モデル
  • Null 安全性: nil は別の型で、コンパイラが union として追跡

簡単な例:

# fibers + channels — Go に非常に近い
ch = Channel(Int32).new

spawn do
  ch.send 42
end

puts ch.receive  # => 42

Crystal が合う場面:

  • Ruby on Rails のバックエンドを静的型 + コンパイル性能でリファクタしたいとき
  • Sidekiq ワーカー、CLI ツールなど Ruby コードをそのまま書き直しにくいワークロード
  • 代表的な採用先: Manas Tech、一部の NeoVim プラグイン、一部のフィンテックバックエンド

率直な弱点:

  1. マルチスレッド実行はまだ実験的(-Dpreview_mt フラグ)。2026 年の 1.14 では既定はシングルスレッド fiber モデル。
  2. ライブラリエコシステムは Ruby/Go と比べて薄い。ORM は Granite、Jennifer、Avram 程度。
  3. Windows 対応は遅く、依然として一級市民ではない。

3. Nim — Python-like compiled(2.x)

Nim は「Python 風構文を C/C++ バックエンドにコンパイル」を目標に 2008 年に始まった。2023 年 8 月に Nim 2.0 が出て、2026 年 5 月現在の安定ラインは 2.0.x、開発ラインは 2.2.x。

特徴:

  • インデントベースの構文(Python 風)+ 静的型
  • C、C++、ObjC、JavaScript バックエンドをすべてサポート — 同じコードで Web とネイティブ両対応
  • コンパイル時マクロ(macro、template)— Lisp 級のメタプログラミング
  • ARC/ORC メモリ管理(2.0 から既定)— GC なし、サイクルコレクタのみ

Nim 2.0 の主な変化:

  • 既定のメモリマネージャを ORC に統一(従来の mark&sweep、refc はレガシー)
  • View types(openArray、lent)で borrow に近い安全性が始まる
  • 明示的に未定義の変数に対する strict モード

コード片:

import std/[asyncdispatch, httpclient]

proc fetch(url: string): Future[string] {.async.} =
  let client = newAsyncHttpClient()
  defer: client.close()
  result = await client.getContent(url)

echo waitFor fetch("https://example.com")

Nim の真の強みはコンパイル時マクロだ。Status が開発する Ethereum 2.0 合意クライアント Nimbus が代表例で、Nim のマクロによって SSZ シリアライズコードをコンパイル時生成している。

弱点:

  1. 日本/韓国の採用市場では殆ど見ない — 学習後の次のキャリアにどう繋ぐかを考える必要がある。
  2. 標準ライブラリは歴史的経緯でやや雑然としている。
  3. コミュニティ規模は Crystal より僅かに小さい。

4. V(Vlang)— ベータ状態の controversial

V言語(Vlang)は 2019 年に公開され、「Go より速いコンパイル、Rust 並の安全性、メモリ GC なし、対話型 GUI まで」という非常に幅広い約束を掲げた。2026 年 5 月時点の公式版は 0.4.x — ベータ 7 年目だ。

論争の理由:

  • 公開当初の約束(例: 1MB の hello world、1 秒コンパイル、自動メモリ管理、C 相当の性能)の多くが時間と共に修正・未完成のままとなっている。
  • 一部のコミュニティでは「マーケティングが技術を追い越している」という批判が続く(2019〜2021 年の Hacker News スレッド多数)。

それでも V は生きている:

  • 構文は Go によく似ている(C 風、短いキーワード)。
  • C にトランスパイル → C コンパイラでビルド — TCC を使うと本当に高速にコンパイルできる。
  • 標準ライブラリに GUI(vlang/ui)、Web(vweb)、ORM(vorm)が同梱されている。

コード例:

struct User {
  name string
  age  int
}

fn main() {
  users := [User{'Anna', 30}, User{'Bob', 25}]
  for u in users {
    println('${u.name} is ${u.age}')
  }
}

V を使うべき場面は? 率直に言うと、2026 年現在、本番運用ではお勧めしにくい。学習、実験、小規模 CLI 程度なら、高速コンパイルと短い構文は楽しい体験だ。だが、V 独自の機能(自動 free、ORM 内蔵)に依存するシステムを作る前に、同じ領域なら Crystal、Nim、Go、Rust のいずれかがほぼ確実により安全な選択である。

5. Carbon(Google)— C++ 後継、緩やかな進行

Carbon は 2022 年の CppCon で Google の Chandler Carruth が発表した「C++ の successor」プロジェクト。2026 年 5 月現在も carbon-language/carbon-lang リポジトリは活発だが、公式ステージは依然として「experimental」であり、0.1 アルファにも到達していない。

設計意図:

  • C++ コードベースとの双方向相互運用 — Carbon から C++ ライブラリを直接 import、C++ から Carbon を呼び出す。
  • C++ の ABI と構文が背負う 30 年分の設計負債を引き継がず、清算する。
  • Rust のような「オプトインのメモリ安全性」— 安全モードと速度モードをモジュール単位で選ぶ。

構文の一例:

package Geometry api;

class Circle {
  var r: f64;
  fn Area[me: Self]() -> f64 { return 3.14159 * me.r * me.r; }
}

fn Main() -> i32 {
  var c: Circle = {.r = 2.0};
  Core.Print(c.Area());
  return 0;
}

進行状況(2026 年 5 月時点):

  • 自前コンパイラ(toolchain/)はアルファ — 一部例はビルドできるが、標準ライブラリは未完成。
  • 仕様は GitHub の design/ ディレクトリに Markdown として蓄積される — 興味深い設計レビュー資料。
  • Google が小規模に社内パイロットを進めているという発表はあるが、実際の社内採用規模は公開されていない。

現実的な評価: Carbon は「今日使う言語」ではなく「C++ 陣営がどこへ向かうかを見る望遠鏡」だ。Rust の方が安全で、Mojo の方が早く GA に届いたが、C++ ABI 互換が必須の巨大コードベース(Chromium、Android、一部ゲームエンジン)に限れば Carbon も意味を持ち得る。

6. Mojo(Modular)— Python superset(2024.8 GA)

Mojo は LLVM/Swift の生みの親 Chris Lattner が設立した Modular が作る言語。2023 年 5 月に初公開、2024 年 8 月に安定 GA(1.0)に到達。2026 年 5 月時点の安定ラインは 24.x — 四半期リリース。

Mojo の約束は大きい:

  • Python スーパーセット — Python コードをそのまま import できる。
  • システムプログラミング — MLIR ベース、C 級の性能、SIMD/GPU intrinsic。
  • AI 加速 — NVIDIA、AMD、Apple Silicon GPU を同一コードでターゲット。

コード片(簡略):

from sys.info import simdwidthof
from algorithm import vectorize

fn dot[type: DType, size: Int](a: SIMD[type, size], b: SIMD[type, size]) -> Scalar[type]:
  return (a * b).reduce_add()

fn main():
  var a = SIMD[DType.float32, 4](1.0, 2.0, 3.0, 4.0)
  var b = SIMD[DType.float32, 4](5.0, 6.0, 7.0, 8.0)
  print(dot(a, b))  # 70.0

Modular の核となる武器が MAX(Modular Accelerated eXecution)プラットフォーム — Mojo + MLIR + 推論エンジンを束ねたもの。2026 年現在、OpenAI 互換の推論サーバを Mojo で書いて配備でき、PyTorch モデルを MAX でグラフコンパイルすると同一 GPU で 1.5〜3 倍のスループットを示すベンチマークが公開されている。

長所:

  • Python 互換性 — 既存の NumPy/PyTorch コードの一部をそのまま import 可能。
  • GPU が一級市民 — CUDA/ROCm/Metal を抽象化する単一コード面。
  • 企業が後ろ盾 — Modular はシリーズ B まで調達し、AI インフラに集中している。

リスク:

  • 言語仕様と標準ライブラリは依然急速に動く — 24.1 と 24.3 の間でも一部 API が壊れた。
  • コンパイラはオープンソースではない(2024 年に段階的 OSS 化の発表はあったが、2026 年 5 月時点ではコンパイラ本体は非公開)。
  • ライセンスは「使用は自由、再配布に制限」— 学習は自由だが会社のポリシー確認が必要。

7. Pony — capabilities-secure

Pony はケンブリッジ出身の Sylvan Clebsch が始めた、「データレースがコンパイル時に不可能」なアクター言語。2026 年 5 月現在 ponylang/ponyc は活発に保守され、0.58.x が最新安定。

中心アイデア — Reference Capabilities:

  • すべての参照は 6 種類の capability のいずれかを持つ: iso、val、ref、box、tag、trn。
  • iso = 隔離(他アクターへ安全に送信可)、val = immutable、ref = mutable だがアクター内ローカル。
  • コンパイラがこれらを追跡し、レースし得るコードはそもそもコンパイル不能にする。
actor Counter
  var _n: U32 = 0

  be inc() => _n = _n + 1
  be get(promise: Promise[U32]) => promise(_n)

actor Main
  new create(env: Env) =>
    let c = Counter
    c.inc()
    c.inc()

Pony が輝く場面:

  • 高スループットのアクターシステム(メッセージパッシング)。WallarooLabs が Pony で構築したデータストリーミングエンジン(2017〜2020)が最も有名な産業例。
  • データレース自体がビジネスリスクとなる領域 — 金融取引、一部の組込み。

限界:

  • WallarooLabs は 2021 年に事業を畳み、最大の産業スポンサーを失った。その後は Sylvan Clebsch と Microsoft の一部エンジニアがコミュニティを支えている。
  • 学習コストが高い — 6 種類の capability を頭に入れないとコードが通らない。
  • ライブラリエコシステムが狭い。

それでも「データレースのないアクターモデルがどんなコードになるか」を見たいなら、Pony は今でも一読の価値がある。

8. Hare(Drew DeVault)— suckless C の代替

Hare は sr.ht の創業者 Drew DeVault が始めた「C99 互換の最小システム言語」。2022 年 4 月に初公開、2026 年 5 月時点で 0.25.x が最新安定。1.0 は意図的に遠くに置かれている。

Hare の哲学(suckless の影響):

  • 標準ライブラリは小さく、明示的に。
  • GC なし、例外なし、マクロなし — C のような単純さ。
  • 自前のアセンブラとリンカ(harec + qbe)— 外部依存を最小化。
use fmt;

export fn main() void = {
  for (let i: int = 0; i < 5; i += 1) {
    fmt::printfln("hello {}", i)!;
  }
};

数多の「C 代替」のなかで、Hare の独自性は:

  • ライセンスは GPLv3 — Drew DeVault のフリーソフト思想を反映。
  • 自前 OS(Hare OS、Helios)を目標 — 言語と OS が一緒に進化する。
  • Windows/macOS は非対応 — Linux、BSD、Plan 9 のみ。

現実的な立ち位置:

  • システムプログラミングの学習資料として優秀 — C++/Rust の複雑さなしでシステムコールとメモリを見られる。
  • 自前 OS、自前 init、自前コンパイラのようなミニマル構築プロジェクトに合う。
  • 採用市場は実質ゼロと考えてよい。

9. Roc(Richard Feldman)— 関数型、no built-in errors

Roc は Elm コミュニティで知られる Richard Feldman が作る関数型言語。2026 年 5 月時点で 0.x(公式 1.0 未発表)だが、0.0.x のリリースは活発で、一部企業が社内ツールに採用している。

Roc の差別点:

  • 純粋関数型 + 強力な Hindley-Milner 推論 — Elm/Haskell 系。
  • 「No built-in errors」 — ビルドエラーはコンパイラ、ランタイムエラーは platform の責任(言語自体に例外概念はない)。
  • Platform / Application の分離 — 同じ Roc コードを CLI、Web、AWS Lambda など異なる platform に載せられる。
app "hello"
  packages { pf: "https://example.com/basic-cli/platform" }
  imports [pf.Stdout]
  provides [main] to pf

main =
  Stdout.line "Hello, Roc!"

用途:

  • CLI ツール、静的サイト生成器、一部の Lambda ワークロード — Elm 風の安全性をサーバ側に持ち込みたいとき。
  • Richard Feldman の NoRedInk が代表ユーザ(Elm + 一部 Roc)。

率直な限界:

  • 1.0 はまだ遠い。言語仕様は安定していない。
  • 標準ライブラリは意図的にミニマル — platform が補完する。
  • AI 補助ツール(Copilot 等)は Roc コードを上手く書けない。

10. Hylo(旧 Val)— Carbon 隣接、value-oriented

Hylo はもともと「Val」という名で 2020 年から開発され、Carbon と同じ「C++ 後継」の席を狙う言語。2023 年に Val から Hylo へ改名(Vale との名称衝突を回避)。2026 年 5 月時点で hylo-lang/hylo は 0.x。

中心設計:

  • Value semantics が既定 — 全変数は基本的に値、参照は明示的に借りる(borrow)ときだけ。
  • Generic programming が一級市民 — C++ テンプレートと Rust ジェネリクスの良い面を組合せる目標。
  • Mutable value semantics — Rust より柔らかい borrow モデル。
// Hylo の構文は視覚的に Carbon と似ている(共に C++ 後継陣営)。
fun main() {
  var nums = [1, 2, 3]
  inout last = nums[2]
  &last = 42
  print(nums)  // [1, 2, 42]
}

(注: 上のコードは雰囲気を示す疑似コード。Hylo の実構文は活発に進化中)

評価:

  • 学術的価値は明確 — 「value semantics を既定とする安全なシステム言語」とはどんな姿か。
  • Hylo と Carbon は同じ席(C++ 後継)を争うが、Hylo はより学術的で Carbon はより実用的。
  • 産業採用は微々たるもの。

11. Vale(Evan Ovadia)— region ベースの borrow

Vale は Evan Ovadia が個人で主導するプロジェクトだが、設計面で学界の注目を集める。2026 年 5 月時点で 0.x。

差別点 — Region borrow checking:

  • Rust の borrow checker は「一時点に一つの mutable 参照」という強い不変量。
  • Vale は「region」という概念を導入 — 明示的に region を開き、その中で一貫した borrow 規則を適用、region 外では別規則。
  • 結果として Rust より表現力が広く、データレースや iterator invalidation を region 境界で捕える。

さらに Vale は「Higher RAII」のような興味深いアイデアも試す — 単純な RAII ではなく、destructor の呼出し順までコンパイラが追跡する。

コードは未だ高速に変わるため、ここには移さない。興味があれば vale.dev ブログの「Single Ownership and Memory Safety without Borrow Checking, RC, or GC」を推奨する。

産業採用はほぼ 0。だが borrow モデルを学ぶ人にとっては良い参考資料。

12. Inko — concurrent + safe

Inko はオランダの Yorick Peterse が作る並行言語。2026 年 5 月時点で 0.x、活発に開発中。

特徴:

  • アクターモデル + Rust 風の所有権。
  • コンパイラは自前 IR + LLVM バックエンド。
  • 非同期 I/O が一級市民 — 自前ランタイムが epoll/kqueue を抽象化する。
// Inko の構文は Rust に非常に似た印象を与える。
import std.stdio.STDOUT

class async Main {
  fn async main {
    STDOUT.write("Hello, Inko!\n")
  }
}

Inko の位置:

  • Pony と直接競合する — 「safe + concurrent + native」領域。
  • Pony の capability より軽量で、Rust より並行性に集中。
  • 個人プロジェクトの限界 — 企業リスクは事実上一人に依存。

13. Koka(MS)— effect handlers

Koka は Microsoft Research の Daan Leijen が主導する研究言語。2026 年 5 月時点で 3.x ライン。

Koka の真の革新: Algebraic effects と effect handlers。

  • 関数の型シグネチャに「この関数がどの effect を発生させるか」が明示される。
  • 例外、async、ジェネレータ、状態、非決定性が、すべて同じ effect handler 機構で表現される。
// Koka の構文は ML/Haskell 系に近い。
fun greet(name : string) : console ()
  println("Hello, " ++ name)

(このフェンスは視覚的参考。Koka の公式構文は依然変化する。)

用途:

  • 学術 — effect handler の実用可能性を示す最も成熟した言語。
  • 影響力は大きい — OCaml 5 の effect、Java の Loom、Swift の typed throws はいずれもこの流れの変奏。
  • 産業採用はほぼないが、「effect システムを持つ関数型言語」がどんな姿かを見るには最良の入口。

14. Common Lisp(SBCL)/ Racket — 学術 + 研究

ニッチと呼ぶには長すぎる二言語を一緒に見る。

Common Lisp + SBCL

  • 1984 年の標準化以降、メジャー改訂は一度もない。それでも死なない。
  • SBCL(Steel Bank Common Lisp)は最も成熟した OSS 実装 — 2026 年 5 月時点で 2.4.x ラインが四半期リリースされる。
  • マクロ系(macro、reader macro)は依然最強。「自分自身を書くコード」を最も自然に表現できる言語。

代表的な採用先:

  • Grammarly の中核 NLP エンジンの一部。
  • ITA Software → Google Flights の検索コア(元は Common Lisp で書かれた)。
  • 日本の NTT 一部研究グループがドメインモデリング用途で使用しているという資料が公開されている。

コード:

(defun factorial (n)
  (if (<= n 1)
      1
      (* n (factorial (- n 1)))))

(print (factorial 10))  ; 3628800

Racket

  • Lisp 系、Scheme の直系子孫。
  • 2007 年に PLT Scheme から Racket へ改名 — 言語そのものより「言語を作るための言語」として位置づけ。
  • 2026 年 5 月時点で Racket 8.x、racket/cs(Chez Scheme バックエンド)が既定。

用途:

  • 学部 PL 講義の標準ツール(SICP の系譜)。
  • DSL 生成 — #lang ... で新しい言語を定義する。
  • 学術研究 + 一部産業のドメインモデリング。
#lang racket

(define (factorial n)
  (if (<= n 1) 1 (* n (factorial (- n 1)))))

(displayln (factorial 10))

15. Tcl 9(2023.9)— 26 年ぶりのメジャー

Tcl(Tool Command Language)は 1988 年に John Ousterhout が作ったスクリプト言語で、Tcl 8.0 が 1997 年に出てから 26 年ぶりに 2023 年 9 月に Tcl 9.0 が正式リリースされた。2026 年 5 月時点で 9.0.1 が最新安定。

Tcl 9 の主な変化:

  • 64 ビット整数が一級。
  • UTF-32 エンコーディング、マルチバイト/マルチ文字の処理改善。
  • 大規模データ(2GB 超)の処理が一級 — string、list、dict が 64 ビット長を扱う。
  • Tk 9.0 も同時リリース — 新ウィジェット、HiDPI 対応。
puts "Hello, Tcl 9.0!"

set users {alice bob carol}
foreach u $users {
  puts "User: $u"
}

Tcl が生きている場所:

  • EDA(電子設計自動化)— Synopsys、Cadence、Mentor のツールは依然として Tcl をスクリプト言語に採用。
  • ネットワーク機器自動化 — Cisco IOS、NX-OS の自動化スクリプトの一部は今でも Tcl ベース。
  • expect — TUI 自動化の事実上の標準。

16. Fortran 2023 — 科学計算 in production

Fortran は 1957 年に IBM の John Backus が発表した、人類最初の高水準コンパイル言語だ。そして 2026 年 5 月時点でも、スーパーコンピュータの中核言語の一つである。

Fortran 2023(ISO/IEC 1539:2023):

  • 2023 年 11 月に標準化完了。
  • ジェネリックプログラミング強化(C++ テンプレートに近い generic procedure)。
  • ASYNCHRONOUS 属性、do concurrent、coarray の改善。
  • ISO_FORTRAN_ENV の整数/実数型拡充。
program hello
  implicit none
  integer :: i
  do concurrent (i = 1:5)
    print *, "Hello, Fortran 2023, iteration =", i
  end do
end program hello

実際の採用先:

  • 気象モデル(WRF、CESM)、気候モデル、流体力学(OpenFOAM は C++ だが周辺ツールは Fortran 多数)。
  • 海洋シミュレーション、核実験シミュレーション(米国 NNSA)。
  • LAPACK/BLAS — 事実上、あらゆる科学計算ライブラリの根幹。

Fortran が消えない理由は単純だ — 数値配列処理で Fortran より速く、安定したコンパイラはほぼなく、60 年分の検証済みコードを書き直すコストはどんな移行利益も上回るからだ。

17. Modula-3 / J language / OpenSCAD / Forth — 歴史 + 好奇心

3 グループに分けて短く見る。

Modula-3

  • 1986〜1993 年に DEC が作ったシステム言語。
  • Modula-2 の後継、Java より早く GC + スレッド + モジュールを一括導入した。
  • 産業的にはほぼ消えたが、OS 講義(例: SPIN OS)とシステム設計資料では依然引用される。

J language

  • APL の後継 — 配列/ベクトル一級言語。
  • アルゴリズムトレーダ、一部統計学者が今も使う。
  • コードはほぼ数学表記に見える(+/ % # が平均)。

OpenSCAD

  • 3D プリント用の declarative CAD 言語。
  • 2026 年でも RepRap、Prusa コミュニティの代表ツール。
// OpenSCAD のワンライナー
// 横20、奥行10、高さ5 の箱
cube([20, 10, 5]);

Forth

  • 1970 年 Charles Moore — スタックベース + メタプログラミング + 組込み。
  • 天文台の望遠鏡制御、BIOS の一部、宇宙探査機(NASA の一部ミッション)で今も生きている。
  • 学習価値 — 「言語が自分自身を定義する」最も極端な姿。

Factor、Joy は Forth 系のスタック言語。学術的意義は大きい。

Plan 9 from Bell Labs

  • 言語ではなく OS だが、「everything is a file」の Unix 哲学を最後まで突き詰めた素材。
  • 9P プロトコル、Acme エディタ、rc シェルは今でも発想の源泉。

18. 韓国 / 日本 — niche コミュニティ

韓国

  • Crystal/Nim の韓国語資料は GitHub の awesome-* リストと個人ブログに散在。KLDP、Modulabs(모두의 연구소)の一部で勉強会。
  • Mojo は NVIDIA AI Day Korea セッションで取り上げられ、一部のスタートアップが推論加速用に PoC。
  • Common Lisp/Racket は PL 学会と大学院に残っている。

日本

  • 日本は historically Common Lisp 利用が厚い。NTT の一部研究所、NEC、過去のゲーム会社(旧 Hyper-FX 系列など)での利用記録が公開されている。
  • Mojo/Modular の日本支社はないが、PFN(Preferred Networks)、MN-3 スーパーコン運用チームが新しい AI 言語に積極的だという発表があった。
  • Tcl/Tk は日本でも EDA、計測機器自動化で今も使われる。

19. どの言語が生き残るか — 2026 年の予測

率直な 5 年予測:

言語5 年後生存確率理由
Mojo非常に高いAI 加速ワークロード + Modular の資本 + Lattner の信用
Crystal中Ruby コミュニティの安定した部分集合、ただし爆発的成長は難しい
Nim中Nimbus のような大きな採用先がある
Carbon中〜低Google 外採用が殆どない。5 年後もアルファのまま在り得る
V低ベータ 7 年、信頼の再構築が必要
Pony低産業スポンサー不在
Hare非常に低い意図的に小さく保つ、個人プロジェクト
Roc中Richard Feldman の信用 + Elm コミュニティ
Hylo/Vale学術的には生存産業採用は困難
Inko低〜中個人プロジェクトリスク
Koka学術的に生存影響力は大きい、直接採用は殆どない
Common Lisp生存40 年生きたので 5 年は更に生きる
Racket生存学界の道具
Tcl 9生存EDA が生きている限り
Fortran 2023生存HPC が生きている限り
Modula-3/J/Forth博物館に生存産業採用 0

最良の学習経路:

  1. メジャー言語(Python、TypeScript、Go、Rust から 2〜3 個)を先にしっかり習得する。
  2. 次に「思想を見る」ために一つを選ぶ — Mojo(システム + AI)、Roc(関数型)、Common Lisp(マクロ)、Fortran(配列)。
  3. 「会社で使えるか」は最後に考える。ほとんどのニッチ言語は採用市場が事実上ない。

20. 参考 / References

Discuss on Twitter • View on GitHub