Blog posts related to the .NET/F# concept "GC"
← Back to all tagsBlog posts related to the .NET/F# concept "GC"
← Back to all tagsThe 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 MoreThe “byref problem” in .NET represents one of the most fundamental performance bottlenecks in managed programming languages. While seemingly technical, this limitation cascades through entire application architectures, not only hijacking developer productivity but also forcing them into defensive copying patterns that can devastate performance in memory-intensive applications. The Fidelity framework doesn’t just solve this problem; our designs transform the limitation into the foundation for an entirely new approach to systems programming that maintains functional programming elegance while delivering hardware-level performance.
Read MoreAt the intersection of two powerful but largely separate computing paradigms stands the Fidelity framework, a revolutionary approach to systems programming that re-imagines what’s possible when functional programming meets direct native compilation. For decades, developers have been forced into an artificial choice: embrace the productivity and safety of managed runtimes like .NET and the JVM while accepting their performance limitations, or pursue the raw efficiency of direct compilation while shouldering the burden of manual memory management and more complex development workflows.
Read MoreHere at SpeakEZ we’re rethinking how developers interact with memory management in systems programming. The conventional wisdom suggests we face a stark choice: embrace the ubiquitous memory burdens of Rust or abdicate all memory concerns and accept the performance penalties of garbage collection. We believe there’s a better way. Mandatory vs. Optional Memory Management Rust’s borrow checker has revolutionized systems programming by statically preventing memory safety issues, but it comes at a significant cost: every line of code must consider ownership and borrowing.
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 MoreFor .NET developers, the term “frontend” already carries rich meaning. It might evoke XAML-based technologies like WPF or UWP, the hybrid approach of Blazor, or perhaps JavaScript visualization frameworks such as Angular, Vue or React. Within the .NET ecosystem, “frontend” generally refers to user interface technologies - the presentation layer of applications. When that same .NET developer encounters terminology like “MLIR C/C++ Frontend Working Group,” something doesn’t quite compute. This clearly isn’t referring to user interfaces or presentation technologies.
Read MoreThe promise of functional programming has always been apparent: write code that expresses a process to an end result, not how the machine should perform those actions. Yet for decades, this elegance came with a tax - runtime overhead, garbage collection pauses, and the implicit assumption that “real” systems programming belonged to C and its descendants. The Fidelity Framework challenges this assumption by asking a different question: What if we could preserve F#’s expressiveness, safety and precision while compiling to native code that rivals hand-written C in efficiency?
Read MoreThe computing landscape has undergone seismic shifts over the past three decades, yet many of our foundational software platforms remain anchored to paradigms established during a vastly different technological era. Virtual machines and managed runtime environments like Java’s JVM and .NET’s CLR emerged during the late 1990s and early 2000s as solutions to very specific problems of that time: platform independence, memory safety, and simplified development in an era of relatively homogeneous computing resources.
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 More