Union types in C# 15 • Hacker News Board

Re: Union types in C# 15

#41

Post by CharlieDigital » Wed, Apr 08, 2026, 1:49 PM UTC

gib444 wrote: post #31

JCTheDenthog wrote: post #22

Earlier quoted context omitted.

Depends on what you mean by ecosystem, it hasn't been trapped on Windows for about a decade now. The variety of third party libraries available is quite good, while the standard library is robust enough that you don't need NPM nonsense like LeftPad and IsEven and IsNumber. Are there particular things about the ecosystem that you worry about (or have heard about)? Biggest complaint I would have is that it seems like m…

Yup, the commercial libraries. That's pretty big. It's nice the standard library has lots of goodies, but I doubt many projects in reality are zero-dependency (The amount of times I hear "the standard lib is great!" seems more to attempt to defend the plethora of commercial libraries, more than anything) The community feels rather insular too? The 9-5 dayjob types with employers who don't understand or embrace open s…

    > And is Postgresql a 2nd-class citizen?

No, it is not.

Microsoft maintains the Npgsql project[0] and I say that it is a very capable, feature rich adapter.

I have not used C# with SQL Server in almost a decade.

[0] https://www.npgsql.org/

Re: Union types in C# 15

#42

Post by algorithmsRcool » Wed, Apr 08, 2026, 1:51 PM UTC

jcmontx wrote: post #34

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

Well off the top of my head...

Active patterns, computation expressions, structural typing, statically resolved type parameters, explicit inlining, function composition, structural equality, custom operators and much richer generators.

Re: Union types in C# 15

#43

Post by Pay08 » Wed, Apr 08, 2026, 1:51 PM UTC

NanoCoaster wrote: post #20

FrustratedMonky wrote: post #11

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

Absolutely agree. Modern C# language design feels very much lacking in vision or direction. It's mostly a bunch of shiny-looking language features being bolted on, all in ways that make the language massively more complex. Just look at this feature: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... Was this needed? Was this necessary ? It's reusing an existing keyword, fine. It's not hard to understand.…

This is why I have always been leery of C# and continued using Java instead. C#s development has always seemed very haphazard and kitchen sink mentality to me.

Re: Union types in C# 15

#44

Post by NanoCoaster » Wed, Apr 08, 2026, 1:54 PM UTC

raincole wrote: post #25

NanoCoaster wrote: post #20

Earlier quoted context omitted.

Absolutely agree. Modern C# language design feels very much lacking in vision or direction. It's mostly a bunch of shiny-looking language features being bolted on, all in ways that make the language massively more complex. Just look at this feature: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... Was this needed? Was this necessary ? It's reusing an existing keyword, fine. It's not hard to understand.…

> Try teaching someone C# nowadays. Completely impossible. Really, I wish they would've given F# just a tenth of the love that C# got over the years If they actually put effort in F#, it would have reached "unteachable" state already :)

Haha, yeah, maybe :)

I would've loved an F# that found a way to improve on the performance issues, especially when using computation expressions. That and, either, a deeper integration of .NETs native OOP subtyping, or some form of OCaml-like module system, would have been enough to make it an almost perfect language for my tastes.

Obviously, these are big, and maybe impossible, issues. But Microsoft as a whole never really dedicated enough resources to find out. I feel for the people still working on it, their work is definitely appreciated :)

Re: Union types in C# 15

#45

Post by twisteriffic » Wed, Apr 08, 2026, 1:55 PM UTC

NanoCoaster wrote: post #20

FrustratedMonky wrote: post #11

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

Absolutely agree. Modern C# language design feels very much lacking in vision or direction. It's mostly a bunch of shiny-looking language features being bolted on, all in ways that make the language massively more complex. Just look at this feature: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... Was this needed? Was this necessary ? It's reusing an existing keyword, fine. It's not hard to understand.…

> Try teaching someone C# nowadays. Completely impossible.

That isn't a reasonable take. Failing to teach a language by enumerating all its features is an indictment of the instructor and not the language.

Re: Union types in C# 15

#46

Post by raincole » Wed, Apr 08, 2026, 1:57 PM UTC

LunicLynx wrote: post #28

