Concept: Actor-Model

The story of distributed systems in F# begins with two distinct programming traditions that converge in F# in unique ways. From OCaml came the functional programming foundation and type system rigor. From Erlang came the mailboxprocessor and with it their ground-breaking approach to fault-tolerant distributed systems. And Don Syme’s innovations that fused true concurrency into the primitives of a high-level programming languages was a revelation. What emerged in F# was neither a simple port nor a mere combination, but something distinctly new: a language that could express actor-based concurrency with type safety, integrate with existing ecosystems, and compile to multiple target platforms.

The actor model isn’t new. Carl Hewitt introduced it at MIT in 1973, the same year that Ethernet was invented. For fifty years, this elegant model of computation, where independent actors maintain state and communicate through messages, has powered everything from Erlang’s telecom switches to WhatsApp’s billions of messages. But until now it has required specialized runtimes, complex deployment, or significant infrastructure overhead. Today’s “AI agents” are essentially rediscovering what distributed systems engineers have known for decades: isolated, message-passing actors are the natural way to build resilient, scalable systems.

Modern computing systems present a fundamental paradox: while processor speeds have increased exponentially, memory latency improvements have been modest, creating an ever-widening performance gap. This disparity manifests most acutely in the cache hierarchy, where the difference between an L1 cache hit (approximately 4 cycles) and main memory access (200+ cycles) represents a fifty-fold performance penalty. For systems pursuing native performance without runtime overhead, understanding and exploiting cache behavior becomes not merely an optimization, but an architectural imperative.

The integration of reactive programming into the Fidelity framework presents a fascinating challenge at the intersection of practical engineering and algorithmic integrity. While exploring various reactive models, we discovered valuable insights from Ken Okabe’s Timeline library - a minimalist F# implementation that demonstrated how powerful reactive systems could be built with remarkably little code. This simplicity was a key inspiration for Alloy.Rx, though we’ve evolved the concepts to align with Fidelity’s unique architectural requirements.

The journey of building the Fidelity Framework has taught us that meaningful changes require careful conceptual positioning alongside technical innovation. When we first introduced the design of Firefly’s zero-allocation compilation capabilities, we established a foundational principle that continues to guide our architectural decisions: functional programming should compile to efficient native code without runtime dependencies. Today, we want to explore how this foundation extends naturally into our roadmap for memory management, and is consistent with the core principles that make Fidelity unique.

While this idea might be met with controversy in the current swarm of AI hype, we believe that the advent of sub-quadratic AI models, heterogeneous computing, and unified memory architectures will show themselves as pivotal components to next generation AI system design. The elements are certainly taking shape. As we stand at this technological crossroads, AMD’s evolving unified CPU/GPU architecture, exemplified by the MI300A and its planned successors (MI325, MI350, MI400), combined with their strategic acquisition of Xilinx, offers a compelling case study for re-imagining how AI models can operate.

The Fidelity Framework and its ecosystem of technologies represent more than technical achievements, they embody our core values in executable form. Where our Compact establishes how people and groups interact within the SpeakEZ ecosystem, our technical innovations demonstrate these same principles applied to systems design. This alignment between human values and technical architecture is neither accidental nor superficial; it reflects our belief that sustainable innovation emerges when technological choices reinforce rather than contradict constituent needs.

As we’ve established in previous entries, FidelityUI’s zero-allocation approach provides an elegant solution for embedded systems and many desktop applications. But what happens when your application grows beyond simple UI interactions? When you need to coordinate complex business logic, handle concurrent operations, and manage sophisticated rendering pipelines? This is where the Olivier actor model and Prospero orchestration layer transform FidelityUI from a capable UI framework into a comprehensive application architecture that scales to distributed systems, all while maintaining deterministic memory management through RAII (Resource Acquisition Is Initialization) principles.

As a companion to our exploration of CXL and memory coherence, this article examines how the Fidelity framework could extend its zero-copy paradigm beyond single-system boundaries. While our BAREWire protocol is designed to enable high-performance, zero-copy communication within a system, modern computing workloads often span multiple machines or data centers. Remote Direct Memory Access (RDMA) technologies represent a promising avenue for extending BAREWire’s zero-copy semantics across network boundaries. This planned integration of RDMA capabilities with BAREWire’s memory model would allow Fidelity to provide consistent zero-copy semantics from local processes all the way to cross-datacenter communication, expressed through F#’s elegant functional programming paradigm.

We at SpeakEZ have been working on the Fidelity framework for a while, and it’s been a journey to find the right balance of familiar conventions with new capabilities. Nowhere is that more apparent than in the async/task/actor models for concurrent programming. The Iceberg Model: Familiar on the Surface, Revolutionary Underneath Think of Fidelity’s concurrency model as an iceberg. Above the waterline, it looks remarkably similar to what you already know:

Erlang emerged in the late 1980s at Ericsson, during an epoch when distributed systems were in their infancy and reliability was becoming a critical concern in telecommunications. Born out of the practical need to build telephone exchanges that could achieve the mythical “nine nines” (99.9999999%) of uptime, Erlang introduced a paradigm shift in how we approach concurrency and fault tolerance. A Pioneer in Reliable Distributed Computing In an era dominated by object-oriented programming and shared-state concurrency, Erlang boldly embraced functional programming with immutable data and the actor model.

This entry examines the architectural rationale behind avoiding the creation of yet another managed runtime system, instead advocating for our actor-oriented approach. As computing platforms continue to diversify across embedded systems, mobile devices, edge computing, and specialized accelerators, the traditional monolithic runtime model faces increasing challenges. Our approach with the Olivier/Prospero actor model provides the security benefits of managed memory without the restrictions and overhead of conventional runtimes. THE RUNTIME LANDSCAPE: A REPEATING CYCLE The Legacy of Monolithic Runtimes Traditional runtimes like the JVM and .

In our work to bring F# to systems programming, we’re pursuing a vision of deterministic memory management outside the familiar boundaries of managed runtimes. For developers who have only known automatic memory management as an omnipresent runtime service, the concept we’re pursuing - applying RAII (Resource Acquisition Is Initialization) principles to actor-based systems - represents a significant departure from established patterns. Our current research focuses on how three complementary systems work together: RAII-based arena allocation, the Olivier actor model we’re developing, and our proposed Prospero orchestration layer.

In the coming waves of “AI” innovation, the computing landscape will continue to fragment into an increasingly divergent array of hardware choices. From embedded microcontrollers to mobile devices, workstations, and accelerated compute clusters, developers will face a challenging decision: build with distinctly different “stacks” for each target or accept the deep compromises of existing cross-platform frameworks. Meanwhile, Python continues its paradoxical ascent, simultaneously becoming the lingua franca of modern computing while quietly imposing an unsustainable tax on engineering resources.