Announcing dinah 0.1.0

Today dinah 0.1.0 is live on crates.io. It is a Rust-first, modular runtime and high-performance compute foundation — the kind of sentence that needs unpacking, so let me unpack it the way the project itself would: with specifics.

DINAH is eight modules — core, runtime, memory, compute, ecs, simulation, networking and storage — plus a manifest-driven CLI. It has no runtime dependencies. It contains zero unsafe blocks, enforced at the crate root with forbid(unsafe_code). It ships 293 passing tests including doc-tests, 90.9% line coverage enforced in CI, benchmarks archived from five platforms, and a public C ABI limited to fixed-width scalar queries.

The rule that shaped everything

Early in the project a single rule was adopted and it decided almost every design that followed:

That sounds obvious until you look at what it excludes. No performance claims without an archived, reproducible benchmark. No "coming soon" features presented as capabilities. No hiding a known limitation in the hope nobody hits it. The README literally contains a table of what DINAH is not.

The most visible consequence: the parallel compute paths are documented as slower for lightweight kernels. They are. We measured them — at 262,144 elements, two workers ran 4 to 10.3 times slower than the sequential loop across the five CI runners. That number is in the documentation, next to the explanation of why sequential is the default and parallelism is opt-in.

A checklist you can audit

The release was driven by a 287-point checklist that lives in the repository. Every point links to its evidence: tests, benchmark runs with environment metadata, security review notes. The v0.1 cycle closed with 279 points complete, zero in progress, and 8 deliberately deferred — each deferred point is not a silent omission but a tracked v0.2 goal with its own ID.

The security review is a good example of the tone. It documents what the manifest parser does not protect against, that corruption tests are a deterministic corpus rather than coverage-guided fuzzing, and that the whole document is a static review, not an external audit. Pre-alpha software that describes its own attack surface honestly is rare, and it is the thing I am proudest of.

Try it

$ cargo add dinah

use dinah::ecs::World;

fn main() -> Result<(), dinah::ecs::WorldError> {
    let mut world = World::new();
    let entity = world.spawn()?;
    world.insert(entity, 42_u32)?;
    assert_eq!(world.get::(entity), Some(&42));
    world.despawn(entity)?;
    Ok(())
}

MSRV is Rust 1.95, verified empirically — the workspace genuinely fails to compile on 1.94. Edition 2021, MIT OR Apache-2.0, and the package was verified with cargo package and a publish dry-run before the upload.

What is next

The v0.2 design is already written and approved. The priorities come from measured gaps in the frozen v0.1 contract: the networking wire format (v1 framing, encoder/decoder, structured versioned events), ECS component queries and safe parallel system execution, storage transactions, and a full TOML manifest parser. No dates — only design, evidence and a checklist, which is exactly how this release was built too.

If deterministic, honest infrastructure is your kind of thing, the repository has guides for every module, a performance baseline, a security review and the complete evidence trail. Criticism welcome — especially about the things we got wrong.