Data lives exactly as long as the lexical scope that created it.
Outer scopes can never retain references to inner allocations.
There is no GC.
No traditional Rust-style borrow checker.
No hidden lifetimes.
No implicit reference counting.
When a scope exits, everything allocated inside it is freed deterministically.
---
Here’s the basic idea in code:
fn handler() {
let user = load_user() // task-scoped allocation
CACHE.set(user) // compile error: escape from inner scope
CACHE.set(user.clone()) // explicit escape
}
The compiler enforces these boundaries at compile time. There are no runtime lifetime checks.
Memory management becomes a structural invariant. Instead of the runtime tracking lifetimes, the program structure makes misuse unrepresentable.
Concurrency follows the same containment rules.
fn fetch_all(ids: [Id]) -> Result<[User]> {
parallel {
let users = fetch_users(ids)?
let prefs = fetch_prefs(ids)?
}
merge(users, prefs)
}
This is structured concurrency in the literal sense: when a parallel scope exits (success or failure), its memory is cleaned up automatically.
Failure and retry are also explicit control flow, not exceptional states:
let result = restart {
process_request(req)?
}
No partial state.
No manual cleanup logic.
---
Why I think this is meaningfully different:
The model is built around containment, not entropy. Certain unsafe states are prevented not by convention or discipline, but by structure.
This eliminates:
* Implicit lifetimes and hidden memory management
* Memory leaks and dangling pointers (the scope is the owner)
* Shared mutable state across unrelated lifetimes
If data must live longer than a scope, that fact must be made explicit in the code.
---
What I’m trying to learn at this stage:
1. Scalability. Can this work for long-running, high-performance servers without falling back to GC or pervasive reference counting?
2. Effect isolation. How should I/O and side effects interact with scope-based retries or cancellation?
3. Generational handles. Can this replace traditional borrowing without excessive overhead?
4. Failure modes. Where does this model break down compared to Rust, Go, or Erlang?
5. Usability. What common patterns become impossible, and are those useful constraints or deal-breakers?
---
Some additional ideas under the hood, still exploratory:
* Structured concurrency with epoch-style management (no global atomics)
* Strictly pinned execution zones per core, with lock-free allocation
* Crash-only retries, where failure always discards the entire scope
---
But the core question comes first:
Can a strictly scope-contained memory model like this actually work in practice, without quietly reintroducing GC or traditional lifetime machinery?
NOTE: This isn’t meant as “Rust but different” or nostalgia for old systems.
It’s an attempt to explore a fundamentally different way of thinking about memory and concurrency.
I’d love critical feedback on where this holds up — and where it collapses.
Thanks for reading.