.NET (OK, C#) finally gets union types

Role of F#, functional languages, and C# catching up

  • Many note F# has had discriminated unions for years; C# is seen as slowly adopting functional features pioneered in F#, Haskell, OCaml, Erlang, Rust, etc.
  • Some argue it’s better to add functional constructs to an already procedural/OO language than vice versa, as this matches the underlying machine model and common developer expectations.

Use cases and benefits of union / sum types

  • Common examples: expression trees / ASTs, domain models like authentication methods, and API responses that can be either success or error.
  • Advocates stress: “make invalid states unrepresentable,” better domain modeling, and avoiding verbose class hierarchies and Visitor patterns.
  • Unions plus pattern matching and exhaustive switches are seen as a fundamental building block for clearer, safer code.

Error handling: Result vs exceptions

  • Many highlight Result/Either unions as a primary use: e.g., APIResponse becoming “T or Error” instead of nullable fields plus flags.
  • Arguments for unions over exceptions: enforce handling via the type system, avoid accidental omission of error handling, and avoid the high runtime cost of exceptions in normal control flow.
  • Skeptics prefer exceptions for separating happy path from error paths and worry about losing that stylistic clarity.

Tagged vs untagged unions and type-system nuances

  • Discussion distinguishes tagged (algebraic) unions in C# from untagged, set-theoretic unions in languages like TypeScript or Scala 3.
  • Debate arises over terminology and whether these are fundamentally different or just implementation/notation variants.

Performance, boxing, and implementation concerns

  • Some are disappointed that the current design always boxes value types, calling it a miss for performance-sensitive code.
  • Others say this is a first iteration; performance and non-boxing patterns may improve later, or can be worked around manually.
  • One commenter cites prior JIT-team resistance to deeply optimizing such features; others are more optimistic about future evolution.

Language complexity, ecosystem, and tooling

  • Mixed feelings: unions are welcomed, but some worry C#’s already-large feature set makes codebases hard to read and team-specific.
  • Several contrast C# with Rust and F#: after using strong ADTs and Options/Results, older C# patterns feel fragile and verbose.
  • Ecosystem complaints include weaker third‑party libraries vs Java (e.g., Kafka, Apache stack, AWS SDKs) and editor/debugger fragmentation, though many still report large .NET deployments, including on Linux, containers, and in game development.