Rust .me is now real.

this-me v0.3.0 is published on crates.io, tagged in git, and verified from a clean external Rust project.

This is the Rust ground for the .me semantic kernel: hash-chained memory, path grammar, operators, secrets, derivations, proofs, key wrapping, snapshots, runtime events, receipts, CLI, tests, and benchmarks.

It is not a rewrite of the idea. It is the same .me meaning, moved closer to the metal.

cargo add this-me

use this_me::kernel::Kernel;
let mut me = Kernel::new();
me.postulate("profile.name", "Jabellae")?;

Rust .me is now installable.

crates.io: Rust Package Registry

Performance Snapshot

The first benchmark signal is not just “Rust is fast.”

The important signal is that Rust .me preserves the shape of the kernel.

In .me, a write should not wake the whole universe. It should touch the actual semantic dependency line. That is the point of the graph.

On the current Rust benchmark run:-

• O(k) recompute from 10 to 10,000 nodes: `k = 1` throughout
• 10,000-node recompute p95: `0.0087ms`
• 2,000 sustained mutations p95: `0.0165ms`
• 10,000-memory cold hydration p95: `17.8ms`
• Warm mutation after hydration p95: `0.007ms`
• Secret write/read p95: `0.032ms`

That matters because .me is not trying to be a database benchmark.

It is measuring something more specific:

Can semantic memory stay reactive, inspectable, tamper-evident, and encrypted without turning every mutation into a global recompute?

So far, yes.

The Rust-vs-TypeScript mirror suite shows the same shape. Both kernels preserve the semantic contract, but Rust starts to win in the hot paths:

- Sustained mutation p95: Rust `0.0165ms`, TypeScript `0.0286ms`
- Eager fanout 5,000 p95: Rust `55.39ms`, TypeScript `99.77ms`
- Lazy fanout 5,000 mutation p95: Rust `0.0025ms`, TypeScript `0.0053ms`
- Secret lazy derivation p95: Rust `0.0286ms`, TypeScript `0.5689ms`

The honest interpretation:

Rust .me is not “a faster rewrite.”
It is the same semantic kernel with a smaller runtime surface, stronger memory discipline, and a path toward embedded hosts: gateways, monads, Raspberry Pi-class machines, robots, vehicles, and local sovereign systems.

The rule remains:

improve the mechanics, never change the meaning.

Rust .me v0.3.0 was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most reactivity is O(n). O(k) reactivity is O(k).

When you mutate one piece of state, the system should only do work proportional to how many things actually depend on it — not the size of the whole graph.

cost(mutation) = O(k)   where k = |affected frontier|cost(mutation) = O(n)   where n = |entire graph|  ← React, Zustand, most stores

That’s it.

The Equations

O(n) vs O(k)

O(n): You change price. The framework scans 3000 components/nodes to find who uses price.

O(k): You change price. The runtime jumps directly to the 3 nodes that depend on price. It never sees the other 2997.

How

Inverted Dependency Indexing.

Inverted Dependency Indexing

Instead of storing derived → sources, we maintain:

source path → set of dependent derived paths

On write to p:

T(Δp) = O(|Reach_D(p)| + C_eval)

We follow the frontier, we don’t scan.

Why it matters

Because explainability becomes free.

In .me:

me['!'].explain('order.total')// → { value, expr, inputs, dependsOn, recomputed, sourcePath }

Returning the computation trace is a lookup over the index — not a second pass.

Benchmark (3000 nodes, 300 mutations):

• baseline p95: 0.0122ms
• with explain() p95: 0.0189ms
• overhead: +0.007ms

Faithful trace for 7 microseconds because k << n.

The formula

I = (path, ciphertext, T, A, C)k = |Reach_D(p)|cost = O(k)

Readability (A) is not topology (T). Capability (C) is not identity. And cost is not size.

Go deeper

• Inverted Dependency Indexing: suign.github.io/InvertedIndex.html
• Equations: suign.github.io/Equations.html#ok-reactivity
• Benchmark: me vs React vs Zustand

O(k) is not an optimization. It’s a different complexity class.

What is O(k) Reactivity? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.