Hi everyone,

If you’ve ever tried to build a high-performance backend, you know the pain of the "Concurrency Trilemma."

You usually have to pick your poison:

1. Callback, Promise, or Async Hell (Rust/JS) where coloured functions fragment your codebase.
2. Mutex Hell (Go/C++) where shared-state leads to subtle race conditions and deadlocks.
3. The GC Ceiling (Erlang/Elixir) where you get a brilliant mental model, but pay for it in garbage collection pauses and VM overhead.

I got tired of choosing. For the last several months, I’ve been heads-down building a system that tries to solve this at the architectural level.

Today, I’m open-sourcing Tina.

Tina is a strictly bounded, thread-per-core concurrency framework written in Odin.

It works by enforcing brutal constraints. There is no async/await. There are no mutexes. There is zero dynamic memory allocation after the system boots.

Instead, you write simple, synchronous-looking state machines called Isolates. They process a message, and return an Effect (like .io, .call, or .yield). The framework handles everything else.

Because the framework strictly controls the clock, the network, and the memory, we get a massive superpower: 100% Deterministic Simulation Testing. You can simulate a massive multi-core distributed system on a single thread. If it crashes at tick 84,212 , you can paste the seed and watch it crash at the exact same tick, every single time (until you fix the issue).

I want you to be the first to see it.

If you are a systems engineer, or just someone who is tired of fighting your programming language to handle massive I/O, I would love for you to check out the architecture.

I wrote extensive documentation on the tradeoffs I accepted to make this work. (For example: why strictly bounded mailboxes that drop messages are safer than infinite queues that crash your server).

I’d love your brutal, honest feedback. Reply directly to this email, or open a discussion on GitHub.

Talk soon,

Peter Mbanugo