Hmm, they seem to have chosen to avoid names to the choices in the union, joining C++ variants and (sort of) TypeScript unions: unions are effectively just defined by a collection of types.

Other languages have unions with named choices, where each name selects a type and the types are not necessarily all different. Rust, Haskell, Lean4, and even plain C unions are in this category (although plain C unions are not discriminated at all, so they’re not nearly as convenient).

I personally much prefer the latter design.

I don't love OneOrMore<T>

It's trying to generalize - we might have exactly one T, fine, or a collection of T, and that's more T... except no, the collection might be zero of them, not at least one and so our type is really "OneOrMoreOrNone" and wow, that's just maybe some T.

I haven't read this in detail but I expect it to be the same kind of sealed type that many other languages have. It doesn't cover ad-hoc unions (on the fly from existing types) that are possible in F# (and not many non-FP languages with TypeScript being the most notable that does).

Sad part is, is that ad hoc unions probably won’t make it into v1. That is probably one of the only feature why I like typescript. Because I can write result types in a good way without creating thousands of sub types. It’s even more important when using Promises and not having checked exceptions.

Looks like it's "just" type-erasure / syntactical sugar. E.g. value types are boxed.

So they finally took all of the cool features from F#. What's missing? The pipe operator for railway oriented programming?

I love it, but I see a downside, though: unions are currently implemented as structs that box value types into a Value property of type object. So there can be performance implications for hot paths.

It's very disappointing that they aren't supporting Rust-style discriminated unions.

This is HUGE! Now we can use mostly functional programming in C#. This feature was requested since many years ago.

The only thing I wish now is for someone to build a functional Web framework for C#.

Is this the last of the F# features to be migrated into C#?

What a missed opportunity. I think really F# if you combine all of its features, and what it left out, was the way. Pulling them all into C# just makes C# seem like a big bag of stuff, with no direction.

F#'s features, and also what it did not included, gave it a style and 'terseness', that still can't really be done in C#.

I don't really get it. Was a functional approach really so 'difficult'? That it didn't continue to grow and takeover.

#define struct union

Is C# a great language trapped in a terrible ecosystem? ie would masses use C# if it existed in another ecosystem?

Or is it becoming a ball-of-mud/bad language compared to its contemporaries?

(Honest questions. I have never used .NET much. I'm curious)