Why F#?

General sentiment & appeal

• Many commenters describe F# as one of the few languages that fundamentally changed how they think about programming; users tend to be unusually enthusiastic.
• Praised for concise, readable syntax, expression-oriented design, immutability-by-default, and “pit of success” feel once you get over the initial learning curve.
• Some see it as “corporate‑friendly ML”: a practical functional language with escape hatches, not academic purity.

F# vs C# and other languages

• C# has adopted many F#-style features (records, pattern matching, lambdas, async composition, optional types), narrowing the gap; some argue this diminishes F#’s niche.
• Others insist the whole of F# (expression-based, pervasive immutability, unions, pipelines) is more than the sum of features C# has copied, and gives a different way of structuring programs.
• Discriminated unions and better null-safety are repeatedly cited as F#’s “killer features” still missing from C#.
• Comparisons appear with Scala, OCaml, Haskell, Elixir, Gleam, Rust, Clojure, and Ruby; F# is seen as simpler than Scala/Java stack, more strongly typed than Elixir, and easier than Haskell/OCaml for many.

Type system, pipelines & type providers

• Strong static typing with full type inference is a core attraction; many like how the compiler enforces correctness across complex refactorings.
• Pipeline operator (|>) and function composition are highlighted as changing how people write and reason about code.
• Type providers are viewed as both a standout innovation (schema-driven, type-safe access to CSV, DBs, configs) and a source of brittleness and operational complexity (compile-time dependence on external systems).

Async, computation expressions & performance

• Computation expressions (async, task, custom CEs) are praised as a powerful generalized version of async/await and other monadic patterns.
• There’s some confusion and criticism around older async vs task interop; newer guidance is to use task {} for better integration with .NET.
• At least one commenter finds F# slower than C# for performance‑critical work; others focus more on clarity and safety than raw speed.

Tooling, build system & ecosystem

• Tooling is described as historically rough but now “good enough”: Visual Studio (Windows), Rider, and VS Code + Ionide are common setups.
• Some still complain about slower compilation, lack of hot reload, and awkwardness compared to mainstream C# tooling.
• Being a .NET language is seen as both strength (huge library ecosystem, GUI/mobile/web options, interop with C#) and weakness (MS distrust, “C# baggage”, many docs/examples only in C#).

Use cases, workflows & interop

• Strong fits mentioned: backend data processing and parsing, CRUD/business-domain modeling, domain‑heavy logic with rich types, CSV/data wrangling with type providers, and full‑stack via Fable/Elmish or WebSharper.
• Common pattern: “functional core, imperative shell” — write domain logic in F#, keep ASP.NET / GUI / DI-heavy code in C#.
• Some teams report successful all‑F# shops, including a sizeable (~80‑person) company and commercial SaaS products.

Adoption, hiring & careers

• Major practical downsides: small community, few job postings, difficulty hiring experienced F# developers, and the perception of being a .NET second‑class citizen.
• Several people like F# but avoid it professionally because investing in C#/Java/TypeScript/Rust pays off more in the job market.
• Others treat F# (and similar languages) as a “learning and hobby tool” that still improves how they write code in mainstream languages.