💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 2026年、「ニッチ言語」がふたたび面白くなった

2010年代後半の言語風景は単調だった。Python・JavaScript・Java・Go・Rust・C++・TypeScript——事実上この7つで産業の90%を占め、それ以外は「趣味」に分類されていた。

2026年の風景はもっと厚みがある。

- **Mojo 25.x** が一部オープンソース化され、MLインフラの「本気の候補」として入ってきた。Modular MAX推論エンジンが実戦ワークロードで検証されている。

- **Carbon Language** がGoogle内部でC++マイグレーションの候補として実験されている。Successor language という明快な座標。

- **Roc 0.x** がRichard Feldman主導で、関数型と高速コンパイル、Elm 風のエラーメッセージを持ち込んだ。

- **Crystal 1.14+** はManas Tecnologíaと一部スタートアップで本番運用されている。Ruby 構文に静的型。

- **Pony 0.59+** のactor モデルとcapabilities は安全な並行性の生きたリファレンスだ。

- **Hare 0.25+** はDrew DeVaultが作るミニマルなシステム言語。Cと同じ領域、違う美意識。

- **Vale・Hylo・Austral** のようなメモリモデル実験言語が「Rust の向こう側」を探している。

- **Odin・Jai・Beef** のようなゲーム言語はインディーシーンで実際にゲームを出荷している。

- **Gleam 1.x** はBEAM(Erlang VM) の上に型安全な関数型を載せ、本番採用を増やしている。

「なぜわざわざニッチ言語を使うのか」はもはや愚問ではない。ドメイン適合性、学習価値、性能特性、コミュニティ——理屈の通る根拠が増えた。本稿はその地形全体を一気に整理する。

> 一行要約: **「この言語は何を上手くこなすか、誰がすでに使っているか、1年後も生き残っているか。」** この3つの問いがニッチ言語選択の90%を決める。

第1章 · なぜニッチ言語を見るのか — 学習・ドメイン・好奇心の三角形

ニッチ言語を本気で見る理由はだいたい3つに収まる。

1. **学習** — 別のパラダイムに触れるとメイン言語の腕が上がる。Haskell を一学期やった人は Python でも良いコードを書く。Pony を触ったことがある人は Go のチャネルをより批判的に見る。

2. **ドメイン適合性** — Mojo は ML インフラ、Crystal は高速 Web サービス、Carbon は C++ マイグレーション、Odin はゲーム。ドメインさえ合えば、ニッチ言語はメインストリームより生産的だ。

3. **好奇心・性能特性** — GC なし、低レイテンシ、capabilities、value semantics のような特定の性質が必要なシステム。

逆に避けるべき理由もはっきりしている。

- 「クールに見えるから」— 半年後にメンテナが見つからない。

- 「速そうだから」— 同じアルゴリズムなら、メインの言語との差は大したことがない場合がほとんど。

- 「最新トレンドだから」— トレンドは進行中であって到着点ではない。

ニッチ言語の真の価値は「メイン言語では見えなかった視野」を与えてくれることだ。その視野はコードを書くたびに積み重なる。

第2章 · Crystal — Ruby の美意識に静的型とネイティブコンパイル

**Crystal 1.14+** (2014年〜、Manas Tecnología) の設計命題はシンプルだ。「Ruby のように見えて、C のように走る。」Ruby 構文に慣れていれば、初めて見る Crystal コードもすぐ読める。

Crystal: 静的型 + 型推論

def fib(n : Int32) : Int64

return n.to_i64 if n < 2

fib(n - 1) + fib(n - 2)

end

puts fib(30)

主な特徴:

- **静的型 + 強力な型推論** — 明示せずともコンパイル時に決まる。

- **LLVM バックエンド** — ネイティブバイナリ。Ruby 比で 10~100 倍のベンチマーク差はよくある。

- **Fiber ベースの並行性** — Go の goroutine に似たモデル。

- **マクロシステム** — コンパイル時メタプログラミング。

- **Shards** — gem のようなパッケージマネージャ。

