DUUMBI vs Traditional Compilers
Traditional compilers (GCC, Clang, rustc, Go) convert text source code through multiple intermediate representations to machine code. DUUMBI skips text entirely — the source is a typed graph, and compilation is a graph traversal.
| Feature | DUUMBI | Traditional |
|---|---|---|
| Source format | JSON-LD semantic graph | Text (C, Rust, Go, etc.) |
| Parsing | JSON deserialization (no grammar needed) | Lexer + parser + AST construction |
| IR | petgraph StableGraph (graph is the IR) | Custom AST → HIR → MIR → LLVM IR |
| AI integration | First-class (graph mutation pipeline) | External (AI generates text, compiler has no AI) |
| Backend | Cranelift (optimized for compile speed) | LLVM (optimized for runtime speed) or custom |
| Syntax errors | Impossible by construction | Common source of frustration |
| Type system | Structural types on graph nodes | Language-specific (nominal, structural, etc.) |
| Ownership | Graph-level validation (Rust-inspired) | Language-specific (Rust has it, C does not) |
| Ecosystem | New, growing | Mature, vast libraries |
| Compile speed | Fast (Cranelift, no parsing overhead) | Varies (LLVM is slow, GCC moderate) |
No parser, no syntax
A traditional compiler's frontend is dominated by parsing: lexing text into tokens, parsing tokens into an AST, then lowering the AST through multiple IRs. For gcc, this chain is roughly: text → tokens → AST → GIMPLE → RTL → machine code. For rustc: text → tokens → AST → HIR → MIR → LLVM IR → machine code.
DUUMBI's pipeline is: JSON-LD → serde_json → petgraph::StableGraph → Cranelift IR → machine code. There's no grammar, no lexer, no parser. The graph is the IR. This is only possible because the source format is structured data, not text.
AI as a first-class citizen
Traditional compilers have no concept of AI. If you want AI to generate C code, the AI produces text, and the compiler's parser might reject it. The feedback loop is: generate text → compile → parse error → fix text → try again.
In DUUMBI, AI generates graph patches — typed operations like "add function", "add op to block", "set edge". These patches are validated against the graph schema before being applied. If validation fails, the error feedback is structural ("node X has wrong type for field Y"), not syntactic ("unexpected token on line 47").
Cranelift vs LLVM
Most production compilers use LLVM for code generation. LLVM produces highly optimized machine code but is slow to compile. DUUMBI uses Cranelift, the code generator from the Wasmtime WebAssembly runtime.
Cranelift prioritizes compile speed over peak runtime performance. For DUUMBI's use case — where programs are frequently regenerated by AI and the edit-compile-run loop should be fast — this is the right tradeoff.
When to use DUUMBI
- You want AI to generate and modify programs without text-based errors
- You value the graph representation — visual, structural, queryable
- You want built-in ownership/borrowing without learning Rust syntax
- You're building systems where AI is the primary "programmer"
When to use a traditional compiler
- You need maximum runtime performance (LLVM optimization passes)
- You're working in an established ecosystem with mature libraries
- You prefer writing code as text (which most humans do today)
- You need broad platform support and battle-tested toolchains
A glimpse of the future
DUUMBI doesn't aim to replace GCC or rustc. It explores what compilation looks like when AI is the primary producer of code. When programs are meaning — typed, validated, structural — instead of syntax.