Story

I’ve spent the last few months rethinking how a dynamic language runtime should interact with modern hardware. The result is ProtoCore and its first major implementation, ProtoJS.

Most dynamic runtimes (Python, Ruby, and even JS engines) handle concurrency through Global Interpreter Locks (GIL) or complex memory barriers because managing mutable state across threads is notoriously difficult.

With ProtoCore, I took a different path based on three pillars:

Immutability by Default: All core data structures are immutable. Instead of locking, we use structural sharing for memory efficiency. This inherently eliminates data races at the object level.

Hardware-Aware Memory Model: Objects are cache-line aligned (64-byte cells) to prevent false sharing and optimize cache locality.

Tagged Pointers: We use a 56-bit embedded payload for SmallIntegers, meaning zero heap allocation for most numeric operations.

To prove the architecture, I built ProtoJS. It uses QuickJS for parsing but replaces the entire runtime with ProtoCore primitives. This allows for real worker thread execution ("Deferred") where immutable objects are shared across threads without copying or GIL-related contention.

Current Status:

ProtoCore: 100% test pass rate (50/50 tests) and a comprehensive technical audit completed today.

ProtoJS: Phase 1 complete, demonstrating real parallel execution and sub-1ms GC pauses.

I’m an Electronic Engineer by training (now a university professor), and I wanted to see if applying low-level hardware principles could fix the high-level concurrency "mess."

I’d love to hear your thoughts on the trade-offs of this immutable-first approach in systems programming.

ProtoCore (The engine): https://github.com/numaes/protoCore ProtoJS (The JS runtime): https://github.com/gamarino/protoJS