# Lux Language Comparison & Project Roadmap

*Comprehensive comparison against major languages and stress test roadmap*

---

## Part 1: What We've Built

### Production-Scale Examples

| Project | Location | Complexity | Features Exercised |
|---------|----------|------------|-------------------|
| **Task Manager API** | `examples/showcase/task_manager.lux` | Advanced | All 3 killer features: effects, behavioral types, schema evolution |
| **REST API Server** | `projects/rest-api/` | Advanced | HttpServer effect, routing, JSON, CRUD operations |
| **Mini Interpreter** | `projects/mini-interpreter/` | Advanced | AST, recursive evaluation, environments, error handling |
| **JSON Parser** | `projects/json-parser/` | Advanced | Recursive descent, complex ADTs, Result type |
| **Markdown Converter** | `projects/markdown-converter/` | Moderate | String parsing, AST transformation, HTML generation |
| **Todo App** | `projects/todo-app/` | Moderate | ADT data modeling, list operations, state management |
| **Guessing Game** | `projects/guessing-game/` | Moderate | State machines, Console I/O, game loops |
| **Interactive Playground** | `website/src/main.lux` | Advanced | Full web app, state management, code execution |

### Standard Examples (70+ files)

| Category | Count | Key Examples |
|----------|-------|--------------|
| Basic Language | 15+ | hello, factorial, fizzbuzz, primes |
| Data Structures | 10+ | datatypes, statemachine, traits, generics |
| Functional Patterns | 8+ | pipelines, tailcall, higher_order |
| Effects | 10+ | effects, handlers, random, file_io, http |
| Behavioral Types | 5+ | behavioral_types, pure functions |
| Schema Evolution | 2 | schema_evolution, versioning |
| Modules | 6 | imports, selective, wildcard |
| Web/Browser | 4 | counter, counter_html, playground |

### Benchmarks

| Benchmark | Purpose | Comparison Languages |
|-----------|---------|---------------------|
| Fibonacci | Function call overhead | Lux, C, Rust, JS, Zig |
| Fibonacci TCO | Tail call optimization | All |
| Ackermann | Deep recursion | All |
| Quicksort | Algorithm + list ops | All |
| Binary Trees | Memory allocation | All |
| N-body | Numeric computation | All |
| List Operations | Map/filter/fold | All |
| Closures | Closure overhead | All |
| Pattern Matching | ADT dispatch | All |
| Primes | Integer math | All |

---

## Part 2: What We Should Build Next

### Tier 1: Core Language Stress Tests (Build First)

These validate fundamental language capabilities:

| Project | Primary Stress | Secondary Stress | Success Criteria |
|---------|---------------|------------------|------------------|
| **Property-Based Testing Framework** | Generators, shrinking, behavioral types | Recursion, ADTs | Can test Lux stdlib with it |
| **Concurrent Task Queue** | Effects + state + coordination | Pattern matching, handlers | 10k tasks without leak |
| **Database Query Builder** | Schema evolution, effects, type safety | Generics, composition | Type-safe SQL generation |
| **Regex Engine** | Backtracking, complex ADTs, performance | Recursive parsing | Match `.*` in < 1s |
| **LRU Cache** | State effects, data structures | Behavioral types (idempotent) | O(1) get/put |
| **Diff Algorithm** | List algorithms, recursion | Optimization | Diff 10k lines in < 100ms |

### Tier 2: Backend Services (Production Viability)

| Project | Competes With | Key Challenges | Lux Advantage |
|---------|---------------|----------------|---------------|
| **GraphQL Server** | Node.js (Apollo), Elixir (Absinthe) | Schema types, resolvers, N+1 | Effects track data fetching |
| **Job Queue System** | Sidekiq (Ruby), Celery (Python), Bull (Node) | Reliability, retries, idempotency | Behavioral types prove idempotent! |
| **Rate Limiter** | Redis, custom Go services | Time effects, sliding windows | Effect-based time mocking |
| **Auth Service** | Every language | JWT, sessions, security | Effect isolation for testing |
| **Message Broker** | RabbitMQ, Kafka clients | Persistence, ordering | Schema evolution for messages |
| **API Gateway** | Kong, custom Go | Routing, middleware | Effect composition |

### Tier 3: CLI Tools (Developer Experience)

