Vision & Design Principles

1. Abstract

Aura is a statically typed, compiled language for services, CLIs, workers, and libraries that ship as a single native executable. The user-facing language is class-based (Java-like) with null-safe types, exceptions plus Result, and a Go-like runtime: tracing GC and M:N lightweight tasks. The toolchain is implemented in Rust and lowers through LLVM to platform binaries.

This RFC locks product vision, non-goals, design principles, and the cross-RFC decision set that all subsequent RFCs must respect. It does not specify grammar, type rules, or compiler internals—those live in child RFCs.

2. Motivation

2.1 Problem statement

Teams building modern backends and tools often face a false choice:

Aura targets a middle path: Java-like productivity and object model, Go-like concurrency and GC, native single-file deploy, with a coherent first-party toolchain (compiler, packages, build, test, CLI).

2.2 Why now

• Demand for copy-one-binary deploy (containers, edge agents, CLI distribution) is higher than ever.
• LLVM and Rust make a high-quality greenfield toolchain realistic without waiting for self-host.
• Language design can bake in nullability and a clear error model instead of bolting them on decades later.

2.3 Success metrics

3. Goals

Product

• Safe-by-default nullability and explicit escape hatches.
• Predictable performance and memory suitable for long-running servers and short-lived CLIs.
• Batteries-included core stdlib; frameworks stay out of core.
• Excellent diagnostics and day-one CLI workflow.

Platform

• Compiled Aura → single native binary (statically linked or equivalent one-artifact ship).
• Toolchain in Rust; language and stdlib in Aura.
• Reproducible packages and builds (aura.toml + lockfile).
• Cross-platform matrix: Linux, macOS, Windows × amd64/arm64 (v1).

4. Non-goals

• Replacing every language in every domain (no GPU/CUDA model, no browser/DOM first-class in v1).
• Application frameworks, DI containers, ORM/data layers, HTTP app frameworks in core RFCs (may return as separate ecosystem RFCs).
• Day-one self-hosting of the compiler in Aura.
• Full formal machine-checked semantics in MVP (prose + grammar + tests first).
• Node/npm or JVM bytecode as primary interop/runtime (C ABI FFI only for v1 interop).
• WASM as a v1 ship target (may appear later).

5. Prior art & alternatives

6. Design

6.1 Product vision

One-liner: Aura is a Java-like, null-safe, GC language with Go-like tasks that compiles to a single native binary via a Rust+LLVM toolchain.

Narrative: An engineer writes Aura with familiar classes and interfaces, marks nullable references explicitly, handles expected failures with Result and unexpected ones with exceptions, spawns tasks for concurrent I/O, and runs aura build to produce one file they can copy onto a server or ship as a CLI. No separate runtime install for end users of the app artifact; the GC and scheduler are linked into the binary.

6.2 Target users & use cases

6.3 Design principles

For each: statement, rationale, implications, counter-example.

P1 — Safety by default, escape hatches explicit

• Statement: Safe defaults (non-null types, checked boundaries); unsafe, raw FFI, and suppressed checks are explicit and auditable.
• Rationale: Most bugs in service code are mundane (null, races, bad error handling), not exotic.
• Implications: T is non-null; T? is opt-in; race detector in dev; FFI in dedicated modules.
• Counter-example: Implicit null on all references (classic Java) is rejected.

P2 — One artifact from source to production

• Statement: The default build produces a single executable embedding user code + runtime.
• Rationale: Operational simplicity beats multi-file runtime installs for many deploy paths.
• Implications: Runtime is a library linked in; dynamic plugin loading is non-default.
• Counter-example: “Install JRE/Node on every host” as the primary story is out of scope.

P3 — Predictable performance & memory

• Statement: GC and scheduler behavior is documentable; hot paths can use value types/arenas where the language allows.
• Rationale: Services need latency budgets, not only throughput peaks.
• Implications: Prefer simple object model; monomorphized generics where it matters; no hidden interpreter in production path for v1.
• Counter-example: Unbounded reflection-heavy frameworks as stdlib defaults.

