I built Arden to optimize one thing: feedback loop speed

Question

Most language posts sell syntax.
I care more about this: edit code -> get signal fast.

Arden is a native systems language built around that loop:

• native output via LLVM
• strict static checks (types, borrowing, effects)
• one CLI that handles build/run/check/fmt/lint/fix/test/bench/profile/bindgen/lsp

Why this is different

I didn’t want a “compiler demo” that only parses files.

Arden has a full project pipeline with:

• project graph rewrite
• import + semantic validation
• object codegen + linker integration
• cache-aware rebuild path
• phase timings (arden build --timings) so you can see where time goes

Example loop on Windows

From a tiny project run:

• cargo build --release: ~2.03s
• arden build --timings: ~0.123s total

Example loop on Linux

On my Linux run with the same tiny shape:

• cargo build --release: ~0.13s
• arden build --timings: ~0.033s total

These are machine-specific numbers, not universal claims.
The point is the workflow: Arden is designed to make the compile-check-fix loop short and inspectable.

Bigger benchmark snapshot (repo harness)

The repo includes a reproducible harness comparing Arden / Rust / Go on shared workloads.

Latest hot compile snapshot (compile_project_starter_graph) on my benchmark machine:

• Arden: 0.0075s mean
• Rust: 0.1636s mean
• Go: 0.0437s mean

Again: benchmark context matters. I publish commands and outputs so people can rerun and challenge numbers.

Language model in one sentence

Arden tries to combine:

• native performance path
• strict correctness boundaries
• practical day-to-day tooling in one place

If that sounds interesting, I’d love feedback from people who care about compilers, DX, and build systems.

Repo: https://github.com/TheRemyyy/arden-lang
Docs: https://www.arden-lang.dev/docs/overview