| Project | Comparable To | Tests | Why Important |
|---------|---------------|-------|---------------|
| **Static Site Generator** | Hugo (Go), Eleventy (JS) | File I/O, templates, watching | Common real-world tool |
| **Code Formatter** | Prettier, Black, rustfmt | Parsing, AST transform | Self-hosting capability |
| **Linter** | ESLint, Clippy, mypy | AST analysis, error reporting | Dogfooding the language |
| **Test Runner** | Jest, pytest, cargo test | Discovery, execution, reporting | Needed for ecosystem |
| **Documentation Generator** | rustdoc, JSDoc | Parsing, templates, output | Ecosystem tooling |
| **REPL Improvements** | IPython, iex | Autocomplete, history, multi-line | Developer happiness |

### Tier 4: Data Processing (Schema Evolution Showcase)

| Project | Tests | Real-World Use Case |
|---------|-------|---------------------|
| **CSV Parser with Schema Inference** | Streaming, type inference | Data import pipelines |
| **Log Aggregator** | Parsing, filtering, effects | Observability |
| **ETL Pipeline Framework** | Transformations, versioned schemas | Data engineering |
| **Report Generator** | Templates, data binding | Business intelligence |
| **Config File Manager** | Multiple formats, validation | DevOps tooling |
| **Database Migration Tool** | Schema diff, SQL generation | Core schema evolution use case |

### Tier 5: Interactive Applications

| Project | Target | Validates |
|---------|--------|-----------|
| **Terminal UI (TUI)** | Native | Event loops, rendering, state |
| **Chat Application** | Web + Server | Real-time, WebSockets, effects |
| **Kanban Board** | Web | Drag-drop, complex state, persistence |
| **Spreadsheet** | Web | Cell dependencies, formulas, reactivity |
| **Code Editor Component** | Web | Syntax highlighting, keyboard handling |
| **Game (Snake/Tetris)** | Web + Native | Game loops, state machines, rendering |

### Tier 6: Prove Language Maturity

| Project | Proves | Precedent |
|---------|--------|-----------|
| **Self-Hosted Lux Compiler** | Language completeness | Rust, Go, Zig did this |
| **LSP Server in Lux** | Complex stateful service | Currently in Rust |
| **Lux Package Registry** | Web service + database | cargo, npm |
| **HTTP Framework** | Ecosystem foundation | Express, Phoenix, Actix |
| **ORM/Database Layer** | Schema evolution in practice | Diesel, Prisma |

---

## Part 3: Language Love/Hate Analysis

### Rust

**What People Love:**
- Memory safety without garbage collection
- "If it compiles, it works" confidence
- Fearless concurrency (no data races)
- Cargo (best package manager in existence)
- Pattern matching and ADTs
- Helpful compiler error messages
- Zero-cost abstractions
- Strong community and documentation

**What People Hate:**
- Steep learning curve (ownership, lifetimes, borrowing)
- Fighting the borrow checker
- Long compile times
- Verbose for simple tasks
- Async complexity (Pin, different runtimes, colored functions)
- Over-engineering tendency
- Macro system complexity
- Not great for rapid prototyping

**Lux vs Rust:**

| Aspect | Rust | Lux | Analysis |
|--------|------|-----|----------|
| Memory safety | Ownership | Reference counting | Rust: more control, Lux: simpler |
| Learning curve | 6+ months | 1-2 weeks | Lux wins |
| Compile times | 30s-10min | <5s | Lux wins |
| Side effect tracking | None | First-class | Lux wins |
| Concurrency model | Fearless (ownership) | Effects | Different approaches |
| Performance | Maximum | Good (C backend) | Rust wins |
| Tooling | Excellent | Good | Rust wins |
| Pattern matching | Excellent | Excellent | Tie |
| Error handling | Result + ? | Result + effects | Both good |
| Ecosystem | Large, growing | Small | Rust wins |

**Lux pitch to Rust users:** "Get 80% of Rust's safety with 20% of the complexity. No lifetime annotations. Effects make testing trivial without mock frameworks."

---

### Go

**What People Love:**
- Simple (50-page spec)
- Fast compilation (seconds)
- Great concurrency (goroutines, channels)
- Excellent standard library
- Single binary deployment
- Good tooling (gofmt, go vet)
- Easy to hire for
- Readable by anyone

**What People Hate:**
- No generics (until 1.18, still limited)
- Verbose error handling (`if err != nil` everywhere)
- No sum types/ADTs
- Limited type system expressiveness
- No immutability guarantees
- Null pointer panics
- Interface{} type erasure
- Repetitive boilerplate

