Golden is a transpiler that maps Go’s CSP concurrency and syntax directly to Odin. It targets systems-level domains where Go’s Garbage Collector is a deal-breaker (game dev, real-time systems) by replacing the runtime with deterministic memory strategies.
Key Features:
Memory: Automatic Escape Analysis routing to Arenas (stack-like) or ARC (Atomic Reference Counting).
Concurrency: Full mapping of go routines to a custom M:N task scheduler and thread pool.
Channels: Re-implemented as unbuffered rendezvous primitives using Odin’s Mutex/Cond-vars.
Methods: Automatic decoupling of Go methods into procedural Odin procs.
Safety: Injects defer delete for dynamic slices and handles closure-capture via heap-allocated context structs.
I’d love to hear what people think about the approach, especially regarding the mapping of Go semantics to Odin’s procedural style. I am also very open to contributions—there is a lot of room to grow in the standard library mapping and the V2.0 roadmap.
Current status is V1.0 (PoC). Interfaces and Maps are on the roadmap.
Converting from Go to Odin like this makes no sense. You’re not going to get any huge “high performance benefits” out of this in the slightest and don’t pretend that it will.
Use Go directly if you want its GC and goroutines which cannot be replicated in Odin.
Otherwise, use Odin directly if you want more control.
I really appreciate the feedback and totally get where you’re coming from. To be clear, this is purely a learning experiment and a personal challenge for me.
I’m not chasing ‘magic’ performance gains over idiomatic Odin. The project is driven by two simple things: I really enjoy Go’s syntax/CSP flow, and I wanted to see if I could map that logic to deterministic memory management (Arenas/ARC) for environments where a GC is a deal-breaker.
It’s definitely a ‘what-if’ PoC, but it’s been a great way to dive deep into transpilation and memory models!
I think this is an interesting exploration even though it likely isn’t production-viable. I’ll let you cook.
I think automatic memory management tends to conflict somewhat with the grouped-element mindset that Odin is trying to steer you towards, however if you just want to experiment with a simple translation step as a starting point, I think this tool could help with that.
How do you determine whether to route a variable to the arena allocator or ARC? What strategy are you using to determine when to call free_all? The most important aspect of any sort of automatic memory management is that users should never accidentally have a pointer to memory that has been freed and/or reallocated as long as they’re using the automatic memory management facilities. The lifetime of a particular allocation can be out-of-band knowledge that can’t be entirely determined by escape analysis or general control flow.