本番運用:

- **Manas Tecnología** — 創始者の会社。自社サービスで運用。

- **Heroku 系の一部スタートアップ** — Ruby から Crystal への部分的な移行。

- **Kemal**・**Lucky** といった Web フレームワークが本番運用されている。

2026 年の Crystal は「Ruby の代替」ではなく「Ruby の視野を保ったまま性能が欲しい時」の選択肢だ。Rails 全体を Crystal に置き換えるシナリオは珍しく、ホットスポットなサービスだけ切り出して移植するパターンが一般的。

第3章 · Pony — Actor モデルと capabilities が作る安全な並行性

**Pony 0.59+** のデザインは、他の言語が本格的に取り入れていない領域にある。**reference capabilities** というシステムで、データ競合がコンパイル時に不可能になる。

// Pony: actor モデル

actor Counter

var _count: U64 = 0

be increment() =>

_count = _count + 1

be report(env: Env) =>

env.out.print("count: " + _count.string())

主な特徴:

- **Actor モデル** — Erlang/Elixir に近いが静的型。

- **Reference capabilities** — `iso`、`val`、`ref`、`box`、`tag`、`trn` の 6 つの capability がオブジェクト共有のあり方をコンパイル時に保証する。

- **No data races** — capability システムが保証。

- **No deadlocks** — actor 間にロックがない。

- **Per-actor GC** — actor 単位で分離されたガーベジコレクション。

本番運用:

- **Wallaroo Labs** — ストリーミングデータ処理。買収と整理の後、Pony 最大の production user が消えた。

- 現在は学術・小規模システム中心。

Pony は production 採用としては小さいが、「並行性の安全性を型システムでどう表現するか」の生きたリファレンスだ。Rust の `Send`/`Sync` 以前の世代のアイデアが、より精緻な形で Pony にある。

第4章 · Mojo — Python superset で SIMD・GPU まで

**Mojo 25.x** (2023年〜、Modular、Chris Lattner) は最新の注目株だ。スローガンは明快。「Python の構文で、C++ の性能と SIMD/GPU まで。」

Mojo: Python superset

fn fib(n: Int) -> Int:

if n < 2:

return n

return fib(n - 1) + fib(n - 2)

fn main():

print(fib(30))

主な特徴:

- **Python superset** — 既存の Python コードがほぼそのまま動く。

- **MLIR ベース** — コンパイラ基盤が Chris Lattner の LLVM・Swift・MLIR の系譜。

- **SIMD/GPU が一級市民** — ベクトル演算が言語レベル。

- **Ownership** — Rust 風のメモリ安全 + 値セマンティクス。

- **Modular MAX** — Mojo 自身で実装された推論エンジン。PyTorch/TF 互換。

2025 年のオープンソース化:

- **Modular が一部コンポーネントを MIT ライセンスで公開**。標準ライブラリと一部のランタイム。

- コンパイラ本体には依然として closed source の部分がある。

- コミュニティの期待と批判が併存。

本番運用:

- **Modular MAX** — Modular の推論エンジン。Mojo 自身で実装。

- ML インフラ系スタートアップで部分採用。

2026 年の Mojo は「Python のように書きたいが PyTorch より速いインフラが必要な時」の候補だ。一般的なバックエンド言語としての Mojo はまだ珍しい。

第5章 · Carbon — C++ 後継候補、Google の実験

**Carbon Language** (2022年〜、Google、experimental) は明確な座標を持つ。**C++ successor language**。Rust や Go ではなく、「C++ のコードを徐々に移行できる言語」が目標。

// Carbon: C++ 後継候補

package Sample api;

fn Fib(n: i32) -> i64 {

if (n < 2) { return n as i64; }

return Fib(n - 1) + Fib(n - 2);

}

fn Main() -> i32 {

Print("{0}", Fib(30));

return 0;

}

主な特徴:

- **C++ interop** — C++ コードと双方向で相互運用。1 つのプロジェクトに 2 言語が同居する。