**Lux vs Go:**

| Aspect | Go | Lux | Analysis |
|--------|-----|-----|----------|
| Simplicity | Very simple | Moderate | Go wins |
| Type system | Basic | Advanced (HM, ADTs) | Lux wins |
| Error handling | `if err != nil` | Result + effects | Lux wins |
| Generics | Limited | Full | Lux wins |
| Concurrency | Goroutines | Effects | Go more mature |
| Compile speed | Fast | Fast | Tie |
| Deployment | Single binary | C/native | Both good |
| Testing | Good | Effect swapping | Lux wins |
| Ecosystem | Large | Small | Go wins |
| Null safety | No | Yes (Option) | Lux wins |

**Lux pitch to Go users:** "Keep the simplicity and fast compilation. Add real generics, ADTs, and no more `if err != nil`. Function signatures tell you exactly what they can do."

---

### Elixir/Erlang

**What People Love:**
- Fault tolerance ("let it crash" + supervisors)
- Concurrency (lightweight processes, actors)
- Hot code reloading
- Pattern matching everywhere
- Immutability by default
- Phoenix/LiveView for web
- Battle-tested (WhatsApp, Discord)
- OTP's 30+ years of reliability

**What People Hate:**
- Dynamic typing (runtime errors)
- Performance for CPU-bound tasks
- Learning curve (OTP concepts)
- Debugging distributed systems
- String handling complexity
- Deployment (releases, nodes)
- Small job market

**Lux vs Elixir:**

| Aspect | Elixir | Lux | Analysis |
|--------|--------|-----|----------|
| Fault tolerance | Supervisors | Not yet | Elixir wins |
| Concurrency | Actors/BEAM | Effects | Elixir more mature |
| Type system | Dynamic | Static (HM) | Lux wins |
| Pattern matching | Excellent | Excellent | Tie |
| Hot reloading | Built-in | Watch mode | Elixir wins |
| Performance | Good (BEAM) | Good (native) | Different tradeoffs |
| Web development | Phoenix (excellent) | Basic HTTP | Elixir wins |
| Testing | Good | Effect handlers | Lux conceptually cleaner |
| Functional style | Yes | Yes | Tie |
| Community | Enthusiastic | New | Elixir wins |

**Lux pitch to Elixir users:** "Same functional style and pattern matching, but with static types that catch errors at compile time. Effects provide similar isolation without learning OTP."

---

### JavaScript/TypeScript

**What People Love:**
- Ubiquitous (browser + server + mobile)
- Huge ecosystem (npm)
- Easy to start
- Flexible (sometimes too flexible)
- TypeScript adds safety
- Async/await for IO
- JSON native
- Great tooling (VS Code, ESLint, Prettier)

**What People Hate:**
- Type coercion madness (`[] + {} === "[object Object]"`)
- `null` AND `undefined`
- `this` binding confusion
- Runtime errors despite TypeScript
- Bundle size concerns
- Security vulnerabilities in npm
- Framework churn
- "any" escape hatch defeats type safety

**Lux vs TypeScript:**

| Aspect | TypeScript | Lux | Analysis |
|--------|------------|-----|----------|
| Type safety | Good (with holes) | Strong (no any) | Lux wins |
| Null handling | Still messy | Option type | Lux wins |
| Side effect tracking | None | First-class | Lux wins |
| Ecosystem | Massive | Small | TypeScript wins |
| Browser support | Native | JS compilation | TypeScript easier |
| Learning curve | Easy | Moderate | TypeScript wins |
| Async model | async/await | Effects | Different |
| Tooling | Excellent | Good | TypeScript wins |
| Refactoring confidence | Medium | High | Lux wins |
| Type inference | Good | Excellent (HM) | Lux wins |

**Lux pitch to TS users:** "Real type safety without 'any' escape hatches. No null pointer exceptions. Know exactly what every function can do. Compiles to clean JS."

---

### Python

**What People Love:**
- Easy to learn and read
- Massive ecosystem (data science, ML, web)
- Rapid prototyping
- Interactive development (REPL, Jupyter)
- Batteries included
- Great for scripting
- AI/ML dominance
- "Executable pseudocode"

