Who Its For

Who This Is For (and Who It Isn't)

The honest fit, not the marketing one.

Squarely for

Backend/network services written or maintained by an AI coding agent, with no human reviewing every line before it runs. This is the one problem nothing else on the market is built for from the grammar up:

• An LL(1) grammar exported to GBNF lets a sampler force every token an agent emits to stay syntactically valid.
• --format=json gives a self-repair loop a structured proof obligation instead of a paragraph to guess at.
• sandbox is a real OS process and a language primitive, not a bolted-on Docker wrapper around output nobody trusts.
• There is no mutex in the language, so an agent literally cannot generate a lock-ordering deadlock — and if generated code still manages a recv/join deadlock (still possible; async messages don't make that vanish), the runtime traps it with a clear diagnostic instead of silently hanging the process.

If you're building an autonomous coding agent, or letting one operate against production, this is the concrete gap Nirdosha targets. See LLM Integration for the full mechanism.

Compliance-shaped CRUD systems — trade finance, KYC/onboarding, anything where "who is allowed to call this" is part of the spec, not an afterthought. requires(role: "admin") / requires(claim: "department", "cardiology") are type-checked at the call site, not if user.role == "admin" sprinkled through handlers — the UI engine derives the login/role gate automatically from the same annotation.

Deterministic simulations and audits, where "run it twice, get the same trace" matters. rand_seed resets a from-scratch RNG with no OS entropy, so a run is byte-for-byte reproducible from a seed.

Not (yet) for

• OS/kernel or embedded work — no no_std, no freestanding target; the runtime assumes a real OS underneath it for threads and processes.
• General frontend/UI work — emit-ui/serve generate CRUD + dashboard screens from struct/fn naming, not a general application-UI framework. See The UI Engine for exactly what it is and isn't.
• Anything where you need the crate ecosystem, hiring pool, or decade of production hardening Rust/Go already have. Nirdosha is a young public research prototype; picking it over Rust today is a research bet, not an engineering one — see Honest Scope & Roadmap.

Why this framing, specifically

This page exists because "who is this for" is usually answered with aspiration, not constraint. Nirdosha's actual target user is unusual enough that most existing language-comparison heuristics don't apply: a human picking a language optimizes for ecosystem, hiring, and their own learning curve. An agent picking (or being pointed at) a language for unsupervised backend generation optimizes for something almost no other language ships as a first-class artifact: a formally decidable grammar it can be mechanically constrained to, and a feedback channel from failure that's structured data instead of prose. That's the actual axis this project competes on — see Nirdosha vs. Rust, Go, Mojo for the direct comparison.