---
title: "Nim Language Overview & Ecosystem (2026)"
description: "Nim ecosystem overview for AI coding agents: what Nim is, the Nim 1.x to 2.0 memory-management default change (ORC), toolchain installation via choosenim, nimble vs atlas package management, and the compiler invocation model (nim c/cpp/js/r)."
language: nim
framework: null
category: language_overview
tags:
  - nim
  - ecosystem
  - memory-management
  - arc-orc
  - toolchain
  - choosenim
  - nimble
  - systems-programming
  - compiles-to-c
keywords:
  - what is nim programming language
  - nim 2.0 orc default memory management
  - choosenim install nim version manager
  - nimble vs atlas package manager
  - nim compiler nim c nim cpp nim js
  - nim vs rust vs go
last_updated: "2026-07-07"
difficulty: intermediate
version: "Nim >= 2.0 (stable line 2.2, currently 2.2.10, April 2026)"
related:
  - ./best_practices.md
  - ./common_pitfalls.md
  - ./metaprogramming.md
  - ./concurrency.md
  - ./testing.md
  - ./interop_ffi.md
  - ../rust/README.md
  - ../go/README.md
  - ../../core/devops/autonomous_least_privilege_environments.md
  - ../../core/principles/solid.md
search_priority: high
status: published
---

# Nim Language Overview & Ecosystem (2026)

## Introduction / Overview

Nim is a statically typed, compiled systems programming language with Python-like, whitespace-significant, highly readable syntax. Rather than targeting a single machine-code backend directly, the Nim compiler translates Nim source into optimized C, C++, JavaScript, or Objective-C, which a native toolchain (GCC, Clang, MSVC, or a JS engine) then compiles or executes. This gives Nim three properties that are unusual in combination: near-C performance and low-level control (manual memory layout, pointers, inline assembly, zero-cost C library interop), a metaprogramming system (`template`/`macro`) powerful enough to implement DSLs and compile-time code generation, and a memory-safety story that does not require a stop-the-world tracing garbage collector in ordinary programs.

That last point is the single most important fact to get right about modern Nim, and the fact most likely to be wrong in any language model's training data: **as of Nim 2.0 (released August 1, 2023), the default memory management mode is ORC** - a deterministic, ARC-based (Automatic Reference Counting) system augmented with a back-up cycle collector - **not** the traditional deferred reference-counting tracing garbage collector (`--mm:refc`) that was the default throughout the entire Nim 1.x line. Under ARC/ORC, the compiler inserts destructor, copy, and move-hook calls at compile time (RAII-style), so most Nim programs never pause for GC collection and most values behave like C++ value types with move semantics rather than heap-tracked references. Material written before mid-2023 - which is the bulk of Nim content any language model has been trained on - describes the *old* default. Treat any pre-2.0 Nim explanation of memory management, manual `GC_ref`/`GC_unref` calls, or default `ref` behavior as potentially stale.

Nim also has several syntax and semantic properties that are extremely easy for both newcomers and code-generating LLMs to get subtly wrong: a partial case/underscore-insensitive identifier-equality rule, exceptions-by-default paired with an opt-in `{.raises.}` effect system, a `func`/`proc` distinction that tracks side effects at compile time, and the value/move semantics ARC/ORC introduces. This document gives the top two or three of these a brief teaser where relevant; [`common_pitfalls.md`](./common_pitfalls.md) is the canonical, exhaustive reference for these and many more, and should be treated as required reading before generating nontrivial Nim code.

This document is the entry point for all Nim-related knowledge in the Agent Knowledge Base. It orients an agent in the ecosystem - installation, tooling, package management, compiler invocation - before it writes any Nim code. For idiomatic patterns, continue to [`best_practices.md`](./best_practices.md).

In practice, Nim is used across a wide range of application shapes: command-line tools and system utilities (where a single static-ish binary and fast startup matter), game engines and game logic (performance plus low-level control), embedded and resource-constrained targets (the C backend and optional garbage-collector-free configurations reach microcontroller-class hardware), and, increasingly, backend web services (`jester`, `prologue`, `mummy`) where Nim competes on the same ground as Go for I/O-bound network services but with a different memory-management philosophy. `config.nims`/`.nims` files also let Nim itself function as a build- and task-scripting language (NimScript), avoiding a separate shell-scripting or Make dependency for project automation.