- **Memory safety roadmap** — メモリ安全性をオプションで段階導入。

- **Modern syntax** — C++ の歴史的な重荷を取り除く。

- **No backwards compat guarantee** — C++ のように 35 年間の互換性負担がない。

2026 年の現状:

- 依然として **experimental**。本番採用は推奨されていない。

- Google 内部での toolchain 実験。

- 標準というより「C++ の方向性についての思考実験」に近い。

Rust が「C++ とは違う言語で一から書き直そう」なら、Carbon は「C++ のコードベースを残したまま、徐々に後継言語へ移行しよう」だ。同じ問題に対する違う答え。

第6章 · Hare — Drew DeVault のミニマルなシステム言語

**Hare 0.25+** (2022年〜、Drew DeVault ほか) は明らかに小さな言語だ。**C と同じ領域、違う美意識。**

// Hare: ミニマルなシステム言語

use fmt;

export fn main() void = {

fmt::println("Hello, world!")!;

};

主な特徴:

- **No GC** — 手動メモリ管理。

- **No generics** — 意図的に抜いた機能。シンプルさを優先。

- **Small standard library** — 明示的かつ小さい。

- **QBE backend** — LLVM ではなく QBE コンパイラバックエンド。ビルドが速く toolchain が小さい。

- **AGPL/MPL ライセンス** — 自由ソフトウェアの倫理。

設計思想:

- 「C が 50 年も生きているのは良いことだ。ただ、その 50 年の間違いは繰り返さない。」

- Generics がないのはバグではなく機能。シンプルさと可読性を優先。

- 標準ライブラリが小さいのも機能。依存爆発を防ぐ。

2026 年の Hare は本番運用よりも、「C の精神を別のやり方で受け継ぐ言語」の生きた例だ。Drew DeVault の他のプロジェクト(sourcehut、wlroots) と趣旨を共有する。

第7章 · Roc — Elm の影響を受けた関数型、高速コンパイル

**Roc** (2020年〜、Richard Feldman) は関数型陣営の野心作だ。スローガンは「fast, friendly, functional」。

Roc: Elm の影響を受けた関数型

app "fib"

packages { pf: "platform/main.roc" }

imports [pf.Stdout]

provides [main] to pf

fib = \n ->

if n < 2 then n

else (fib (n - 1)) + (fib (n - 2))

main = Stdout.line (Num.toStr (fib 30))

主な特徴:

- **Purely functional** — Elm のように純粋関数型。

- **Static types + 強い推論** — 明示しなくてもほぼ全てが推論される。

- **Friendly error messages** — Elm 風のコンパイラエラー。

- **Platforms** — platform (host) が I/O と effects を担い、Roc コードは純粋を保つ。

- **No null、no exceptions** — 明示的な Result と Task。

- **Fast compile** — コンパイル速度が設計目標。

本番運用:

- 小規模だが成長中。

- Web サーバ、CLI ツール。

- platform モデルにより様々な host に埋め込める。

Roc は「関数型がまっとうな選択肢になる一つの道」のケーススタディだ。Elm の美意識を Web を超えてシステム領域に持ち込んだ実験。

第8章 · Vale — gen+region メモリ、no GC、no borrow checker

**Vale** はメモリモデル実験の最前線にある言語だ。**Generational references** と **region-based memory** で、GC なしでも borrow checker の学習曲線を避ける。

// Vale: generational references

exported func main() {

println("Hello, Vale!");

}

主な特徴:

- **Generational references** — ポインタに generation 番号を付け、use-after-free を実行時に防ぐ。

- **Regions** — メモリ領域単位で GC・manual・arena を選べる。

- **No borrow checker** — Rust の lifetimes のようなコンパイル時制約がない。

- **No GC** — デフォルトでガーベジコレクションなし。

- **Linear types オプション** — リソース追跡が必要なら明示的に選択。

設計思想:

- 「Rust 並みに速く、Java 並みに書きやすく。」

- borrow checker の学習コストを generational references で迂回。

