Continued development

The immediate goal is to expand the range of common backends that can be written in readable High, with consistent rules for types, ownership, failures, and resource cleanup. Rust native code generation and existing libraries remain the foundation.

This page describes the priorities for future development. Release dates remain undecided. See the reference for current APIs and CHANGELOG for changes by version.

Priorities

1. Make existing language rules consistent. Review owned, view, moves, branch and loop checks, arithmetic failures, and source mapping. Track check-success/build-failure cases with reproductions and distinguish Nagi diagnostics from checks delegated to Rust.
2. Define native resource boundaries. Specify opaque type identity, borrowing, sharing, asynchronous cleanup, and work that remains after cancellation. Evaluate general traits and new syntax only when concrete APIs establish a need.
3. Organize the standard library. Provide HTTP, JSON, and database APIs through modules and separate unused runtime dependencies. Generated Serde and row conversions and exported types also need support; making Cargo dependencies optional is insufficient.
4. Generalize database access. Use separate modules and resource types for SQLite and PostgreSQL while aligning parameter, row, and error rules. The SQLite Pool/Tx API and cleanup policy are included in 0.2.0. See SQLite Pool and Transaction for usage and limits. Nagi 0.1.10's explicit SQL/schema checks cover SQLite names, result columns, and bind counts, but not value types, NULL behavior, or other databases.
5. Compare HTTP foundations. Evaluate Axum/Tower first against the current implementation with matching APIs, limits, failures, and shutdown conditions. Compare normal load, overload, sustained operation, and maintenance costs before deciding on adoption. Replacement is undecided.
6. Validate boundaries through examples and documentation. Show Nagi and Rust checks, main/release differences, and measurement conditions. Evaluate diagnostics and usability through implementations of the same tasks.

See the library and Rust integration proposal. ADR 010 records the adopted initial SQLite contract. API names and cleanup contracts for other resources still have unresolved details.

The narrow migration requiring explicit move for assignment of an existing owned value, spawn result handles, and business Err/task-fault separation are published in Nagi 0.1.11. The S2 Supervisor/HTTP migration is implemented with the existing Task API and passes the monitor's inner Err through the parent body's try. S2 is also published in Nagi 0.1.11; confirm the installed compiler version. Conditional shared actor messages remain later design work. See DESIGN and ADR 011 for differences from published releases, unresolved details, and migration conditions.

Compiler verification combines known pass/fail examples with bounded generated programs through High, saved Low, and Rust, plus mutation tests. Keep tested cases separate from unsupported combinations and preserve accepted-then-rejected cases as regressions.

Low scope

Preserve existing Low code, brace syntax, inspection of generated output, and function replacement. Prioritize High and Rust integration. Plans to expand Low into an independent systems language with pointers, layout, unsafe syntax, C ABI, and SIMD are paused.

See High and Low for these limits and current usage.

self-hosting

An independent backend, self-hosting, a custom VM or scheduler, hot code replacement, and distributed actors have not been started. Whether to pursue them remains undecided.

Preserving semantics with another backend requires contracts and implementations for types, ownership, cleanup, failures, asynchronous work, and runtime integration. Rewriting the compiler in Low is not a requirement for the current development stage.

S1 Task result handles and the S2 Supervisor/HTTP migration are published in Nagi 0.1.11. S2 uses existing APIs. Check usage and the service example. Public Pool/Tx is included in 0.2.0.

0.2.0 Security Foundation

Nagi 0.2.0 Security Foundation was released on 2026-10-20, after four-OS and browser acceptance. It includes explicit HTTP policy, request-bound Grants, durable Sessions/Cookies, CSRF/CORS, a typed HTML subset, literal SQL with typed binding, outbound destination checks, and response/rate budgets. See migration and the individual API references for limits.

0.2.1 plan: HTTP response decompression (SF06-COMP-021)

This follow-up is planned and not started; implementation count is 0. The 0.2.0 HTTP client accepts identity encoding only and fails on other Content-Encoding values without implicit decoding or retry.

For 0.2.1, choose codecs after independent dependency review and separately bound encoded/decoded size, memory, and processing time. Acceptance must safely stop on corrupt input or cancellation and release resources only after the worker actually joins. Codec selection, concrete limits, and a universal strict CPU guarantee remain undecided. Preserve existing API signatures and safety contracts. Retain Q1's finite TCP failover and one-operation TTL=0 rule; do not automatically retry decode failures. Implementation, review, and website generation have not run.