**When to use this guidance**: You are generating, reviewing, or reasoning about Nim code; setting up a new Nim project; or deciding whether Nim is the right tool for a systems-level, performance-sensitive, or embeddable-scripting task.

### Version Timeline: Why the 1.x → 2.0 Boundary Matters

| Version | Released | Significance |
|---|---|---|
| 1.4 | December 2020 | ORC introduced as an **opt-in** memory management mode alongside the existing default `refc` GC |
| 1.6 | March 2022 | Long-term-support-style release; `refc` still the default memory management mode |
| **2.0** | **August 1, 2023** | **ORC becomes the default** memory management mode; `strictFuncs` tightened (a store through a `ref`/`ptr` dereference is disallowed in more cases); this is the breaking-change boundary that most pre-2023 Nim material predates |
| 2.2 | October 2024 | Current stable line; incremental refinements, not a memory-management default change |
| 2.2.10 | April 2026 | Latest patch release on the 2.2 stable line at time of writing |

**Practical implication for code generation**: any Nim example, blog post, or cached training memory that does not explicitly account for ARC/ORC - including anything discussing manual `GC_ref`/`GC_unref`, assuming `ref` objects are tracked by a background collector, or omitting `--mm` entirely under the assumption that "the default GC" means `refc` - should be treated as describing Nim 1.x and re-verified against current behavior before being trusted.

## Core Concepts