- region でメモリ戦略をコード単位で選べる。

Vale は本番運用というより「メモリ安全性を別の解法で解いたら」の研究室だ。アイデア自体が他言語へ波及する可能性が高い。

第9章 · Virgil — Google Research の研究言語

**Virgil** (Ben L. Titzer、Google) は研究言語陣営のベテランだ。組み込みとシステムの間に座標を置く。

// Virgil: 研究言語

def main() {

System.puts("Hello, Virgil!\n");

}

主な特徴:

- **AOT コンパイル** — Ahead-of-time コンパイル。

- **No GC** — 静的メモリモデル。

- **Tiny runtime** — 組み込みフレンドリー。

- **Compile-time initialization** — 初期化をコンパイル時に処理。

- **WebAssembly バックエンド** にも対応。

Virgil は「組み込みと WASM の間で小さなランタイムを保ちつつモダンな言語機能を持つ道」の研究事例だ。直接本番で採用することは稀でも、アイデアが他所へ流れていく。

第10章 · Gleam — BEAM の上の型安全な関数型

**Gleam 1.x** (Louis Pilfold) ははっきりした価値提案を持つ。**Erlang VM (BEAM) の上に型安全な関数型を載せた言語。**

// Gleam: BEAM 上の型安全な関数型

pub fn main() {

io.println("Hello, Gleam!")

}

主な特徴:

- **Strong static typing** — すべての型がコンパイル時に決まる。

- **Erlang interop** — Erlang/Elixir ライブラリをそのまま呼べる。

- **JS target** — JavaScript にもコンパイル。

- **Friendly syntax** — Rust と Elm の影響を感じる。

- **Production users が増加中**。

Gleam は「Erlang/Elixir の actor・OTP の堅牢さ」と「静的型の安全性」の両方を欲しい人の答えだ。2026 年は本番採用が急速に増えている。

第11章 · Grain — 型付き関数型、WebAssembly 優先

**Grain** は最初から WebAssembly ターゲットを前提に設計された関数型言語だ。

// Grain: WASM 優先の関数型

print("Hello, Grain!")

主な特徴:

- **WebAssembly 優先** — 第一ターゲットが WASM。

- **Strong static types** — 関数型に馴染む型システム。

- **GC あり** — WASM 環境向けの GC。

- **No null** — Option・Result で明示的に扱う。

Grain は「WebAssembly がどこでも走る時代」に合う関数型オプションの一つだ。エコシステムはまだ小さいが、WASM が大きくなれば一緒に育つ可能性がある。

第12章 · Chapel — HPC と並列プログラミング

**Chapel** (Cray/HPE) は HPC (High Performance Computing) 陣営の言語だ。並列・分散プログラミングを明示的に一級市民として扱う。

// Chapel: HPC の並列

forall i in 1..10 do

writeln("Hello from iteration ", i);

主な特徴:

- **First-class parallelism** — 並列ループとタスクが言語レベル。

- **Locality awareness** — locale 概念で分散ノードに配分。

- **Productivity + Performance** — 両方を狙う。

- **スーパーコンピュータ環境フレンドリー** — Cray クラスのマシンでの大規模分散。

Chapel は一般的な Web バックエンド向けの言語ではない。だが numerical computing、scientific HPC では本気の候補だ。Mojo とは別系統の「performance」を狙う。

第13章 · Inko — 並行 OO、owned values

**Inko** (Yorick Peterse) は owned values と並行性を組み合わせた OO 言語だ。

// Inko: 並行 OO

