Welcome to the Fidelity Framework Discussion forums

[houstonhaynes]

Welcome to Fidelity Framework Discussions

We're opening this space to share what we're building and, more importantly, to learn from developers who see F# from different vantage points than we do.

What Brings Us Here

The Fidelity Framework started from a question: what if F#'s elegance and safety didn't have to end at the runtime boundary?

Most F# developers work at an abstraction level where the .NET runtime is invisible infrastructure. You write functions, compose pipelines, define types—and the CLR handles everything underneath. That's the right abstraction
for most work. It's productive. It's safe. It works.

But some domains push against those boundaries. Embedded systems. Real-time audio and video. High-frequency trading. IoT devices with kilobytes of RAM. Edge computing where every millisecond of cold start matters. These contexts share a common constraint: the assumptions baked into managed runtimes become liabilities rather than conveniences.

Fidelity asks whether we can keep what makes F# valuable—the type safety, the expressiveness, the functional patterns—while compiling to native binaries that run without a runtime, without a garbage collector, with deterministic memory behavior.

What Makes This Different

This isn't transpilation to another language's ecosystem (like Fable's excellent JavaScript/TypeScript output). It's not a different runtime (like .NET Native or NativeAOT). It's direct compilation: F# source to MLIR to LLVM to machine code.

The compiler uses a nanopass architecture—many small, composable transformations rather than monolithic phases. Each pass does one thing. This design enables something we care deeply about: carrying proofs and safety guarantees through compilation rather than discarding them. When F# tells you a function is pure, that information can guide optimization. When types guarantee bounds, we can eliminate redundant checks.

We call it "Fidelity" because the properties you rely on in your F# code remain true in the generated binary.

Why We Want to Hear from You

We're building this from a systems programming perspective—thinking about memory layouts, cache lines, register allocation, syscall surfaces. But that's only part of the picture.

Most F# value comes from developers who think at higher levels of abstraction. Application builders. Domain modelers. People who chose F# because discriminated unions elegantly express business logic, not because they wanted to think about stack allocation.

We want to understand:

• What would native compilation unlock for you? Faster startup? Smaller binaries? Deployment to constrained environments? Something else entirely?
• What would you need to give up, and is it worth it? The reflection-heavy libraries you depend on may not translate. Some patterns assume garbage collection. Where are the real friction points?
• What does "F# without .NET" even mean to you? Is that intriguing, terrifying, or just irrelevant to your work?

There are no wrong answers. We're genuinely curious about perspectives different from our own.

The State of Things

Everything here is under active development. APIs are unstable. The framework is not yet suitable for production use. We're building in the open because we believe the conversations along the way matter as much as the destination.

If you're curious, the SpeakEZ blog has deeper dives into the architectural thinking. Our Ask AI is a good starting point to provide context-driven access to our nearly 100 technical blog entries (and counting!).

Ground Rules

This is a space for technical discussion, questions, and genuine exchange of ideas. We're here to learn from each other. Critique is welcome; the goal is to make something better than any of us could alone.

Welcome aboard.

— Houston Haynes
Founder, SpeakEZ Technologies