Blog posts related to the .NET/F# concept "Async-Await"
← Back to all tagsBlog posts related to the .NET/F# concept "Async-Await"
← Back to all tagsThe “AI industrial complex” in its current form is not sustainable. While transformers have delivered remarkable capabilities, their energy consumption and computational demands reveal a fundamental inefficiency: we’re fighting against nature’s design principles. The human brain operates on roughly 20 watts, processing massive volumes of information through sparse, event-driven spikes. (at least, as we currently understand it today) Current AI systems consume thousands of watts to support narrow inference capabilities, forcing dense matrix operations through every computation.
Read MoreThe 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.
Read MoreModern async and parallel programming presents an engineering challenge: we need both the performance of low-level control and the safety of high-level abstractions. Nearly 20 years ago, the .NET ecosystem pioneered the async/await syntactic pattern, making concurrent code accessible to millions of developers and influencing other technology stacks in following years. However, this pattern comes with tradeoffs - runtime machinery that, while powerful, can become opaque when we need to understand or optimize workload behavior.
Read MoreModern processors are marvels of parallel execution. A typical server CPU offers dozens of cores, each capable of executing multiple instructions per cycle through SIMD operations. GPUs push this further with thousands of cores organized in warps and thread blocks. Emerging accelerators like NextSilicon’s Maverick or Graphcore’s IPU reimagine computation entirely. Yet most code fails to harness even a fraction of this power. Why? Because choosing the right parallel execution strategy requires understanding not just what your code does, but what it needs from its environment.
Read MoreWhen we set out to build Firefly, we faced a fundamental question that cuts to the heart of functional systems programming: how far down the compilation stack can we preserve the elegant abstractions that make F# powerful? Specifically, can delimited continuations - the theoretical foundation for async/await, generators, and algebraic effects - survive the journey from high-level F# through MLIR’s SSA form to executable code? And perhaps more importantly, should they?
Read MoreIn 1998, Andrew Appel published a paper that heralded a change to how we should think about compiler design. “SSA is Functional Programming” demonstrated that Static Single-Assignment form, the intermediate representation at the heart of modern optimizing compilers, is exactly equivalent to functional programming with nested lexical scope. This insight has profound implications as we enter a new era of hardware-software co-design. At SpeakEZ, this revelation validates our approach with the Fidelity framework more than 25 years after its first publication: lowering F# to native code through MLIR isn’t just possible, it’s aligned to the fundamental structure of well-principled compilation.
Read MoreThe Fidelity Framework faces a fascinating challenge: how do we identify opportunities for massive parallelism hidden within sequential-looking F# code? The answer lies in an elegant application of graph coloring to our Program Hypergraph (PHG), using bidirectional zippers to traverse and analyze control flow and data flow patterns. This approach, inspired by insights from Ramsey graph theory, enables automatic discovery of where async and continuation-based code can be transformed into interaction nets for parallel execution.
Read MoreThe 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.
Read MoreThe Fidelity framework represents an ambitious project to bring F# to native compilation without runtime dependencies. One of the most challenging aspects of this endeavor is the treatment of asynchronous programming. This design document outlines our approach to compiling F#’s async computation expressions to efficient native code through delimited continuations, and introduces Frosty, an enhancement that brings advanced async patterns to this runtime-free environment. 🔄 Updated July 25, 2025 True RAII principles for automatic async resource management Bidirectional PSG “zipper” computation expressions for async transformations Integration with Olivier actor model for structured concurrency …with special thanks to Paul Snively for his polyglot perspective that led to many of the connections drawn through the latest updates.
Read MoreThe future of AI inference lies not in ever-larger transformer models demanding massive GPU clusters, but in a diverse ecosystem of specialized architectures optimized for specific deployment scenarios. At SpeakEZ, we’re developing the infrastructure that could make this future a reality. While our “Beyond Transformers” analysis explored the theoretical foundations of matmul-free and sub-quadratic models, this article outlines how our Fidelity Framework could transform these innovations into practical, high-performance inference systems that would span from edge devices to distributed data centers.
Read MoreWe 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:
Read MoreThe embedded systems industry has operated under a fundamental assumption for decades: achieving hardware control requires sacrificing high-level abstractions and type safety. This assumption has created a divide between embedded development and modern software engineering practices, forcing developers to choose between expressiveness and efficiency. The Fidelity Framework challenges this paradigm through a revolutionary approach that delivers hardware type safety with truly zero runtime cost, a breakthrough in hardware/software co-design methodology.
Read MoreIn 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.
Read MoreLast year, we explored how F#’s type system could transform threshold signature security through FROST. Today, we’re tackling an even more challenging problem: the conspicuous absence of end-to-end encryption in group messaging. While Signal has admirably protected one-to-one conversations for years, their group chat implementation remains a study in compromise. Telegram simply gave up, offering no end-to-end encryption for groups at all. The reasons aren’t mysterious. Group encryption faces fundamental mathematical challenges that individual encryption elegantly sidesteps.
Read MoreIn 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.
Read More