「Nim」入門 — Cにトランスパイルするマルチパラダイム言語の現在地

はじめに

こんにちは、あそぴテックです。

今回は、最近再び注目度が上がりつつあるプログラミング言語 Nim について解説します。実は先日、AlopexDB の SQL パーサーを Rust から Nim へ置き換える検討が本格化し、その調査ドキュメントが GitHub 上で公開されました（alopex-db/docs feature/document-reorganization ブランチ）。

本記事はその一連のドキュメントとリファレンス実装をベースに、Nim を「今」触るとどう見えるのか を、ベンチマーク・開発体験・Rust との連携まで含めて整理したものです。

Nim ってどんな言語？

Nim は Andreas Rumpf によって 2008 年から開発されている、静的型付けのマルチパラダイム言語です。以下のような特徴があります。

• Python 風の構文 — インデントによるブロック、proc name(x: int): int のような読みやすいシグネチャ
• C/C++/JS へのトランスパイル — ほぼすべてのプラットフォームで動く
• 強力なマクロ — 抽象構文木（AST）を直接操作するコンパイル時メタプログラミング
• 選択可能な GC — 参照カウント（ORC）から手動アロケーションまで選べる
• --app:lib で C 共有ライブラリを直接出力可能 — ヘッダも自動生成できる

システム系言語（Rust / Zig / Go）と比較したときの Nim のポジションは、「C にトランスパイルされる Python」、あるいは 「マクロが本気の Rust」 と表現されることが多いです。

2026年6月時点の現在地

Nim は「マイナー言語」の印象を持たれがちですが、2.x 系の安定化と次期コンパイラの発表で、2026 年時点ではかなり実用的な段階に来ています。

2.2 系の安定リリース

2〜3 ヶ月ごとにパッチリリースが出ており、開発ペースは安定しています。GitHub の star 数は約 18,066、NimConf 2026 が 2026年6月20日にオンライン開催されました。

次期コンパイラ「Nimony（Nim 3.0）」

Nim 3.0 は「Nimony」と呼ばれる コンパイラの完全書き直しプロジェクト です。2025 年 11 月に v0.2 早期プレビューが出ました。

バックエンドは NIFC を経由して C（ほぼ本番品質）、LLVM（計画中、WASM 対応）、ネイティブ（最も野心的）へ広げていく計画です。

「C にトランスパイルする」設計は Nim の大きな特徴で、これが後述する C ABI ライブラリ出力の容易さ に直結しています。

ORC メモリ管理 — Nim を選ぶ理由の 1 つ

Nim には ORC (Ownership-based Reference Counting) という参照カウント方式の GC があります。2.x でデフォルトになり、--gc:orc は --mm:orc へと呼び名が変わりました（旧オプションも当面は動作します）。

ORC の特徴は次の通りです。

• 移動セマンティクスをベースに、コンパイル時に参照カウント操作を挿入
• サイクルコレクタを組み合わせているので Rc/Arc のような手動対策が不要
• バッチ解放によりオブジェクト単位のオーバーヘッドを削減
• --mm:none で完全に GC を切ることも可能 — 組み込み用途にも対応

この特性が効いてくるのが、後述する AST のような小さいオブジェクトが大量に生成されるワークロード です。

ランタイム性能 — Rust と比べてどうなのか

「Nim にすると Rust より遅くなるのでは？」という疑問は、代替言語を検討する上で必ず出てきます。AlopexDB の調査ドキュメントでは、公開ベンチマークを集約して次のような結果になっています（programming-language-benchmarks.vercel.app、2025-08、AMD EPYC 7763、nim 2.2.4 / rustc 1.88.0）。

数値計算・並列処理・正規表現は Rust が圧勝 ですが、注目すべきは Binary Trees で Nim が 46% 高速 な点です。これは「小さいノードを大量に生成・破棄しながらツリーを構築する」ワークロードで、まさに ORC が得意な領域です。

Rust の Box<T> は 1 ノードごとに alloc::alloc → alloc::dealloc のペアが走りますが、Nim の ORC は移動＋バッチ解放でこれを削減します。AST 構築・IR 変換・パーサー・コンパイラといった 「小さなヒープオブジェクトを大量に扱う」処理では、Nim は Rust より速い場合すらある ということです。

C 共有ライブラリを Nim から直接出す

Nim を面白く感じるポイントの一つは、Rust や Go では地味に面倒な 「C ABI 共有ライブラリの出力」 がほぼワンコマンドで済むことです。

proc NimMain() {.importc.}

proc mylib_init*() {.exportc, dynlib, cdecl.} =
  NimMain()

proc mylib_add*(a, b: cint): cint {.exportc, dynlib, cdecl.} =
  a + b

ビルドは次のコマンド一発です。

# .so を出力
nim c -d:release --app:lib --noMain --mm:orc -o:libmylib.so src/mylib.nim

# 同時に C ヘッダも生成
nim c -d:release --header:mylib.h --noMain --app:lib src/mylib.nim

