Live data from Hacker News

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

andrewlock.net

201–210 of 300 posts

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

#201
post #108
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?

Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.

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

#202

Earlier quoted context omitted.

Rust and Zig brought new ideas for memory management that Haskell, OCaml, Erlang sidestep having garbage control. its honestly amazing to me that they managed to get the adoption they have while being so innovative. I say this as a fulltime elixir dev.

What new ideas did Zig bring to memory management?

Pluggable allocators. Allocators are passed to functions as arguments, the caller decides exactly how memory is managed. Maybe not "new" in idea, but "new" in being consistently applied everywhere in language & libraries.

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

#203

Earlier quoted context omitted.

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!

note CTrue, the one true true

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

#204
post #174

Earlier quoted context omitted.

> But no one is actually confused. Wrong, see this comment: https://news.ycombinator.com/item?id=48251896 Clearly he thought that it's the same kind of union as in TypeScript and that in C# just the syntax is weird. Which is not the case. Some others who are not commenting are probably also not aware of the two kinds of union types (or three, counting C separately). > It's neither ambiguous nor confusing to use the w…

I see no evidence the user is confused, they said they wished the syntax were similar to TS. Though they're not the same thing, they do have comparable uses, so it makes sense to wish for similar syntax to reduce cognitive overhead. > Well, we disagree. Most people here know the set theory definition of unions. It's simply a niche use, compared to the usual CS definition, which is the one used in the original article…

> they do have comparable uses, so it makes sense to wish for similar syntax to reduce cognitive overhead

No this makes no sense at all. Set theoretic types don't use special constructors, there is no way to make them look remotely similar. He is clearly not aware that these are different kinds of unions.

> They do.

Nope, precisely because they are less common. You yourself also clearly also didn't understand the difference between "untagged unions" in C and set theoretic type systems.

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

#205
post #185

Earlier quoted context omitted.

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.

Java wasn’t open source at all from the beginning.

And the binaries, the default sdk when using java, i.e. oracle jdk, is still not open source, encumbered with a mine field of legalese. For a long time it also included malware as ask toolbar. Stay away.

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

#206
post #108

Earlier quoted context omitted.

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

Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.

Clearly legacy heavy weight threads, virtual or not, are not superior. That’s why Swift, Rust and Typescript all chose async/await for concurrency.

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

#207

Earlier quoted context omitted.

Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.

Clearly legacy heavy weight threads, virtual or not, are not superior. That’s why Swift, Rust and Typescript all chose async/await for concurrency.

We are not taking about legacy heavy weight OS/platform threads. But "green" threads managed by the language runtime like Go. Java went the Go/Erlang way.

https://javapro.io/2026/03/05/java-25-and-the-new-age-of-per...

https://docs.oracle.com/en/java/javase/26/core/virtual-threa...

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

#209
post #195
post #188

Earlier quoted context omitted.

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 advance…

I know. I literally gave the example of a Python Literal in the post you're replying to. TS too. :) My overall point is that Haskell's type system is sufficiently expressive (you may not have "A" | "B" | "C", but you do have A | B | C) that there's no obvious remaining use case for string literals, unless you're thinking of typing input by way of expected literals instead of actually parsing it, which is... a choice.…

By Haskell's type system do you mean with all the GHC extensions?

Because TypeScript has structural sub-typing, while standard Haskell (eg. `A | B | C`) has neither subtyping nor structural typing, which both are very useful features for safe "integration/glue" type of programs.

(String) literals form a fundamental part of the TS "row polymorphism" (record types) and eg. tuple union type implementation.

You can type a non-empty array that starts with zero...

    type Arr = [0, ...number[]];
    const a: Arr = [0, 1, 2, 3, 4]
Now try in Haskell.

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

#210
post #185

Earlier quoted context omitted.

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.

Java wasn’t open source at all from the beginning.

No, but it was free/gratis distributed on almost every developer magazine shipping with CDs.

One of the reasons why it took off.

Post reply on HN