DEV Community

TheRemyyy
TheRemyyy

Posted on

I built Arden to optimize one thing: feedback loop speed

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

Top comments (0)