--app:lib で共有ライブラリ、--header: で C ヘッダを自動生成、--noMain で main を省略、--mm:orc で ORC を使う、という組み合わせです。C から見ると普通の .so + .h なので、Rust や Go、Python 側は extern "C" / ctypes / cgo 経由で普通に呼べます。

これは Rust から C ライブラリを クロージャなしで安全に呼び出せる ことも意味していて、後述するように Rust ホストに Nim パーサーを埋め込む構成 に非常に向いています。

コンテナ開発環境

コンテナ上での開発体験も 2026 年時点ではかなり整っています。

• 公式イメージ: nimlang/nim — Alpine slim（約 50MB）と Ubuntu slim が選べる
• セマンティックバージョニング: nimlang/nim:2.2.10 のように完全固定できる
• マルチアーキ: amd64 / arm64 / armv7 対応
• 同梱ツール: Nim コンパイラ、Nimble、gcc/musl-gcc、Node.js（JS バックエンド用）、SSL

Dockerfile はこれだけで動きます。

FROM nimlang/nim:2.2-alpine-slim AS builder

WORKDIR /build
COPY . .

RUN nimble install -y --depsOnly && \
    nim c -d:release --app:lib --noMain --mm:orc \
      -o:libmylib.so src/mylib.nim

VS Code Devcontainer なら以下のようなイメージです。

{
  "name": "Nim Dev",
  "image": "nimlang/nim:2.2-alpine-regular",
  "customizations": {
    "vscode": {
      "extensions": ["nimsaem.nimvscode", "saem.vscode-nim"]
    }
  },
  "postCreateCommand": "nimble install -y npeg"
}

実プロジェクトでの体感 — SQL パーサーを Nim で書いた話

AlopexDB チームは、既存の Rust 手書き SQL パーサーを Nim に移植する試験実装を行いました（alopex-db/alopex experiment/sql-parser-trial）。ここでの計測が非常に象徴的です。

同じテストケース（58 テスト）を全通しした状態で、コード量は 37%、ビルド時間は 63 倍高速 という結果です。

Nim 側の実装コアは意外なほど素直な書き方でした。AST は object variant（判別共用体）で表現されます。

type
  SqlNodeKind* = enum
    nkSelect, nkInsert, nkUpdate, nkDelete
    nkIdentifier, nkStringLit, nkIntLit, nkBoolLit
    nkBinaryOp, nkUnaryOp, nkColumnRef, nkFunctionCall
    # ...

  SqlNode* = ref object
    case kind*: SqlNodeKind
    of nkIdentifier, nkStringLit:
      strVal*: string
    of nkIntLit:
      intVal*: int64
    of nkBinaryOp:
      binOp*: BinaryOpKind
      binLeft*, binRight*: SqlNode
    else:
      children*: seq[SqlNode]

Rust の enum + Box<T> に相当する構造ですが、Box の明示や #[allow(clippy::large_enum_variant)] に相当する回避策が不要 で、変換の可読性がだいぶ違います。

Nim 2.x の気になるところ

もちろん万能ではありません。今のところ以下は注意点として挙げられます。

• std/parsesql が Nim 2.0 で標準ライブラリから nimble パッケージに移動 — nimble install parsesql が必要
• --gc:orc → --mm:orc の名称変更 — 旧オプションは非推奨警告が出る
• Nimble パッケージ名にハイフンが使えない — nim-sql-parser は nim_sql_parser にリネームする必要がある
• エコシステムは Rust ほど広くない — 特に Web/DB ドライバは選択肢が少ない
• エラーメッセージが Rust より素朴 — 型が絡む問題の原因究明にコツが要る

とはいえ、これらは 2.x 系が安定に達している現在では実運用に耐えるレベルまで整理されており、上記の Alopex での試験実装でも修正箇所は --gc:orc → --mm:orc の 1 箇所のみ で済んだと報告されています。

まとめ — 誰にとって Nim は「今」使うべき言語か

Nim を試す価値が特に高いのは、次のようなケースだと思います。

• AST・IR・パーサー・コンパイラなど「小さいオブジェクトを大量に扱う」領域
• C ライブラリを綺麗に切り出して、別言語からリンクしたい場面
• Rust のビルド時間がボトルネックになっているプロジェクトの、パーサーやコード生成器の切り出し
• Python ライクな読み書きしやすさとネイティブ性能の両立が欲しいシステムスクリプト

2.2 安定版が実運用に耐え、Nimony（3.0）でさらにビルド速度・メモリ効率が改善される見込みがある、というのが 2026 年時点の Nim の立ち位置です。

次回は、同じ検討の中でもう一方の候補として挙がっている純粋関数型言語 Roc を、「「Roc」入門 — Elm譲りの純粋関数型言語がRustホストと組む未来」で紹介しています。そちらもぜひご覧ください。

それではまた！

参考リンク

• Nim 公式サイト
• nim-lang/Nim (GitHub)
• nimlang/nim Docker Hub
• npeg — PEG for Nim
• Nim Compiler User Guide
• Nim Backend Integration (C/C++ FFI)
• alopex-db/docs — Alopex DB 調査ドキュメント
• alopex-db/alopex experiment/sql-parser-trial