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

211–220 of 300 posts

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

#211

Post by Quarrelsome »

zoogeny wrote: post #67
Quarrelsome wrote: post #62

Earlier quoted context omitted.

I can already do functional programming like map/reduce in C# tho. Not sure what the LISP argument is. Spolsky was saying there's a perf benefit in there somewhere but I'm not seeing how unions give me that.

You have at least two options: 1. Argue from ignorance. Never try unions in any other programming languages and completely disallow their use in C# codebases that you participate in. 2. Try them out and adopt an informed opinion. You may even choose to remain in ignorance until someone wastes their own time trying to convince you. But it isn't my job or desire to teach someone who won't put in the effort to learn for…

its not your job to comment spitty replies either but yet you volunteer that time, when you could have been productive instead of whatever the fuck this shit is.

My primary concern with this pattern versus exceptions is calling code can simply discard the resulting problem.

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

#212

Post by Quarrelsome »

Akronymus wrote: post #89
Quarrelsome wrote: post #57

Earlier quoted context omitted.

I think I get it but I'm not really sure what I'm gaining over exception types. With an intelligent use of exceptions I can easily specify the happy path and all the error paths separately which seems really nice to me, because usually the behaviour between those two outcomes is rather different.

> I think I get it but I'm not really sure what I'm gaining over exception types. With an intelligent use of exceptions I can easily specify the happy path and all the error paths separately which seems really nice to me, ... Until your coworker comes along and accidentally refactors the code to skip the exception catching and it suddenly blows up prod. With tagged unions you can't accidentally dereference to the und…

> Until your coworker comes along and accidentally refactors the code to skip the exception catching and it suddenly blows up prod.

can't my co-worker just use this pattern and discard an error result the same? I'd argue its easier as the stack wont unwind by default because the error is returned instead of thrown.

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

#213

Post by pjmlp »

goto11 wrote: post #185
kensai wrote: post #108

Earlier quoted context omitted.

Do you think by now C# has left Java behind in features and performance?

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.

To the point that after all the drama with J++ that lead to .NET and C# development, Microsoft nowadays is also an OpenJDK contributor with their own distributions, and official developer advocacy channels on YouTube, conferences and devblogs.

Turns out they really want to have plenty of Java development on Azure as well.

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

#214

Post by Quarrelsome »

JCTheDenthog wrote: post #76
Quarrelsome wrote: post #57

Earlier quoted context omitted.

I think I get it but I'm not really sure what I'm gaining over exception types. With an intelligent use of exceptions I can easily specify the happy path and all the error paths separately which seems really nice to me, because usually the behaviour between those two outcomes is rather different.

Exceptions are significantly slower than normal control flow in C# (about 10,000 times slower). It's also pretty non-idiomatic in both C# and most other languages I've worked in to use exceptions instead of a switch statement or similar to handle an HTTP error code. Also there can be multiple possible non-error responses from an endpoint you need to differentiate between, and exceptions would make zero sense in that…

> Also there can be multiple possible non-error responses from an endpoint you need to differentiate between

Yeah, I'm mildly sold on this use-case to be fair. But I think I'll keep the unexpected errors as exceptions.

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

#215

Post by pjmlp »

hackerqwe wrote: post #206
lenkite wrote: post #201

Earlier 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.

Except one of the milestones for .NET 11 is to offer similar mechanisms for async/await.

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

#216

Post by Quarrelsome »

rspeele wrote: post #120
Quarrelsome wrote: post #32

Earlier quoted context omitted.

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?

Object-oriented polymorphism (interfaces, inheritance) is for when you have a fixed set of methods to implement but an unbounded set of types that may want to implement them. As a consumer, you cannot change the methods, but you can add a subtype. When you subtype an abstract class or an interface, the compiler does not let you proceed until you have implemented all the methods . Discriminated unions are for the exac…

thank you so much, that's extremely helpful <3.

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

#217

Post by orthoxerox »

8n4vidtmkvmk wrote: post #190
t-writescode wrote: post #178

Earlier 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!

-1 means every single bit is 1, the truest possible value.

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

#218

Post by pjmlp »

lenkite wrote: post #202
unclad5968 wrote: post #137

Earlier quoted context omitted.

What new ideas did Zig bring to memory management?

Pluggable allocators. Allocators are passed to functions as arguments, the caller decides exactly how memory is managed. Maybe not "new" in idea, but "new" in being consistently applied everywhere in language & libraries.

Already Turbo Pascal for MS-DOS had a custom allocator API for its runtime.

All modern C++ collection types have allocators as type parameters, and this was already a thing in the compiler frameworks like OWL during the 90's.

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

#220

Post by drdaeman »

t-writescode wrote: post #178
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 };

Usual reminder that one of the hardest problems in software engineering is still naming things ;-)
Post reply on HN