class async Main {

fn async main {

Stdout.new.print('Hello, Inko!')

}

主な特徴:

- **Async-first** — actor と軽量プロセス。

- **Owned values** — Rust に似た ownership。

- **No null** — Option を使う。

- **Pattern matching** — 強力なパターンマッチ。

- **Erlang・Pony の影響**。

Inko は本番採用は小さいが、「OO 言語のモダン化」という座標で意味のある実験だ。

第14章 · Hylo — mutable value semantics

**Hylo (formerly Val)** (Dave Abrahams ほか) は明示的に **mutable value semantics** を中核哲学に据えた言語だ。

// Hylo: mutable value semantics (signature 例)

public fun main() {

print("Hello, Hylo!")

}

主な特徴:

- **Value semantics** — すべてが値。参照共有なし。

- **Mutable values** — 値を mutate できるが aliasing は発生しない。

- **No borrow checker** — value semantics が安全性を自然に与える。

- **Generic programming** — C++ template の精神的な後継。

Hylo は Dave Abrahams の C++ generic 作業の延長線にある。C++ committee でできなかったことを一から再設計する。

第15章 · Austral — linear types の実用化

**Austral** は **linear types** を中核機能に据えたシステム言語だ。

// Austral: linear types

module Main is

public function Main(): ExitCode is

return ExitSuccess();

end

主な特徴:

- **Linear types** — すべてのリソースがちょうど 1 回消費される。

- **No GC** — 手動メモリ。

- **Capability-based security** — システムリソースのアクセスに capability が必要。

- **Small specification** — 言語仕様を意図的に小さく。

Austral は「linear types を本気で実用言語として持ち込んだらどう見えるか」の答えだ。Rust の affine types より厳しい。

第16章 · Odin — Ginger Bill のゲーム言語

**Odin** (Ginger Bill、2016年〜) はゲームプログラミングを第一ターゲットにしたシステム言語だ。Pascal の美意識をモダン化した印象。

// Odin: ゲームフレンドリーなシステム言語

package main

main :: proc() {

fmt.println("Hello, Odin!")

}

主な特徴:

- **No GC, manual memory** — ゲームフレンドリー。

- **Custom allocators** — メモリ割り当て戦略をコードで選ぶ。

- **Struct-of-arrays フレンドリー** — SoA 変換を言語でサポート。

- **Foreign function interface** — C との滑らかな相互運用。

- **Vendor library** — よく使う OpenGL・Vulkan・SDL2 バインディングを同梱。

本番運用:

- **EmberGen** (JangaFX) — VFX シミュレーションツール。

- 一部のインディーゲーム。

- **Bill 本人のゲーム開発**。

Odin は「C の精神をゲームに合わせてモダン化した」言語の一つの答えだ。Zig・Jai と領域が被るが美意識が違う。

第17章 · Jai — Jonathan Blow の closed-beta ゲーム言語

**Jai** (Jonathan Blow、非公開ベータ) は The Witness と Braid の開発者が作るゲーム言語だ。2026 年時点でも closed beta。

主な特徴:

- **No GC** — ゲームフレンドリー。

- **Compile-time execution** — コンパイル時に任意のコードを実行。metaprogramming の別解。

- **Data-oriented design フレンドリー**。

- **Fast iteration** — コンパイル速度が中核。

2026 年の現状:

- 依然として非公開ベータ。

- 映像中心に公開され、本番ゲームの出荷は限定的。

- コミュニティの一部から「いつ公開されるのか」の期待と懐疑が併存。

Jai は本番として評価するのは難しいが、「compile-time execution を本気で突き詰めたら」の思考実験として価値がある。

第18章 · その他のシステム・ゲーム・実験言語 — V・Wuffs・Mun・Beef・Pinion・Helium

短く触れておくに値する言語たち。

- **V (Volt)** — Go と Rust の影響。マーケティングと実際の進捗の差で議論を呼んでいる。それでも、小さなバイナリと速いコンパイルなど明確な魅力点がある。

- **Wuffs** — Google。「Safe-by-default subset of C」。画像デコーダや解凍のような領域に特化。Chrome の一部コーデックが Wuffs で書かれている。

- **Mun** — ゲームの hot-reload フレンドリーなスクリプティング。小さな組み込み言語。

- **Beef** — BeefLang。C# の影響。ゲームフレンドリー。IDE とコンパイラを一緒に開発。

- **Pinion**・**Helium** — 研究段階の実験言語。

このグループは「本番推奨」というより「アイデア市場」だ。1つ2つがメインストリームに影響を与えるかもしれないし、すべて消えるかもしれない。

第19章 · 意思決定マトリクス — どのドメインにどの言語を見るか

ドメイン別の意思決定ガイド。

| ドメイン | 本気の候補 | ニッチな候補 |

| --- | --- | --- |

| C/C++ 置換 | Rust、Zig、Go | Carbon、Hare、Odin |

| Python 性能 | Cython、Numba、PyPy | Mojo |

| 関数型 | F#、OCaml、Haskell | Roc、Gleam、Grain |

| Erlang/BEAM | Elixir、Erlang | Gleam |

| 並行・actor | Erlang/Elixir、Akka on the JVM | Pony、Inko |

| Ruby 代替 | Ruby + JIT、Crystal | Crystal |

| ゲーム | C++、Rust + Bevy | Odin、Jai、Beef |

| HPC | C++、Fortran、Julia | Chapel、Mojo |

| WASM 優先 | Rust、AssemblyScript | Grain、Virgil |

| メモリ実験 | Rust | Vale、Hylo、Austral |

| 組み込み | C、Rust embedded | Hare、Virgil |

| 画像・コーデック | C、Rust | Wuffs |

「本気の候補」は本番採用事例が十分にあり、採用市場も存在する。「ニッチな候補」はドメインさえ合えば非常に強力だが、採用・エコシステムのリスクがある。

第20章 · 採用・コミュニティ・韓国・日本 — 現実チェック

ニッチ言語を本気で見るなら、市場の現実も見るべきだ。

- **採用市場**:

- ほとんどがゼロから極小。Crystal・Gleam・Mojo は時折ジョブ募集が見える。

- Carbon・Jai・Vale・Hylo はほぼ募集なし。

- ただし「主力としての採用はないがサイドプロジェクトなら歓迎」する会社は増えた。

- **コミュニティ規模** (GitHub スター、Discord メンバー基準のおおよそ):

- Mojo: 最大かつ最速で成長。

- Crystal、Gleam、Roc: 中規模だがアクティブ。

- Pony、Hare、Vale、Hylo: 小さいが結束力がある。

- Jai、Carbon: 情報が制限的。

- **韓国コミュニティ**: ほぼすべてのニッチ言語で非常に小さい。Crystal・Mojo の発表資料が一部ある程度。

- **日本コミュニティ**: Crystal Tokyo Meetup、Mojo 関連の日本コミュニティが存在する。日本はニッチ言語に比較的寛容。

- **学習資料**:

- 公式ドキュメントはどの言語も平均以上。

- 書籍があるのは Crystal・Mojo 程度。

- 韓国語・日本語の資料は極めて少ない。

ニッチ言語を会社に導入する際の最大のリスクは「自分が抜けたら誰がメンテするか」だ。この問いに答えが出ないなら本気で再考すべき。

第21章 · 学習パス — 一度に多くを見すぎないこと

ニッチ言語を学ぶ時の推奨パス。

1. **メイン言語 1〜2 個を固める** — Python・Rust・Go・TypeScript のうち少なくとも 2 つは本気で。

2. **別のパラダイムを 1 言語深掘り** — 関数型なら OCaml か Haskell を一学期。並行性なら Erlang/Elixir で 1 プロジェクト。

3. **その次にニッチを見る** — メインが固まっていれば、ニッチ言語のアイデアが見えやすい。

4. **小さなプロジェクトから始める** — CLI ツール、小さな Web サービス。初日から本番投入は危険。

5. **公式ドキュメント → 標準ライブラリ → 小さな OSS コード** — 書籍はオプション。ドキュメントが最も正確。

6. **コミュニティを 1 年観察** — Discord、GitHub、公式ブログ。半年あれば「死につつある言語 vs 育つ言語」が見える。

覚えておくこと: ニッチ言語に費やした時間はメイン言語の実力に積み重なる。それ自体が報酬だ。

エピローグ — 結論と推奨事項

ニッチ言語の景色を一行で要約するとこうなる。

> 「メインストリームが 80% の仕事をこなす。ニッチ言語が残りの 20% と、次の 100% の視野をくれる。」

**2026 年の推奨事項**:

1. **Crystal** — Ruby 構文に静的型とネイティブコンパイルが必要なら安全な候補。

2. **Gleam** — Erlang/Elixir のモデルが好きで型も欲しいなら本気の選択肢。

3. **Mojo** — Python・ML インフラで性能が必要なら見ておく価値あり。

4. **Roc** — Elm の美意識をサーバ・CLI 領域に持ち込みたいなら。

5. **Odin** — ゲーム・システム領域で C より現代的な美意識が欲しいなら。

6. **その他 (Carbon・Jai・Vale・Hylo・Austral)** — 学習・好奇心で推奨。本番導入は慎重に。

ニッチ言語は「道具」というより「視野」だ。その視野はメイン言語に戻っても消えない。

— ニッチモダン言語 2026、了。

References

1. Manas Tecnología. "Crystal Programming Language." [https://crystal-lang.org/](https://crystal-lang.org/)

2. Pony Project. "Pony Programming Language." [https://www.ponylang.io/](https://www.ponylang.io/)

3. Modular. "Mojo Programming Language." [https://www.modular.com/mojo](https://www.modular.com/mojo)

4. Google. "Carbon Language GitHub." [https://github.com/carbon-language/carbon-lang](https://github.com/carbon-language/carbon-lang)

5. DeVault, D. "Hare Programming Language." [https://harelang.org/](https://harelang.org/)

6. Feldman, R. "Roc Programming Language." [https://www.roc-lang.org/](https://www.roc-lang.org/)

7. Vale Language. "Vale." [https://vale.dev/](https://vale.dev/)

8. Titzer, B. L. "Virgil Programming Language." [https://github.com/titzer/virgil](https://github.com/titzer/virgil)

9. Pilfold, L. "Gleam Programming Language." [https://gleam.run/](https://gleam.run/)

10. Grain Lang. "Grain Programming Language." [https://grain-lang.org/](https://grain-lang.org/)

11. Cray/HPE. "Chapel Parallel Programming Language." [https://chapel-lang.org/](https://chapel-lang.org/)

12. Peterse, Y. "Inko Programming Language." [https://inko-lang.org/](https://inko-lang.org/)

13. Abrahams, D. "Hylo Programming Language." [https://www.hylo-lang.org/](https://www.hylo-lang.org/)

14. Austral Lang. "Austral Programming Language." [https://austral-lang.org/](https://austral-lang.org/)

15. Bill, G. "Odin Programming Language." [https://odin-lang.org/](https://odin-lang.org/)

16. Blow, J. "Jai Programming Language Presentations." [https://www.youtube.com/@jblow888](https://www.youtube.com/@jblow888)

17. V Project. "V Programming Language." [https://vlang.io/](https://vlang.io/)

18. Google. "Wuffs Programming Language." [https://github.com/google/wuffs](https://github.com/google/wuffs)

19. Mun Lang. "Mun Programming Language." [https://mun-lang.org/](https://mun-lang.org/)

20. Beef Lang. "Beef Programming Language." [https://www.beeflang.org/](https://www.beeflang.org/)

21. Lattner, C. "Modular Blog." [https://www.modular.com/blog](https://www.modular.com/blog)

22. Feldman, R. "Roc Talks." [https://www.youtube.com/@rtfeldman](https://www.youtube.com/@rtfeldman)

23. Crystal Tokyo. "Crystal Tokyo Meetup." [https://crystal.tokyo/](https://crystal.tokyo/)

24. Carbon Working Group. "Carbon Language Design Documents." [https://github.com/carbon-language/carbon-lang/tree/trunk/docs](https://github.com/carbon-language/carbon-lang/tree/trunk/docs)

25. Roc Zulip. "Roc Community." [https://roc.zulipchat.com/](https://roc.zulipchat.com/)