**What People Hate:**
- Slow performance (100x slower than C)
- GIL (no true parallelism)
- Runtime type errors
- Dependency management chaos (pip, venv, poetry, conda...)
- Significant whitespace (controversial)
- Python 2 vs 3 (mostly resolved)
- Type hints are optional and often ignored
- No compile-time checks

**Lux vs Python:**

| Aspect | Python | Lux | Analysis |
|--------|--------|-----|----------|
| Learning curve | Very easy | Moderate | Python wins |
| Performance | Slow | Fast (C backend) | Lux wins (10-100x) |
| Type safety | Optional (mypy) | Required | Lux wins |
| REPL | Excellent | Good | Python wins |
| Data science | Dominant | None | Python wins |
| Side effects | Everywhere | Tracked | Lux wins |
| Ecosystem | Massive | Small | Python wins |
| Rapid prototyping | Excellent | Good | Python wins |
| Refactoring | Scary | Confident | Lux wins |
| Runtime errors | Common | Rare | Lux wins |

**Lux pitch to Python users:** "Same rapid development feel with REPL, but catch errors at compile time instead of production. 10-100x faster performance. Effects make testing easy."

---

### Elm

**What People Love:**
- Zero runtime exceptions (truly)
- Best error messages in any language
- Enforced architecture (TEA)
- Refactoring with total confidence
- Small, focused language
- No null
- Immutability everywhere
- Compiler as assistant

**What People Hate:**
- No side effects (ports required for JS interop)
- Limited to web frontend
- Small ecosystem
- Single maintainer, slow evolution
- Can't call JS directly
- No custom operators
- Treats everyone as beginners

**Lux vs Elm:**

| Aspect | Elm | Lux | Analysis |
|--------|-----|-----|----------|
| Runtime exceptions | Zero | Near-zero | Elm slightly better |
| Error messages | Legendary | Good | Elm wins |
| Architecture | Enforced TEA | TEA available | Elm more opinionated |
| Side effects | Ports only | First-class handlers | Lux wins |
| JS interop | Awkward | Good | Lux wins |
| Target platforms | Browser only | Native + JS | Lux wins |
| Effect handling | Cmd/Sub | Algebraic effects | Lux more powerful |
| Learning curve | Easy | Moderate | Elm wins |
| Ecosystem | Small | Small | Tie |
| Flexibility | Low | High | Lux wins |

**Lux pitch to Elm users:** "Same type safety and FP principles, but with algebraic effects that make side effects elegant instead of awkward ports. TEA for web, native for servers."

---

### Gleam

**What People Love:**
- Type-safe Erlang (best of both worlds)
- "If it compiles, it's good"
- Simple, focused language
- Great error messages
- BEAM + JS targets
- Erlang/Elixir interop
- Growing enthusiastic community

**What People Hate:**
- Young ecosystem
- Limited features vs Elixir
- No effect tracking
- No macros
- Small job market
- Documentation still maturing

**Lux vs Gleam:**

| Aspect | Gleam | Lux | Analysis |
|--------|-------|-----|----------|
| Type safety | Excellent | Excellent | Tie |
| Effect tracking | None | First-class | Lux wins |
| Error messages | Great | Good | Gleam slightly better |
| BEAM runtime | Yes | No | Gleam for distributed |
| JS compilation | Yes | Yes | Tie |
| Native compilation | No | Yes (C) | Lux wins |
| Pattern matching | Good | Good | Tie |
| Behavioral types | No | Yes | Lux wins |
| Community size | Growing | Smaller | Gleam wins |
| Maturity | Young | Younger | Gleam slightly ahead |

**Lux pitch to Gleam users:** "Same ML-family safety, but with algebraic effects Gleam explicitly rejected. Behavioral types for compile-time guarantees. Native compilation for servers."

---

### Zig

**What People Love:**
- Simple, readable C replacement
- No hidden control flow
- Compile-time execution (comptime)
- No GC, manual memory (with safety)
- Good error handling
- Cross-compilation
- Excellent C interop
- Growing systems programming niche

**What People Hate:**
- Young, still evolving (pre-1.0)
- Small ecosystem
- Manual memory management
- No RAII/destructors
- Limited abstractions
- Build system learning curve
- Documentation gaps

**Lux vs Zig:**

