.NET (OK, C#) finally gets union types • Hacker News Board

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

#181

Post by bob1029 » Sun, May 24, 2026, 7:10 AM UTC

munchler wrote: post #2

F# leads the way and C# slowly catches up, as always. Yet for some reason, C# still gets all the mindshare.

C# gets all the mindshare because it's easier to understand and use on average.

We can all agree that F# is more clever and concise. No one is dying on that hill. But in terms of hacking your way through the customer requirements and working with a team of other humans, it cannot hold ground in the same way.

There is certainly not some concerted effort or lack of care involved. Microsoft could 10x the marketing budget around F# and the adoption rate probably wouldn't budge.

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

#182

Post by tgv » Sun, May 24, 2026, 7:15 AM UTC

rich_sasha wrote: post #155

LeonB wrote: post #139

Finally C# will have a more idiomatic way to represent this classic code example from “The Daily WTF” in 2005 — enum Bool { True, False, FileNotFound }; See https://thedailywtf.com/articles/what_is_truth_0x3f_

Awful as it is, I can easily imagine how it happened... Probably says more about me than the code.

You're a true Romantic: Idealist and Pragmatist in one.

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

#183

Post by 3plefly » Sun, May 24, 2026, 7:21 AM UTC

Rapzid wrote: post #179

Shame it'll be like 3 years until System.Text.Json sees support for serialization or exporting schemas for them..

[dead]

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

#184

Post by goto11 » Sun, May 24, 2026, 7:35 AM UTC

bertylicious wrote: post #177

bertylicious wrote: post #143

Earlier quoted context omitted.

But you can have an `Either String String` which is what GP was talking about.

My mistake. I see my oversight now. `Either String String` is not equivalent to `String | String`, but to `Left String | Right String`. The same must be done for the C# version.

Yes, you must have individual constructors for the left and right cases in order to distinguish them. In C# you would use two distinct record types for this. Haskell’s syntax is more concise though, since you define the constructors inline in the declaration of the sum type.

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

#185

Post by goto11 » Sun, May 24, 2026, 7:45 AM UTC

kensai wrote: post #108

glimshe wrote: post #31

I love C# and in every iteration we're getting more and more features to get C-like performance in a lot of scenarios. C# does it really well because if your problem isn't performance/memory-constrained, you can ignore these features and fallback on the language's natural ease of use.

Do you think by now C# has left Java behind in features and performance?

C# was always better than Java as a language. The strength of Java is the ecosystem, and Java being open source and cross-platform from the beginning.

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

#186

Post by joe_mwangi » Sun, May 24, 2026, 7:49 AM UTC

paavohtl wrote: post #162

gfody wrote: post #128

Earlier quoted context omitted.

more than 10 years ago, yes

More like 25. C# 1.0 already had capabilities Java developers are still dreaming of, like structs / value types, properties and operator overloading. C# 2.0 in 2005 introduced generics, implemented far more competently than Java ever did.

Notice you point out features that were easy to add during the beginning where there was no concern of backward compatibility? Now that java is porting value classes to mainline and we might have them soon, and planned operator overloading through type class, I believe java approach is making careful design choices that are semantically sound, rather than adding features that create edge cases such as boxing invariants in unions like C#.

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

#187

Post by 369548684892826 » Sun, May 24, 2026, 7:50 AM UTC

jayd16 wrote: post #164

Amekedl wrote: post #127

Earlier quoted context omitted.

Dev tools. The debugger is something for example that Microsoft ostensibly keeps to their own products, and how they totally slaughtered omnisharp. It killed my daily csharp vscode driver couple of years ago, only now catching back up somewhat, but still unusable for bigger solutions. That move made me gravitate towards vscodium, and avoiding csharp where possible. Microsoft's move only recently got more understandab…

If you can use Jetbrains, Rider is on par with IntelliJ. From that perspective, both languages have a best in class debugger.

Rider is very good but this subthread is about the lack of open source dev tooling.

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

#188

Post by jaen » Sun, May 24, 2026, 7:54 AM UTC

troad wrote: post #110

nesarkvechnep wrote: post #24

Earlier quoted context omitted.

I guess C# is more strongly-typed than Haskell then... /s

String literal typing appears to be a common feature of type systems bolted onto dynamic languages: # Python MyStringBool = Literal("Yes") | Literal("No") // TypeScript type MyStringBool = "Yes" | "No" I assume it exists to compensate for the previous lack of typing, and consequent likelihood of ersatz typing via strings. It would seem pretty unnecessary in Haskell, where you can just define whatever types you want w…

String literals are structural types which are way more expressive than regular (Haskell) ADTs, which are nominal types.

In TS in particular, in combination with other features (mapped types), they are equivalent to row polymorphism + whatever Haskell/GHC features enable type families to specialize on constant literal arguments (or you can use atomic types, but that's not structural / open-world)... so pretty advanced.

This is valid TS/Python:

    type ABC = "A" |"B" | "C"
    type AB = "A" | "B"
    const x: AB = "A";
    const y: ABC = x;

The equivalent Haskell requires using several extensions.

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

#189

Post by jaen » Sun, May 24, 2026, 8:05 AM UTC

cubefox wrote: post #88

Most people don't know that there are fundamentally two different kinds of "union" types: "tagged unions" and "untagged unions". Now .NET is introducing tagged unions, but unfortunately they stick to the popular tradition of calling them just "unions", which greatly adds to the confusion. To clarify, these tagged unions are fundamentally different from the untagged unions that can be found in languages like Typescrip…

These are not what are commonly called tagged unions. It's actually closer to an untagged union.

The C# union does not store any discriminator. Just look at the implementation - it's a single `object?` field.

The discriminative part is handled by run-time type information, which is stored in the object itself, not the union - which is why the C# built-in implementation requires boxing.

Also, you can use the same class/record type ("discriminator") in several different unions - again, a feature which ADTs/sum-types/tagged unions in most functional languages do not have.

You can even store one single object (ie. identical by reference equality) in several different union values at the same time, theoretically, which in combination with mutability is... uhh, certainly not common functional/mathematical semantics.

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

#190

Post by 8n4vidtmkvmk » Sun, May 24, 2026, 8:18 AM UTC

t-writescode wrote: post #178

LeonB wrote: post #139

Finally C# will have a more idiomatic way to represent this classic code example from “The Daily WTF” in 2005 — enum Bool { True, False, FileNotFound }; See https://thedailywtf.com/articles/what_is_truth_0x3f_

What about Microsoft's own "MsoTrioState"? https://learn.microsoft.com/en-us/dotnet/api/microsoft.offic... enom MsoTrioState { Toggle, Mixed, True, False, CTrue };

Is it called "trio" state because 3 of the 5 states are not supported?

I also like how True is -1. Beautiful all around!