NanoCNanoC compared
Where NanoC sits among systems languages. It is a frontend for C, not a replacement for it.
| What | C | Zig | Rust | Nim | NanoC |
|---|---|---|---|---|---|
| Compiles to | machine code | machine code | machine code | C, C++ or JS | plain C11 or C++17 |
| Block syntax | braces | braces | braces | indentation | indentation |
| Translate-time code | preprocessor text | comptime | macro_rules!, proc macros | templates, macros | macros and @tt programs, rewritten until stable |
| Build-time code | Make, CMake… | build.zig | build.rs | nimscript | External build tools |
| Existing C | native | @cImport | FFI / bindgen | importc | unmarked C is kept as-is |
| Runtime / deps | none | none | std, crates | GC or ARC | none: it is just C |
| Inspect the output | n/a | assembly / LLVM IR | MIR / assembly | generated C | generated C, with #line back to your source |
Qualitative and simplified: each language does much more than this table shows. NanoC's pitch is narrow: keep C's output and ecosystem, lose the ceremony.
When NanoC fits
- You already ship C and want less boilerplate without giving up your toolchain.
- You want code generation that is a language feature (
@m,@tt) instead of a Makefile trick. - You need readable C output for audits, certification or portability to odd compilers.
When it does not
- You want memory safety checked by the language: use Rust, or Zig for a middle ground.
- You need a large standard library or package ecosystem: NanoC deliberately has none.
- You need a stable language today: NanoC is alpha.