Live data from Hacker News

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

andrewlock.net

151–160 of 300 posts

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

#151
post #43

Earlier quoted context omitted.

I love discriminated unions. The problem with C# is that it’s so overloaded with features. If you come from one codebase to another codebase by a different team it’s close to learning a completely new language, but worse, there is no documentation I can find that will teach me only about that language. Throw in all the versioning issues and the fact that .Net shops aren’t great about updating to the latest versions,…

I am all for minimalism but "If you come from one codebase to another codebase by a different team it’s close to learning a completely new language" I really don't agree. It's not that big. Just sounds like a skill issue

Sure. Maybe it was a skill Issue.

I switched between dozens of similar codebases over a period of 3-4 years (pre AI) when I was consulting and did multiple projects in multiple languages (well, only 1 in rust).

In my experience switching between the C# projects was always the worst. The codebase semantics diverged in ways I simply didn’t see in the Java/C++ codebases.

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

#152

Earlier quoted context omitted.

I see this reason a lot but what are some actual examples of what is lacking in the .NET ecosystem vs. Java?

Large Apache ecosystem (Spark, Flink, Pinot) is completely missing and third-party SDKS (looking at you AWS) almost ALWAYS have worse SDKs. The java Kinesis consumer and producer libraries are amazing, the ones for C# are simple wrappers around the AWS APIs which means there's a few foot guns waiting for developers to run into, even if they should know better.

Good point. The majority of Apache projects are Java. Amazon is also mostly Java internally.

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

#153
post #146

Earlier quoted context omitted.

> Maybe they are implemented similarly under the hood It's hard to know what to say to this. Tagged unions are not tagged unions, even if they are literal tagged unions? What? I reiterate what I said in my previous comment, you're not using the ordinary definition of the term union, and this is causing confusion. A union may or may not be a "union" as understood within various academic type theories, that really depe…

See my edit above. There is the C terminology, and the TypeScript et al terminology, and it's the same "untagged" terminology for two different things. In any case, both these kinds of "untagged" unions are different from tagged/discriminated unions. So just calling them "unions" is ambiguous at best and confusing at worst.

But no one is actually confused. You yourself understand what the author meant, from your comments. Everyone here understands what he meant.

It's neither ambiguous nor confusing to use the word union in CS. The only person who's making it so is you, by introducing semi-unrelated concepts from set theory that happen to have the same name as the established CS concept.

Why stop there? Maybe the author meant the Union, as in the United States? Itself quite ambiguous - does he mean the United States of Mexico, or the United States of the Ionian Islands? Is C# getting Corfu? Corfu dot net? :P

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

#154

I mean yes, but also: uh-oh. I'm looking forward to reading some code that is even more confusing than the code I'm already reading. Not entirely convinced that I see the usecase that makes up for the potential madness.

Have you considered trying them out (maybe in F#) to understand why they are so popular in many other languages?

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

#155
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.

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

#157
post #92

Earlier quoted context omitted.

Well it is a type union. The union of string and string is just string.

No, it's a union of a left value (that happens to be a string) and a right value (that happens to be a string). But the compiler-generated code can't tell them apart.

What you are describing is something different called a disjoint union which will maintain the identities of the left and right values when there is overlap.

The C# unions appear to behave like unions, not disjoint unions.

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

#160
post #91
post #55

Earlier quoted context omitted.

Rider is the replacement, unless they are doing really specific (like WinUI2/UWP)

VS Code is also manageable. Or the CLI tools, if that's your thing. Rider is definitely the most equivalent to full Visual Studio though.

I don’t think VS Code is remotely a replacement for VS/Rider. I use VS Code for a lot of things but for large and complex project sets the automation and features in VS are luxuries you really miss. It’s like going back to the Stone Age to use VS Code in those contexts. Trying to fill the voids in VS Code with extensions makes VS Code very brittle. VS Code has its lane but I think they are different tools suited to very different jobs.
Post reply on HN