P4 — Batteries included, modular core

• Statement: Stdlib covers collections, I/O, net primitives, JSON, log, sync, crypto baseline.
• Rationale: Cold-start ecosystems fail without basics; frameworks are opinionated and version-churny.
• Implications: Core RFCs stop at libraries, not app frameworks.
• Counter-example: Shipping a full web MVC stack inside stdlib.

P5 — Tooling is part of the language

• Statement: Format, test, package, and build are first-class CLI verbs with stable contracts.
• Rationale: Fragmented toolchains destroy DX more than missing syntax sugar.
• Implications: RFC-011/012/005/008 are not afterthoughts.
• Counter-example: “Community will invent the formatter” as the plan.

P6 — Progressive disclosure of complexity

• Statement: Simple programs stay simple; advanced features (attributes, macros, unsafe, FFI) appear when needed.
• Rationale: Onboarding cost dominates adoption.
• Implications: Hello-world needs no build-file ceremony beyond defaults; advanced IR/flags stay opt-in.
• Counter-example: Requiring macros or DI to print a line.

6.4 Pillar map (language → ecosystem)

Language (001–003, 009–010)
    → Compiler / Build / CLI (004, 008, 012)
    → Runtime / Stdlib (006–007)
    → Packages (005, 013)
    → Testing (011)

6.5 Locked cross-RFC decisions

6.6 Guiding trade-offs

6.7 Versioning & stability policy (high level)

• Toolchain & stdlib: Semantic Versioning. Breaking stdlib APIs require major bump; deprecations prefer two minors of warning when practical.
• Language: MVP freezes a “v1 surface.” Breaking surface changes after adoption prefer editions (opt-in per package) rather than silent breaks.
• Packages: Manifest declares Aura edition/language version range (details in RFC-005).

6.8 Examples

// Conceptual tour — syntax stabilized in [RFC-001](/rfc/001)
package demo

class Server {
  fun start(port: Int): Result<Unit, IoError> {
    // bind + accept loop using stdlib net + tasks
    return Result.ok(Unit)
  }
}

fun main() {
  let s = Server()
  match s.start(8080) {
    case Ok(_) => println("listening")
    case Err(e) => throw e   // or log and exit
  }
}

End-to-end narrative: author writes the above → aura new / edit → aura test → aura build -o server → copy server to host → run. No separate GC/runtime install.

6.9 Error model / edge cases

N/A at vision level for program errors. Process-level edge cases:

• Conflict between “Java-like classes” and “Go-like tasks” is intentional; document identity/sharing under GC (RFC-003).
• Single-binary vs future dynamic plugins: plugins are non-goals for core v1.

6.10 Compatibility & migration

• No JS/TS source compatibility. Interop is C ABI and (later) well-defined binary interface for Aura packages.
• Migration from other languages is human/port, not automated transpile as a core promise.
• Within Aura: deprecation + editions as above.

7. Open questions

8. Rationale & trade-offs

Choosing GC + classes optimizes for service developer productivity and a familiar mental model, accepting GC pauses and a richer runtime than pure ownership languages. Choosing LLVM + single binary optimizes for deploy simplicity and native performance, accepting heavier compile infrastructure than a bytecode-only story. Choosing Rust for the toolchain optimizes for toolchain reliability and ship speed without waiting for self-host. Rejecting frameworks in core keeps the RFC set implementable and avoids premature ecosystem lock-in.

9. Unresolved / future work

• Finalize brand, license, governance
• Logo, website, playground
• WASM target RFC (post-v1)
• Self-host roadmap
• Optional ownership/region annotations as opt-in performance layer (not v1 requirement)

10. Security & safety considerations

Security is a design axis, not an add-on:

11. Implementation plan (optional)

12. References

• RFC-001 … RFC-013 (this series)
• Go memory/concurrency model (inspiration)
• Kotlin nullability (inspiration)
• LLVM project
• Rust tooling patterns (Cargo-like workflow inspiration for Aura CLI)

Changelog