Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

andrewlock.net

Post reply on HN
Print view View original

171–180 of 300 posts

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

#171

Post by pjmlp »

munchler wrote: post #2

F# leads the way and C# slowly catches up, as always. Yet for some reason, C# still gets all the mindshare.

Microsoft management has decided CLR has a new meaning, C# Language Runtime.

VB, C++/CLI and F# are only there because existing customers.

They have always behaved as if it had been a mistake to promote F# from research project into VS 2010 as an official language.

Since then it has been something that the teams never knew how to sell to the .NET customer base, pivoting from being only libraries for C# and VB, write unit tests, Web development, data analysis, whatever might make it.

However it was Standard ML, Miranda, Hope, OCaml and Haskell that lead the way, we aren't still fully there.

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

#172

Post by pjmlp »

cultofmetatron wrote: post #38
correct_horse wrote: post #29

Earlier quoted context omitted.

Haskell, OCaml, Erlang lead the way and Rust, Zig and Go get all the mindshare. I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.

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.

Zig is Modula-2, Ada 83 with a curly brackets, what new ideas?

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

#173

Post by itishappy »

Quarrelsome wrote: post #119
itishappy wrote: post #101

Earlier quoted context omitted.

The Result pattern can be a lot more ergonomic than exceptions. Microsoft C# guidelines recommend try-parse (which is just the Result pattern, albeit somewhat cludgy with no unions) over exceptions. https://learn.microsoft.com/en-us/dotnet/standard/design-gui...

the result pattern doesn't force you to handle the exception though. You can just discard the result.

A function that returns `Result` is not a `T` and cannot be implicitly converted to one. If you want to use that `T`, the only way is writing code that drops or handles the `E`. If you don't, your program does not compile.

Compare this to exceptions, where the type is just `T` and can be used without further ceremony. You can discard the error by forgetting a handler. Now you have a program that occasionally crashes.

Follow-up: Are there async exceptions? A `Result` is just data that can be awaited. How would that work with exceptions?

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

#174

Post by troad »

cubefox wrote: post #166
troad wrote: post #153

Earlier quoted context omitted.

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

> 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 and now all the comments.

You're swimming upstream with a definition that doesn't reflect what is under discussion, which you decreed as though from on high, complete with the assertion that most people don't understand unions like you do. They do.

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

#175

Post by hvb2 »

correct_horse wrote: post #29
munchler wrote: post #2

F# leads the way and C# slowly catches up, as always. Yet for some reason, C# still gets all the mindshare.

Haskell, OCaml, Erlang lead the way and Rust, Zig and Go get all the mindshare. I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.

> I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.

You're ignoring the fact that it's harder to bring new features to older languages as they have more bloat to deal with as not every idea turns into a success. So younger more focused languages can iterate more quickly. Also, being willing to make breaking changes makes things easier. Microsoft tries hard not to do that with C#.

Over time, maintaining any software becomes harder, languages are no exception. The fact that c# is still around, and still being developed is a feat in itself

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

#176

Post by ikekkdcjkfke »

Quarrelsome wrote: post #32
Sharlin wrote: post #23

Earlier quoted context omitted.

Discriminated union types are a really fundamental building block of a type system. It's a sad state of matters that many mainstream languages don't have them.

ok, so what problems do they help me solve that I can't already solve? Is it just that we can make code more concise or am I missing a trick somewhere?

make the compiler check more stuff, helpful when expanding or refactoring

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

#177

Post by bertylicious »

bertylicious wrote: post #143
goto11 wrote: post #100

Earlier quoted context omitted.

You cant have a `type Foo = String | Strimg` in Haskell either.

But you can have an `Either String String` which is what GP was talking about.

My mistake. I see my oversight now. `Either String String` is not equivalent to `String | String`, but to `Left String | Right String`. The same must be done for the C# version.

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

#178

Post by t-writescode »

LeonB wrote: 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_

What about Microsoft's own "MsoTrioState"? https://learn.microsoft.com/en-us/dotnet/api/microsoft.offic...

  enom MsoTrioState {
    Toggle,
    Mixed,
    True,
    False,
    CTrue
  };

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

#180

Post by bertylicious »

jafffsuds wrote: post #157
bertylicious wrote: post #142

Earlier quoted context omitted.

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.

My mistake. I see my oversight now. `Either String String` is not equivalent to `String | String`, but to `Left String | Right String`. The same must be done for the C# version.

You are correct that this requires support for disjoint unions (aka tagged unions), which Haskell always had and C# will soon have.

Post reply on HN