| Aspect | Zig | Lux | Analysis |
|--------|-----|-----|----------|
| Abstraction level | Low | High | Different targets |
| Memory management | Manual | Automatic (RC) | Different tradeoffs |
| Performance | Maximum | Good | Zig wins |
| Safety | Explicit | Type system | Lux more automatic |
| C interop | Excellent | Via C backend | Zig wins |
| Compile-time | comptime | Limited | Zig wins |
| Learning curve | Moderate | Moderate | Tie |
| Use case | Systems | Applications | Different |
| Ecosystem | Small | Small | Tie |

**Lux pitch to Zig users:** "Different tools for different jobs. Use Zig for systems programming, Lux for application logic where you want effect tracking and behavioral guarantees without manual memory."

---

### C/C++

**What People Love:**
- Ultimate performance
- Direct hardware access
- Available everywhere
- Huge existing codebase
- Full control
- Mature tooling

**What People Hate:**
- Memory unsafety (buffer overflows, use-after-free, dangling pointers)
- Undefined behavior everywhere
- Header file complexity (C++)
- Build system nightmare (CMake, Make, etc.)
- Manual everything
- Security vulnerabilities
- C++: incredibly complex (1000+ page spec)
- Segfaults

**Lux vs C/C++:**

| Aspect | C/C++ | Lux | Analysis |
|--------|-------|-----|----------|
| Performance | Maximum | Good | C/C++ wins |
| Safety | None | Strong | Lux wins |
| Abstraction | Low/Medium | High | Different targets |
| Memory management | Manual | Automatic | Lux easier |
| Side effect tracking | None | First-class | Lux wins |
| Ecosystem | Massive | Small | C/C++ wins |
| Build system | Complex | Simple | Lux wins |
| Learning curve | Steep | Moderate | Lux wins |

**Lux pitch to C/C++ users:** "Lux compiles to C, keeping performance while adding memory safety and effect tracking. Keep low-level access when needed, get safety for application logic."

---

### Java

**What People Love:**
- Mature, stable (25+ years)
- JVM performance (JIT optimization)
- Huge ecosystem
- Great IDE support
- Enterprise adoption
- Strong typing
- Good tooling
- Predictable

**What People Hate:**
- Verbose (`AbstractSingletonProxyFactoryBean`)
- Slow startup (seconds to minutes)
- Null pointer exceptions everywhere
- Checked exceptions (controversial)
- Boilerplate (getters, setters, constructors)
- XML configuration era (Spring)
- Memory hungry
- "Legacy" perception

**Lux vs Java:**

| Aspect | Java | Lux | Analysis |
|--------|------|-----|----------|
| Verbosity | High | Low | Lux wins |
| Type system | Nominal | Structural + HM | Lux wins |
| Null safety | NPE common | Option type | Lux wins |
| Side effects | Everywhere | Tracked | Lux wins |
| Ecosystem | Massive | Small | Java wins |
| Performance | Good (JIT) | Good (native) | Tie |
| Startup time | Slow | Fast | Lux wins |
| Enterprise adoption | Dominant | None | Java wins |
| IDE support | Excellent | Good | Java wins |
| Testing | Mock frameworks | Effect handlers | Lux cleaner |

**Lux pitch to Java users:** "Same type safety, 1/10th the boilerplate. No null pointers. Functions are first-class. Effects replace dependency injection frameworks for clean testing."

---

### Haskell

**What People Love:**
- Pure functional programming
- Powerful type system
- Pattern matching
- Type inference
- Lazy evaluation (sometimes)
- Algebraic data types
- Category theory integration
- Correctness guarantees

**What People Hate:**
- Steep learning curve
- Monad transformers complexity
- Lazy evaluation (often)
- String types mess (String, Text, ByteString)
- Error messages historically poor
- Build tool fragmentation (Cabal, Stack)
- "Academically arrogant" perception
- Simple things feel hard

**Lux vs Haskell:**

| Aspect | Haskell | Lux | Analysis |
|--------|---------|-----|----------|
| Type system | Very powerful | Powerful | Haskell more expressive |
| Effect handling | Monad transformers | Algebraic effects | Lux simpler |
| Learning curve | Very steep | Moderate | Lux wins |
| Purity | Enforced via IO | Tracked via effects | Both good |
| Pattern matching | Excellent | Excellent | Tie |
| Error messages | Improving | Good | Lux slightly better |
| Ecosystem | Medium | Small | Haskell wins |
| Practical focus | Mixed | Yes | Lux wins |
| Performance | Good | Good | Tie |
| Metaprogramming | Template Haskell | Limited | Haskell wins |

