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?
.NET (OK, C#) finally gets union types
201–210 of 300 posts
Re: .NET (OK, C#) finally gets union types
#202Earlier 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?
Re: .NET (OK, C#) finally gets union types
#203Earlier 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!
Re: .NET (OK, C#) finally gets union types
#204Earlier 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…
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
#205Earlier 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.
Re: .NET (OK, C#) finally gets union types
#206Earlier 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.
Re: .NET (OK, C#) finally gets union types
#207Earlier 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.
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
#208Re: .NET (OK, C#) finally gets union types
#209Earlier 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.…
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
#210Earlier 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.
One of the reasons why it took off.