It shares the runtime, the packages, and the debugger with C#. That still was not enough.
Elixir asks a team to run a different virtual machine. Rust asks a team to relearn how memory works. F# asks almost nothing: it compiles to the same intermediate language as C#, ships in the same .NET SDK, calls existing C# libraries directly, and debugs in the same Visual Studio or Rider window. Of the three functional-leaning languages developers talk about today, F# had by far the shortest distance to travel inside an existing enterprise stack. It is worth asking, plainly, why that head start never turned into the kind of adoption Rust and Elixir eventually found.
Riding the Same Rails as C#
F# was designed by Don Syme at Microsoft Research, first released in 2005 as a .NET-flavored descendant of OCaml, and bundled into Visual Studio starting with the 2010 release, at the same level as C# and Visual Basic. That placement was not symbolic. F# projects compile to ordinary .NET assemblies, so a service written in F# can call a library written in C#, and a C# project can reference a component written in F#, in the same solution, with no adapter layer. There is one NuGet feed, one CLR, one set of profiling and debugging tools. For a team already running .NET in production, trying F# does not mean standing up new infrastructure, it means adding a project to a solution that already exists.
| Language | Runtime relative to an existing .NET shop | Interop with existing code |
|---|---|---|
| F# | Same CLR, same .NET SDK | Direct, in the same solution |
| Elixir | Separate BEAM/Erlang VM | Through ports, NIFs, or services |
| Rust | Separate toolchain (Cargo, rustc) | Through FFI or a service boundary |
What the Survey Numbers Actually Say
If low friction were the deciding factor, F# should show up somewhere between C# and the newcomers. The 2025 Stack Overflow Developer Survey, with responses from over 49,000 developers, suggests otherwise.
F# sits at 1.3%, behind Elixir’s 2.7% and nowhere close to Rust’s 14.8%, despite running on a platform C# alone puts in front of 27.8% of all respondents. Sharing a runtime with a popular language did not translate into borrowed popularity.
Loved Once You’re There, Nobody’s Queued Up to Arrive
The same survey asks two related questions: who used a language and wants to keep using it (admired), and who wants to use a language next year regardless of past experience (desired). The gap between the two tells a sharper story than usage alone.
F# is admired by 49.1% of the people who actually use it, a respectable score, close to C#’s own 55.8%. The problem shows up on the desired side: only 2.9% of all respondents want to pick it up next year, versus 29.2% for Rust and 5.8% for Elixir. People who try F# tend not to regret it. Almost nobody outside that group is curious enough to try it in the first place, and that is the number that decides whether a language spreads.
Microsoft’s Own Strategy Document Says the Quiet Part Out Loud
Microsoft maintains a public strategy page for its three .NET languages. It describes C# plainly: “the most widely used language” and “most of .NET is written in” it. F# gets a different framing: it “explores new language possibilities” while the community carries much of the tooling and library work. That is not a knock on the language, but it is Microsoft naming, in its own documentation, which language gets the aggressive investment and which one gets encouragement from the sidelines. Rust, by contrast, has been landed inside Windows kernel components and Azure infrastructure on its own technical merits, and Elixir built a following by offering something C# and F# alike do not: the Erlang VM’s process isolation and fault tolerance, the exact pitch behind Phoenix, the framework the same 2025 survey ranks as the most admired web framework for three years running.
The Isolated Pockets Where It Did Work
F# was not a failed experiment everywhere. Jet.com, the e-commerce startup Walmart later acquired for 3.3 billion dollars, built its pricing engine and microservices architecture in F# in production, a case its own engineers documented in detail rather than merely mentioned in a slide deck. It worked, it shipped, and it competed at scale. What it did not do was start a wave. A decade later, Jet.com’s F# stack reads as a well-documented exception, not the first domino in an industry shift, and that gap between “it worked here” and “it caught on broadly” is exactly what the survey numbers above are measuring.
| Rust | Elixir | F# | |
|---|---|---|---|
| Core pitch | Memory safety without a garbage collector | Fault-tolerant concurrency on the Erlang VM | Type-safe, concise code on the existing CLR |
| Cost of trying it | New toolchain, new mental model | New runtime, new ops story | None, same solution file |
| 2025 desired | 29.2% | 5.8% | 2.9% |
Consider F# for a .NET shop when
- The team wants stronger immutability and type-safety defaults without leaving the CLR or duplicating infrastructure
- The workload is domain modeling, pricing logic, or data transformation, where F#’s conciseness pays for itself quickly
- Existing CI, package feeds, and hosting can be reused as-is, since a new runtime is not part of the deal
- The hiring pool, not the tooling, is accepted up front as the real constraint on scaling the team
What We Learned
F# had the shortest technical distance to an existing enterprise stack of any modern functional language: same runtime, same packages, same debugger as C#. The 2025 Stack Overflow numbers show that distance did not translate into adoption, F# trails Elixir in usage and trails both Elixir and Rust badly in desire, even though the people who do use it mostly like it. Low friction removes the barrier to trying a language; it does not supply a reason to want to. Rust sells memory safety, Elixir sells fault tolerance, and Microsoft’s own strategy documentation is candid that F# mostly sells “C#, but nicer,” which turns out to be a much harder story to build momentum around than a genuinely different guarantee.
