Live data from Hacker News

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

andrewlock.net

251–260 of 300 posts

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

#251
post #250

Earlier quoted context omitted.

Language design isn't just about adding every possible feature. For example, someone mentioned operator overloading. As someone who has written a lot of Scala, I think operator overloading would be a very bad feature for an enterprise language like Java which needs to be consistent above all else. I never understood the obsession some people have with the C# vs Java debate anyway. Generally, both languages are very g…

> I think operator overloading would be a very bad feature for an enterprise language like Java which needs to be consistent above all else. Operator overloading increases consistency. Instead of having int a = b + c; CustomNumberType x = y.add(z); you have int a = b + c; CustomNumberType x = y + z;

The problem with operator overloading is it makes things confusing when mixing types and let's programmers write confusing code.

    Person x;
    Job y;
    CustomType z = x + y;
WTF is Z?

Is the argument, anyway, I support operator overloading.

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

#252
post #2

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

C# gets all the mindshare because it's easier to understand and use on average. We can all agree that F# is more clever and concise. No one is dying on that hill. But in terms of hacking your way through the customer requirements and working with a team of other humans, it cannot hold ground in the same way. There is certainly not some concerted effort or lack of care involved. Microsoft could 10x the marketing budge…

I hate the trend of measuring “easy to understand” based on how superficially similar the language is to C/Java.

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

#253
post #248
post #244

Earlier quoted context omitted.

Haha, I knew you'd bring up Go. I even considered pre-emptively dropping Rust and Zig as counterexamples. I think most people who favour static typing consider the duck-typed interfaces of Go to be a mistake. Personally, I consider all of Go to be a mistake. > these type system features were added by multiple experienced language designers for a reason Oooh, an appeal to authority, where that authority isn't even nam…

Yeah, you're just continuing to take whatever was written argumentatively/maliciously as predicted. Does not seem like this: > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. > Personally, I consider all of Go to be a mistake. You also consider Scala and OCaml to be mistakes? Because all of what I've mentioned also works in…

I believe I was promised a respite from this.

Everything I said to you prior to my last message was fairly gentle. I'm not sure what response you were expecting to what you wrote at that point, which was to accuse me of disingenuous strawman arguments and ignorance. Perhaps you yourself would have benefited from a rule refresher?

> You seem to know what I'm doing better than I am

Apparently so! Trust me, it gives me no pleasure, and I'd rather I didn't.

> Again, I wasn't talking about runtime schemas, but types. I only mentioned runtime as a counterpoint to the false statement that TypeScript doesn't enforce this. Only reducing this to runtime checking is a fallacy, again.

My dear friend, this is almost completely incoherent.

I wish to strictly type myself as a function at this point, whereby your messages are my input, and void is my output. Zod, activate!

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

#254

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

Not quite, as the compiler wouldnt let let you use the "value" in that case. So if you discard the error path, you simply wont have any value to use further on in the code.

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

#255
post #171
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…

> Microsoft management has decided CLR has a new meaning, C# Language Runtime. > VB, C++/CLI and F# are only there because existing customers.

Oh, I think we need a citation for these claims.

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

#257

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.

You would be surprised to see, how OCaml and the BEAM specifically think about memory.

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

#258
post #2

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

C# gets all the mindshare because it's easier to understand and use on average. We can all agree that F# is more clever and concise. No one is dying on that hill. But in terms of hacking your way through the customer requirements and working with a team of other humans, it cannot hold ground in the same way. There is certainly not some concerted effort or lack of care involved. Microsoft could 10x the marketing budge…

That is entirely anecdotal and based on subjective interpretation of someone, who has worked in C like languages or something similar:

This is just about how you are used to it, it says nothing about the quality of the language itself.

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

#259
post #253
post #248

Earlier quoted context omitted.

Yeah, you're just continuing to take whatever was written argumentatively/maliciously as predicted. Does not seem like this: > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. > Personally, I consider all of Go to be a mistake. You also consider Scala and OCaml to be mistakes? Because all of what I've mentioned also works in…

I believe I was promised a respite from this. Everything I said to you prior to my last message was fairly gentle. I'm not sure what response you were expecting to what you wrote at that point, which was to accuse me of disingenuous strawman arguments and ignorance. Perhaps you yourself would have benefited from a rule refresher? > You seem to know what I'm doing better than I am Apparently so! Trust me, it gives me…

I would say, with a striped-shirt and not a glove in my hand, that the person you were fighting with gets the score, and wins by technicality. I suggest you take the bench first and review your comments and reflect with a wet towel on your head.

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

#260

Why would the default language-level union keyword implementation force boxing? Seems like a crazy decision if it could just also implement the HasValue/TryGet itself and avoid it?

Hi there! C# language designer here, and one of the people working on unions. Boxing is not something inherently to be avoided. It actually can work better in many (most?) use cases, and avoids a lot of problems that non-boxing approaches often cause (like tearing and copy costs). It's try that the non boxing pattern could be implemented by us. And it's very reasonable that that is something we may do post this relea…

Can we expect that the C# development team works with the F# crowd, to make this copied feature work on both?
Post reply on HN