**Lux pitch to Haskell users:** "Same FP principles without monad transformer stacks. Effects are simpler than `StateT IO`. Keep the type safety, lose the complexity."

---

## Part 4: Lux's Unique Position

### What Only Lux Has

| Feature | Lux | Koka | Elm | Rust | Go | Haskell | Elixir |
|---------|-----|------|-----|------|-----|---------|--------|
| Algebraic effects | Yes | Yes | No | No | No | Libraries | No |
| Effect handlers | Yes | Yes | No | No | No | Libraries | No |
| Behavioral types | Yes | No | No | No | No | No | No |
| Schema evolution | Yes | No | No | No | No | No | No |
| Elm-style errors | Goal | No | Yes | Partial | No | Partial | Partial |
| No runtime exceptions | Goal | Partial | Yes | No | No | No | No |
| Native + JS targets | Yes | Via C | JS only | No | No | No | No |
| Effect-based testing | Yes | Yes | Arch-based | Mocks | Interfaces | Mocks | Process |

### Where Lux Fits

```
                        High Abstraction
                              │
                   Haskell    │
                      │       │
                Elm ──┼── LUX ──┼── Elixir
                      │       │       │
        TypeScript ───┼───────┼───────┼─── Python
                      │       │       │
               Rust ──┼───────┼───────┼─── Go
                      │       │       │
                C++ ──┼── Zig ───────┼─── C
                      │               │
                     Low Abstraction
                      │               │
              Pure FP ─────────────── Imperative
```

### Target Users

1. **Backend developers** wanting explicit effects without monad transformer stacks
2. **Teams** needing testable code without DI framework complexity
3. **Data engineers** dealing with schema changes across versions
4. **Educators** teaching FP without Haskell's learning curve
5. **Elm/Gleam users** wanting effects on the server side
6. **Go developers** wanting better error handling and generics

---

## Part 5: Stress Test Success Criteria

### Must Pass Before 1.0

| Test | Why It Matters | Target |
|------|---------------|--------|
| Self-hosted compiler | Language completeness | Compile Lux with Lux |
| 10k concurrent requests | Backend viability | < 100ms p99 latency |
| 1M row processing | Schema evolution at scale | < 10s with migrations |
| 100-file project | Module system | < 2s compile time |
| Full test suite in Lux | Dogfooding | 100% pass rate |
| 24-hour server run | Memory stability | No memory growth |

### Performance Targets

| Benchmark | Target | Rust | Go | Node.js |
|-----------|--------|------|-----|---------|
| Fibonacci(40) | < 1s | 0.3s | 0.5s | 1.5s |
| Quicksort 1M | < 500ms | 80ms | 150ms | 300ms |
| HTTP req/sec | > 50k | 200k | 100k | 50k |
| JSON parse 1MB | < 50ms | 10ms | 20ms | 30ms |
| Startup time | < 50ms | 1ms | 10ms | 100ms |
| Memory (hello) | < 10MB | 2MB | 5MB | 30MB |

### Ecosystem Health Indicators

| Metric | Target | Why |
|--------|--------|-----|
| Packages on registry | 100+ | Usable ecosystem |
| Stars on GitHub | 1000+ | Community interest |
| Discord/forum members | 500+ | Active community |
| Production users | 10+ | Real-world validation |
| Contributors | 20+ | Sustainable development |

---

## Part 6: Priority Recommendations

### Next 3 Projects to Build

1. **Property-Based Testing Framework** (Tier 1)
   - Uses behavioral types to prove properties
   - Shrinking shows effect system handles state
   - Tests the language with the language

2. **Database Query Builder** (Tier 1)
   - Schema evolution core use case
   - Type-safe SQL generation
   - Effect tracking for queries

3. **Job Queue System** (Tier 2)
   - Behavioral types prove idempotency
   - Effect handlers for testing
   - Real production use case

### Ecosystem Needs (Priority Order)

| Package | Priority | Impact |
|---------|----------|--------|
| HTTP framework (routing, middleware) | P0 | Web services |
| PostgreSQL/MySQL driver | P0 | Real backends |
| Property-based testing | P0 | Code quality |
| CLI argument parser | P1 | Tools |
| Template engine | P1 | HTML generation |
| Logging (structured) | P1 | Operations |
| JSON Schema validation | P1 | APIs |
| Metrics/tracing | P2 | Observability |
| Markdown parser | P2 | Documentation |
| TOML/YAML parser | P2 | Configuration |