- **Multi-backend compilation**: `nim c` emits and compiles C (the default), `nim cpp` emits and compiles C++ (needed for C++-only library interop), `nim js` emits JavaScript (browser or Node.js targets), and `nim objc` emits Objective-C for Apple-platform interop. This is why Nim gets mature, battle-tested optimizing back ends and near-universal platform reach for free, rather than maintaining its own native code generator.
- **Value semantics by default under ARC/ORC**: `seq`, `string`, and `object` values are moved or copied deterministically according to compiler-inserted hooks, not silently shared via hidden reference counting the way they were under the old `refc` GC. `ref` types remain the explicit, opt-in mechanism for heap-allocated, shared, potentially cyclic data. See [`best_practices.md`](./best_practices.md#4-memory-management-arcorc-and-value-semantics) for the full model.
- **No mandatory GC pauses**: Because destruction is deterministic and compile-time-scheduled under ARC/ORC, typical Nim programs have no tracing-GC pause to reason about - a property historically associated only with manual-memory languages like C++/Rust, not with a language this high-level and readable.
- **Exceptions are the default error-handling mechanism**: Unlike Rust or Go, Nim raises and catches exceptions by default (`raise`, `try`/`except`/`finally`). An opt-in effect-tracking pragma (`{.raises: [...].}`) lets a routine statically declare, and the compiler verify, exactly which exceptions it may propagate. See [`best_practices.md`](./best_practices.md#5-error-handling).
- **Metaprogramming as a first-class feature**: `template` (hygienic textual/AST substitution) and `macro` (full compile-time AST manipulation) let libraries extend the language itself - this is how Nim implements features other languages need built in (async/await, ORMs with compile-time-checked queries, custom DSLs). Deep coverage lives in [`metaprogramming.md`](./metaprogramming.md).
- **Compile-time execution**: Nim can run substantial parts of a program at compile time (`const` expressions, `static` blocks, and full-blown macros evaluating arbitrary Nim code), a capability closer to Zig's `comptime` than to C++'s more limited `constexpr`.
- **A batteries-included, if smaller, standard library**: `std/asyncdispatch`, `std/json`, `std/strutils`, `std/os`, `std/httpclient`, and `std/unittest` cover most everyday application needs without a third-party dependency, though the library is smaller and less battle-tested in every corner than Python's or Go's.
- **A single compiler binary drives the entire workflow**: there is no separate build-system choice to make (no Make/CMake/Meson equivalent competing with the compiler itself) - `nim c`/`nim r`/`nim check` plus a project's `nim.cfg`/`config.nims` is the whole build pipeline for the overwhelming majority of projects.

## Best Practices

### 1. Install the Toolchain with `choosenim`, Not a Distro Package

**Rationale**: [`choosenim`](https://github.com/nim-lang/choosenim) is Nim's official version manager - the direct analogue of `rustup` for Rust. It installs and switches between Nim compiler versions entirely under the invoking user's own home directory, requiring no `sudo`/Administrator privilege, which makes it the correct default for CI runners and AI-agent sandboxes (see [Autonomous, Least-Privilege, Portable Execution Environments](../../core/devops/autonomous_least_privilege_environments.md)).

```bash
# Linux/macOS - non-interactive, installs to ~/.choosenim (toolchains) and ~/.nimble (bin/pkgs)
curl https://nim-lang.org/choosenim/init.sh -sSf | sh -s -- -y
export PATH="${HOME}/.nimble/bin:${PATH}"
```

`choosenim` places the actual compiler toolchains under `~/.choosenim/toolchains/nim-<version>/`, and exposes a `nim` proxy binary at `~/.nimble/bin/nim` that dispatches to whichever version is currently selected - no system directory is ever touched.

```bash
choosenim update stable      # install/update to the latest stable (2.2.x) release
choosenim <version>          # e.g. choosenim 2.2.10, pin an exact version
choosenim devel              # switch to the development branch
```

| Method | When to prefer it | Root required? |
|---|---|---|
| `choosenim` | Default recommendation: cross-platform, multi-version, non-root | No |
| Official tarball/zip from [nim-lang.org/install.html](https://nim-lang.org/install.html) | Air-gapped installs, or environments where fetching the `choosenim` installer script is blocked | No (extract to a user-owned directory) |
| Distro package (`apt install nim`, `dnf install nim`, Homebrew `brew install nim`) | Quick local experimentation on a personal workstation only | Usually yes for `apt`/`dnf`; no for Homebrew |
| Building from the `nim-lang/Nim` Git repository via `build_all.sh`/`build.bat` | Contributing to the compiler, or needing an unreleased fix | No |

**Why this works well in production**: distro packages frequently lag several minor versions behind upstream and vary in whether they require elevated privilege; `choosenim` behaves identically across Linux, macOS, and Windows, and needs no privilege escalation on any of them.

### 2. Manage Dependencies with Nimble; Know What Atlas Offers

**Rationale**: **Nimble** is Nim's traditional, bundled package manager, shipped with every Nim installation. A project declares its metadata and dependencies in a `<projectname>.nimble` file, and `nimble install`/`build`/`run`/`test` drive the workflow. Nimble resolves packages primarily by name against a central package index (`packages.json`), with a `nimble.lock` file available for reproducible, pinned dependency resolution across machines.

```nim
# orders.nimble
version       = "0.1.0"
author        = "Your Name"
description   = "Order processing service"
license       = "MIT"
srcDir        = "src"
bin           = @["orders"]

requires "nim >= 2.0.0"
requires "results >= 0.5.0"
```

```bash
nimble install results        # fetch and install a dependency
nimble build                  # build the project per the .nimble file
nimble test                   # run the project's configured test task
nimble lock                   # generate/update nimble.lock for reproducible installs
```

**Atlas** ([`nim-lang/atlas`](https://github.com/nim-lang/atlas)) is a newer dependency manager the Nim project has been developing as a more deterministic alternative: it clones dependencies as Git repositories into an isolated workspace/`deps/` directory, resolves version requirements via Git tags and commits rather than a central name index, and manages a project's `nim.cfg` for you. It remains compatible with the existing Nimble package ecosystem and `.nimble` file format rather than replacing it outright. As of 2026, Atlas is actively developed and documented, but Nimble remains the default, more broadly documented, and more widely assumed package manager across third-party tutorials and CI examples.

**Why this works well in production**: default to Nimble for a new project unless a specific need - fully reproducible, workspace-isolated, Git-commit-pinned dependency resolution - points to Atlas, and re-verify Atlas's current maturity against its own repository before committing a project to it, since package-manager status in this ecosystem has been, and continues to be, in flux.

### 3. Choose the Right Compiler Backend and Invocation

**Rationale**: The `nim` binary is a single entry point whose subcommand selects the compilation backend, and `nim r` collapses the usual "compile, then run" loop into one command for fast local iteration.

| Command | Backend | Typical use |
|---|---|---|
| `nim c <file>` | C | Default, most common - native executables on any platform with a C compiler |
| `nim cpp <file>` | C++ | Required when linking against a C++-only library, or using features that need C++ interop |
| `nim js <file>` | JavaScript | Browser or Node.js targets; a large subset of the standard library is JS-compatible |
| `nim objc <file>` | Objective-C | Apple-platform interop (macOS/iOS) with Objective-C frameworks |
| `nim r <file>` | C (default) | Compiles **and immediately runs** - the fast inner-loop command for local development, analogous to `cargo run`/`go run` |
| `nim check <file>` | none (no codegen) | Type-checks only, useful for fast IDE-driven feedback |

```bash
nim c -d:release --out:bin/orders src/orders.nim
nim r src/orders.nim              # compile + run in one step, ideal for iteration
nim cpp --app:lib src/wrapper.nim # produce a C++-linkable shared library
```

**Why this works well in production**: `nim r` during development keeps the feedback loop as fast as an interpreted language while still exercising the real, statically typed compiled path; picking `cpp` vs `c` deliberately (rather than defaulting to `c` everywhere) avoids surprising link errors the first time a C++-only dependency is introduced.

### 4. Follow the Two-Piece Project Convention: `.nimble` at Root, Source in `src/`

**Rationale**: Idiomatic Nim projects place a single `<projectname>.nimble` file at the repository root (package metadata, dependencies, build tasks) and keep actual source under a `src/` directory, mirroring the module path back to the project name. Tests conventionally live in a top-level `tests/` directory, discovered by `nimble test`.

```
orders/
├── orders.nimble
├── nim.cfg              # or config.nims - project-wide compiler flags
├── src/
│   ├── orders.nim
│   └── orders/
│       ├── inventory.nim
│       └── billing.nim
└── tests/
    └── test_inventory.nim
```

**Why this works well in production**: every Nimble/Atlas tool, `nimlangserver`, and `nimble test` itself assumes this layout by default - deviating from it means manually configuring paths that would otherwise just work.

### 5. Adopt the 2026-Consensus Tooling Stack

**Rationale**: A settled, single recommendation per tooling category removes the same category of bikeshedding this document's sibling language sections eliminate for Python/Rust/Go.

| Area | Recommendation | Notes |
|---|---|---|
| Compiler / version manager | `choosenim` | Non-root, cross-platform, multi-version |
| Package manager | `nimble` (bundled) | Default choice; `atlas` is a newer, Git-native alternative - verify current maturity before adopting for a new project |
| Formatter | `nph` | The community-endorsed successor to the now-effectively-superseded `nimpretty`; integrated into `nimlangserver` for format-on-save |
| Linter / static analysis | Compiler warnings/hints (`--styleCheck:error`, `--warningAsError`), `nim check`, and `DrNim` (Z3-backed formal verification) for high-assurance code paths | Nim has no single dominant third-party linter comparable to `golangci-lint`/`clippy`; compiler hints and effect pragmas (`{.raises.}`, `{.noSideEffect.}`) carry more of that load than in other ecosystems |
| Test runner | `std/unittest` for everyday project tests; `testament` for process-isolated, multi-backend, statistics-generating suites | `testament` is what the Nim compiler itself is tested with - see [`testing.md`](./testing.md) |
| Editor / IDE support | `nimlangserver` (LSP server) driven by `nimsuggest` | Covers completion, hover, go-to-definition, references, rename, and formatting (via `nph`) in any LSP-capable editor |

```bash
nimble install nph                 # formatter
nimble install nimlangserver       # LSP server for editor integration
nim c -d:release --styleCheck:error src/orders.nim   # fail the build on style violations
```

**Why this works well in production**: standardizing on this stack in a project's `nim.cfg`/CI configuration gives every contributor - human or agent - identical formatting, identical compiler-hint strictness, and identical editor tooling, the same guarantee `gofmt`/`rustfmt` provide in their respective ecosystems.

## Common Pitfalls & Anti-Patterns

A starter set; see [`common_pitfalls.md`](./common_pitfalls.md) for the exhaustive, canonical catalogue.

### Pitfall: Assuming Nim 1.x Memory-Management Defaults Still Apply

**Problem**: Code or explanations that manually call `GC_ref`/`GC_unref`, or describe Nim's memory model purely in terms of a background tracing collector, reflect Nim 1.x's *previous* default (`refc`), not the ARC/ORC model that has been the default since Nim 2.0 (August 2023).

**Recommended approach**: Default to describing and relying on ARC/ORC's compile-time-inserted destructor/copy/move hooks; verify any memory-management claim against the current [Nim manual](https://nim-lang.org/docs/manual.html) or [`mm.html`](https://nim-lang.org/docs/mm.html) rather than recalled pre-2.0 material. See [`best_practices.md`](./best_practices.md#4-memory-management-arcorc-and-value-semantics).

### Pitfall: Installing Nim via a Stale OS Package Manager, Then Debugging "Missing" 2.0 Features

**Problem**: A distro-packaged `nim` binary that lags upstream by a year or more will lack 2.0+ features (ORC-as-default, updated `strictFuncs`), producing confusing failures that look like documentation errors rather than a version mismatch.

**Recommended approach**: Install via `choosenim` (Best Practice #1) and confirm the active version with `nim --version` before debugging any 2.0-era feature.

### Pitfall: Mixing Nimble and Atlas Project Files Without Understanding the Overlap

**Problem**: Both tools manage a project's dependency configuration; introducing Atlas into a Nimble-managed project without understanding that Atlas also touches `nim.cfg` can produce a project that behaves differently depending on which tool a contributor happens to run.

**Recommended approach**: Pick one dependency manager per project deliberately (Best Practice #2) and document the choice in the project's `README`, rather than letting it be an accident of whichever contributor set it up first.

### Pitfall: Typing Compiler Flags by Hand Instead of Committing Them to `nim.cfg`

**Problem**: Relying on every contributor (or CI job) to remember and retype `--mm:orc --threads:on -d:release` on every invocation guarantees eventual drift - a debug build accidentally shipped, or a memory-management mode silently differing between a developer's machine and CI.

**Recommended approach**: Commit the project's compiler flags to `nim.cfg`/`config.nims` at the repository root (Best Practice #4) so `nim c src/orders.nim` alone reproduces the exact same build everywhere; see [`best_practices.md`](./best_practices.md#8-compilation-flags-for-development-vs-production) for the specific flags to standardize on.

## Testing Strategies

- **`std/unittest`** for everyday project-level tests: `suite`/`test` blocks, `check`/`require` assertions, straightforward `nimble test` integration.
- **`testament`** once a project needs process-isolated, multi-backend (C/C++/JS), or statistically-reported test execution - the same tool used for the Nim compiler's own test suite.
- Test the public (`*`-exported) API surface a module presents, mirroring how real consumers call it, rather than reaching into private internals.
- See [`testing.md`](./testing.md) for fixtures, mocking patterns, and CI wiring for both tools.

## Performance, Security & Scalability Considerations

- **No mandatory GC pause**: ARC/ORC's deterministic destruction avoids the latency-spike class of bug that tracing-GC languages must otherwise account for under load - a meaningful advantage for latency-sensitive services.
- **`-d:release` keeps runtime safety checks (bounds, overflow, nil) enabled while optimizing**; only `-d:danger` strips them entirely for maximum throughput - treat that trade-off as a reviewed project decision, not a default. See [`best_practices.md`](./best_practices.md#8-compilation-flags-for-development-vs-production).
- **Supply-chain hygiene**: pin dependencies via `nimble.lock` (or Atlas's Git-commit pinning) and review third-party `.nimble` package sources before adopting them - the same discipline recommended generally in [Autonomous, Least-Privilege, Portable Execution Environments](../../core/devops/autonomous_least_privilege_environments.md).
- **Multi-backend compilation is a security-relevant choice, not just a convenience**: code compiled to JavaScript loses the memory-safety properties the C/C++ backends provide via ARC/ORC and instead inherits the JS engine's own runtime model - do not assume identical safety guarantees across backends.

## Edge Cases & Advanced Usage

- **Cross-compilation**: `nim c --os:linux --cpu:arm64` (and similar `--os`/`--cpu` combinations) cross-compiles by invoking an appropriately configured C cross-compiler toolchain - the Nim compiler itself does not need to run on the target platform.
- **`--threads:on` interaction with ARC/ORC**: enabling threads changes how the memory-management hooks synchronize; see [`concurrency.md`](./concurrency.md) for the full implications before mixing manual threading with shared `ref` data.
- **JS backend standard library gaps**: not every stdlib module compiles under `nim js` (anything requiring OS-level file/process access, for instance); verify a dependency's JS-backend support before committing to it for a browser target.
- **Migrating a pre-2.0 codebase to 2.0+**: expect to revisit code that manually managed reference counts or relied on the looser pre-2.0 `strictFuncs` definition, which the 2.0 release tightened.
- **Selecting an explicit memory-management mode for compatibility**: `--mm:arc` (no cycle collector, smaller/faster but leaks true reference cycles and is incompatible with the stdlib async dispatcher's cyclic data structures) and `--mm:refc` (the pre-2.0 default, occasionally still required by an unmaintained dependency assuming its semantics) both remain available for cases where the ORC default is not the right fit - see [`best_practices.md`](./best_practices.md#8-compilation-flags-for-development-vs-production).
- **Standalone/embedded targets**: `--os:standalone` combined with a minimal or absent C runtime is used for microcontroller and kernel-level Nim, at the cost of losing most of the standard library's OS-dependent modules.

## When *Not* to Use / Alternatives

| Dimension | Nim | Rust | Go | C++ |
|---|---|---|---|---|
| Learning curve / syntax familiarity | Low (Python-like) | High (ownership/borrowing) | Low | High |
| Memory safety guarantees | Deterministic (ARC/ORC), not compiler-proven against all misuse | Strongest (compile-time borrow checker) | Safe (tracing GC) | Weakest (manual) |
| Compile-time metaprogramming power | Very high (`macro`, full AST access) | High but more ceremony (proc macros) | Low (no generative macros) | High (templates, more arcane) |
| Ecosystem/library maturity | Smaller, growing | Large and fast-growing | Very large | Enormous, legacy-heavy |
| Team hiring pool | Small | Growing | Large | Large |

**Choose Nim** when you want C-level performance and control, or a single codebase that must also target JavaScript/the browser, with a syntax and productivity profile closer to Python than to Rust or C++ - and when a smaller hiring pool and ecosystem are acceptable trade-offs.

**Choose Rust** (see [`../rust/README.md`](../rust/README.md)) when compile-time-enforced memory and thread safety is a hard requirement and the team can absorb a steeper learning curve.

**Choose Go** (see [`../go/README.md`](../go/README.md)) when team velocity, a large existing ecosystem, and a simple concurrency model matter more than Nim's metaprogramming power or multi-backend compilation.

## Related Documentation

- [Nim Best Practices](./best_practices.md) - idiomatic naming, module/export system, `proc`/`func`/`template`/`macro`/`iterator`/`method` selection, ARC/ORC value semantics, error handling, and compilation flags.
- [Nim Common Pitfalls & Anti-Patterns](./common_pitfalls.md) - the exhaustive catalogue of Nim's sharpest edges; consult before trusting generated Nim code that looks "almost right."
- [Nim Metaprogramming](./metaprogramming.md) - `template` and `macro` in depth.
- [Nim Concurrency](./concurrency.md) - threads, `--threads:on`, channels, async/await, and ARC/ORC implications for concurrent code.
- [Nim Testing](./testing.md) - `unittest` vs `testament` in depth, fixtures, mocking, CI integration.
- [Nim FFI/Interop](./interop_ffi.md) - calling C/C++ from Nim and vice versa, `{.importc.}`/`{.exportc.}`.
- [Rust Language Overview](../rust/README.md)
- [Go Language Overview](../go/README.md)
- [SOLID Principles](../../core/principles/solid.md)
- [Autonomous, Least-Privilege, Portable Execution Environments](../../core/devops/autonomous_least_privilege_environments.md)

## Glossary

- **ARC**: Automatic Reference Counting - Nim's deterministic memory management strategy where destructor/copy/move calls are inserted at compile time; does not collect reference cycles on its own.
- **ORC**: ARC plus a cycle collector (trial-deletion based); the **default memory management mode since Nim 2.0**.
- **`refc`**: The traditional deferred reference-counting tracing garbage collector that was Nim's default throughout the 1.x line, selectable explicitly today via `--mm:refc`.
- **Backend**: The target Nim compiles to - C, C++, JavaScript, or Objective-C - selected via the `nim c`/`cpp`/`js`/`objc` subcommand.
- **`choosenim`**: Nim's official, non-root, cross-platform compiler version manager.
- **Nimble**: Nim's bundled, name-index-based package manager and its `.nimble` project file format.
- **Atlas**: A newer, Git-native dependency manager for Nim, compatible with the Nimble file format.
- **`nimsuggest`**: The compiler-integrated suggestion/analysis engine underlying Nim's editor tooling; `nimlangserver` exposes it over the Language Server Protocol.

---

**Maintenance note**: When updating this document, also update `last_updated` and re-verify the current stable Nim version and any nimble/atlas maturity claims against the [Nim blog](https://nim-lang.org/blog.html) and the `nim-lang/atlas` repository, since package-manager status in this ecosystem has changed more than once.