NanoCoaster wrote: post #20

Earlier quoted context omitted.

Absolutely agree. Modern C# language design feels very much lacking in vision or direction. It's mostly a bunch of shiny-looking language features being bolted on, all in ways that make the language massively more complex. Just look at this feature: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... Was this needed? Was this necessary ? It's reusing an existing keyword, fine. It's not hard to understand.…

You are looking at it from what you know about C#, the goal is how can you reduce (delete) all this to make the language more accessible. For you it may be fine to write: List strs = new List (); And sure if you have been using C# for years you know all the things going on here. But it shouldn’t be an argument that: List strs = []; Is substentionally easier to grasp. And that has been the theme of all changes. The ex…

> The example you point out is the advanced case, someone only needs in a very specific case

This is exactly how C++ landed where it is now. Every time it's "you only need to know that syntax if..." well it ends up everyone has to know that syntax because someone will use it and if you're a responsible programmer you'll end up reading a lot code written from other people.

Re: Union types in C# 15

#47

Post by xnorswap » Wed, Apr 08, 2026, 1:58 PM UTC

LunicLynx wrote: post #28

NanoCoaster wrote: post #20

Earlier quoted context omitted.

Absolutely agree. Modern C# language design feels very much lacking in vision or direction. It's mostly a bunch of shiny-looking language features being bolted on, all in ways that make the language massively more complex. Just look at this feature: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... Was this needed? Was this necessary ? It's reusing an existing keyword, fine. It's not hard to understand.…

You are looking at it from what you know about C#, the goal is how can you reduce (delete) all this to make the language more accessible. For you it may be fine to write: List strs = new List (); And sure if you have been using C# for years you know all the things going on here. But it shouldn’t be an argument that: List strs = []; Is substentionally easier to grasp. And that has been the theme of all changes. The ex…

That's a basic example with a single level of generics too, you'd sometimes have to do things like:

    Dictionary>> foo = new Dictionary>>

Or things like:

    Dictionary>> foo = DoSomeWork();

And you'd have to get the type right, even though the compiler knew the type, because it'd tell you off for getting it wrong. Sometimes it was easiest to just grab the type from the compiler error. ( This example is of course a bit OTT, and it's a bit of a code-smell to be exposing that detail of typing to consumers. )

No-one wants to go back to that, and anyone who says C# is over-complicated I think is forgetting how rough it was in the earliest versions.

While introduction of auto-typing through "var" helped a lot with that, you'd still regularly have to fight if you wanted to properly initialise arrays with values, because the syntax was just not always obvious.

Collection literals are amazing, and now the ability to pass things into the constructor means they can be used when you need constructor parameters too, that's just a good thing as you say.

Re: Union types in C# 15

#48

Post by kkukshtel » Wed, Apr 08, 2026, 2:01 PM UTC

[flagged]

Re: Union types in C# 15

#49

Post by owlstuffing » Wed, Apr 08, 2026, 2:02 PM UTC

recursive wrote: post #36

jcmontx wrote: post #34

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

Units of measure

F# units are handy, but nothing like Manifold units (Java):

https://github.com/manifold-systems/manifold/tree/master/man...

Re: Union types in C# 15

#50

Post by dathinab » Wed, Apr 08, 2026, 2:05 PM UTC

FrustratedMonky wrote: post #11

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

> big bag of stuff, with no direction.

also called general purpose, general style langue

> that still can't really be done in C#

I would think about it more as them including features other more general purpose languages with a "general" style have adopted then "migrating F# features into C#, as you have mentioned there are major differences between how C# and F# do discriminated sum types.

I.e. it look more like it got inspired by it's competition like e.g. Java (via. sealed interface), Rust (via. enum), TypeScript (via structural typing & literal types) etc.

> Was a functional approach really so 'difficult'?

it was never difficult to use

but it was very different in most aspects

which makes it difficult to push, sell, adapt etc.

that the maybe most wide used functional language (Haskel) has a very bad reputation about being unnecessary complicated and obscure to use with a lot of CS-terminology/pseudo-elitism gate keeping doesn't exactly help. (Also to be clear I'm not saying it has this properties, but it has the reputation, or at least had that reputation for a long time)