Getting Started with Nim: A Multi-Paradigm Language That Transpiles to C

Introduction

Hello, Asopi Tech here.

In this article we take a look at Nim, a programming language that has been gaining renewed attention lately. The trigger for this deep dive was a recent investigation by the AlopexDB team, which is seriously considering replacing its Rust SQL parser with a Nim implementation. Their research is now public on GitHub (alopex-db/docs, feature/document-reorganization branch).

This article uses those documents and the reference implementation as a base to answer the question: what does Nim look like today, in 2026? — with benchmarks, developer experience, and Rust interop included.

What kind of language is Nim?

Nim is a statically typed, multi-paradigm language developed by Andreas Rumpf since 2008. Its distinctive traits are:

• Python-like syntax — indentation-based blocks and readable signatures like proc name(x: int): int
• Transpiles to C/C++/JS — runs on virtually every platform
• Powerful macros — compile-time metaprogramming that directly manipulates the AST
• Choice of GC — from reference counting (ORC) to fully manual allocation
• --app:lib outputs a C shared library directly — headers are auto-generated

When placed alongside other systems languages (Rust / Zig / Go), Nim is often described as “Python that transpiles to C” or “Rust with serious macros.”

Where does Nim stand in mid-2026?

Nim is sometimes dismissed as a “minor language,” but with the 2.x series stabilizing and the next-generation compiler being announced, it has become quite practical as of 2026.

The stable 2.2 release line

Patch releases arrive every 2–3 months and development is on a steady pace. GitHub star count sits at around 18,066, and NimConf 2026 was held online on June 20, 2026.

The next-gen “Nimony” (Nim 3.0) compiler

Nim 3.0 is codenamed “Nimony” — a complete rewrite of the compiler. An early v0.2 preview was released in November 2025.

Backend roadmap: NIFC → C (nearly production-quality), NIFC → LLVM (planned, includes WASM), NIFC → native (most ambitious).

The “transpiles to C” design is fundamental to Nim, and this directly enables easy C ABI shared library output, which we’ll come back to later.

ORC memory management — one of the main reasons to pick Nim

Nim ships with ORC (Ownership-based Reference Counting), a reference-counting GC. It became the default in 2.x, and the flag was renamed from --gc:orc to --mm:orc (the old form still works with a deprecation warning).

ORC’s characteristics:

• Move semantics as a baseline; refcount ops are inserted at compile time
• Combined with a cycle collector, so manual Rc/Arc gymnastics are unnecessary
• Batch deallocation reduces per-object overhead
• --mm:none disables the GC entirely — suitable for embedded

Where ORC really shines is a class of workload we’ll see later: generating huge numbers of small objects like AST nodes.

Runtime performance — how does Nim compare to Rust?

“Will switching to Nim make things slower than Rust?” is the first question that comes up when considering alternatives. AlopexDB’s research aggregates public benchmarks and reports the following (programming-language-benchmarks.vercel.app, 2025-08, AMD EPYC 7763, nim 2.2.4 / rustc 1.88.0):

Rust dominates numeric and parallel workloads, but note the standout result: Nim is 46% faster than Rust on Binary Trees. That’s exactly the “allocate many small nodes, build up a tree, then dispose” workload where ORC excels.

Rust’s Box<T> requires an alloc::alloc / alloc::dealloc pair per node, while Nim’s ORC combines moves with batch deallocation. Which is to say: for the “many small heap objects” workloads that show up in AST construction, IR transformation, parsers and compilers, Nim can actually be faster than Rust.

Emitting a C shared library from Nim

One genuinely fun thing about Nim is that emitting a “C ABI shared library” — which is surprisingly annoying in Rust and Go — is essentially a one-liner.

proc NimMain() {.importc.}

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

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

Build with:

# emit a .so
nim c -d:release --app:lib --noMain --mm:orc -o:libmylib.so src/mylib.nim

# also emit a C header
nim c -d:release --header:mylib.h --noMain --app:lib src/mylib.nim

--app:lib for shared libraries, --header: to auto-generate a C header, --noMain to skip main, --mm:orc for ORC. From C’s point of view, you get a plain .so + .h — Rust (via extern "C"), Go (via cgo), Python (via ctypes), all call it as expected.

This also means Rust can safely embed a Nim library without any closure ceremony — which sets up the “Rust host with Nim parser” architecture we’ll look at later.

Container development environment

Container tooling is well-developed as of 2026.

• Official image: nimlang/nim — pick from Alpine slim (~50MB) or Ubuntu slim
• Semantic versioning: nimlang/nim:2.2.10 locks you to a specific patch
• Multi-arch: amd64 / arm64 / armv7
• Bundled tools: Nim compiler, Nimble, gcc/musl-gcc, Node.js (for the JS backend), SSL

A minimal 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"
}

Real-world signal — writing a SQL parser in Nim

The AlopexDB team ported their existing Rust hand-written SQL parser to Nim as a trial (alopex-db/alopex experiment/sql-parser-trial). The measurements are striking:

Same 58 tests all passing, and the numbers land at 37% of the LoC and a 63x faster build.

The Nim implementation itself is surprisingly readable. AST is expressed as an object variant (tagged union):

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]

This is structurally equivalent to Rust’s enum + Box<T>, but no explicit Box, no #[allow(clippy::large_enum_variant)] — the code stays remarkably clean.

Gotchas of the 2.x era

Nim isn’t a silver bullet. A few things to watch out for:

• std/parsesql was moved out of stdlib in Nim 2.0 — install with nimble install parsesql
• --gc:orc renamed to --mm:orc — the old form emits a deprecation warning
• Hyphens are disallowed in Nimble package names — nim-sql-parser becomes nim_sql_parser
• The ecosystem is smaller than Rust’s — especially for web / DB drivers
• Error messages are more terse than Rust’s — type-related issues take some getting used to

These are livable in practice, though. The Alopex team’s Nim port required exactly one change: --gc:orc → --mm:orc.

Who is Nim for, right now?

Nim is worth serious consideration if you fall into one of these buckets:

• AST / IR / parsers / compilers — anywhere many small objects fly around
• You need a clean C library that other languages link against
• Your Rust project’s build time is holding development back, especially in the parser / codegen layers
• You want something with Python-like ergonomics and native performance for systems scripting

The 2.2 line is stable enough for production, and Nimony (3.0) promises to improve build times and memory usage further. That’s where Nim sits in 2026.

Next up: “Getting Started with Roc: A Pure Functional Language Meant to Ride Alongside Rust” — the other candidate that came up in the same investigation. Please read that one too!

References

• Nim official site
• nim-lang/Nim (GitHub)
• nimlang/nim on Docker Hub
• npeg — PEG for Nim
• Nim Compiler User Guide
• Nim Backend Integration (C/C++ FFI)
• alopex-db/docs — AlopexDB research docs
• alopex-db/alopex experiment/sql-parser-trial