Live data from Hacker News

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

andrewlock.net

281–290 of 300 posts

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

#281
post #259
post #253

Earlier quoted context omitted.

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.

Having reviewed as instructed, I stand by everything I said here. Let's review the action replay.

I began by noting that TS has literals and set theoretic types, and that this makes sense for a post-facto type system bolted on top of a dynamic language. Jaen showed up to inform me that TS has literals and set theoretic types, implying he hadn't read my post.

I noted that typed string literals are not generally considered desirable within strictly typed environments. "Parse, don't validate", etc. Jaen seemed to follow this up by aggressively trying to prove that TS is somehow "better" than Haskell. His arguments comprised the fact that TS has literals and set theoretic types (again, yes, this was is in my initial post), and a mixture of personal insults and just straight up nonsense (I wasn't the one to bring Zod into a discussion of type systems... ). At that point I did have a little fun with things, since it had become clear Jaen was not a constructive or good faith interlocutor.

Jaen's central misapprehensions seem to be that (a) I don't understand literals and set theoretic types, despite this whole thread being in reply to a post where I give examples of them in TS; and (b) that I care which type system is "better".

As I repeated a number of times above, TS' type system makes sense for a type system bolted onto a dynamic language. It's extremely useful when the underlying language has oodles of untyped structs flying every which way. Conversely, Haskell's type system makes sense within a holistic strictly typed environment. Structural typing would be a gaping hole in Haskell's strict type safety, which is kind of Haskell's whole thing. Neither system is better, each has its use. Different strokes for different folks.

I don't usually put much stock in upvotes, but I do note I seem to have the edge there. Seems that our esteemed panel of armchair referees respectfully dissent from your narrative, nvlled. :)

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

#282
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_

About 12 years ago I went to go and work on some legacy C++ software when I was very green. We had a big code base and it had enum Bool { False = 0, True = 1 } everywhere. I thought it was a good idea to rationalise this since we had conversions all over the place to the modern bool type.

So I suggested it, got a PR up (bit painful) it got reviewed, went in, everything worked fine, and we came about a week towards releasing the product (6 monthly releases) before someone noticed that we couldn’t load files from previous versions. Turned out that we wrote lots of these old Bool types to binary data files and so the 4 byte data was now being read as 1 byte data. Oops. Reverted the whole lot. Lesson in humility!

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

#283

Earlier quoted context omitted.

So you try to say that Java gets to be more semantically sound by making bad choices early on? That does not make sense. Those choices are very difficult fix today and many of them can't be fixed. Say what you want but semantically more sound Java won't be. And the boxing with C# unions can and will be addressed later, this was a deliberate choice by the team to bring unions earlier.

> and many of them can't be fixed... And the boxing with C# unions can and will be addressed later No, they won't. C# already got itself into a corner with 32 bit arrays and 32 bit spans. And if unions are introduced as reference only that will never be fixed due to binary compatibility requirement.

The new C# unions are not reference-only. The attribute/interface allows implementing custom union types by writing `TryGetValue`-methods instead of a single `object? Value {get;}`. The compiler handles this transparently.

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

#284
post #171

Earlier quoted context omitted.

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.

Can't think for yourself reading DevBlogs and Github issues?

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

#286
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_

And as always when there is a mix of state and result, i post rop https://fsharpforfunandprofit.com/rop/

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

#287

Earlier quoted context omitted.

I daylight as a .NET dev professionally. I completely agree with what you have wrote, but I do not think C# is particularly unique in that regard. I would say many common compiled languages are on the same path, e.g., Swift, Java, Kotlin, etc.. As time progresses, I am finding it harder to justify using C# for a greenfield project.

> As time progresses, I am finding it harder to justify using C# for a greenfield project. Are you able to elaborate why? Just curious.

GP here.

What I meant is that I try to be pragmatic when writing applications. Most languages solve most problems with relatively minor differences between them.

Of course, some languages excel in areas few or others do not. When it comes to C#, I struggle to justify when it is the “right tool for the right job.” If I were building a game in Unity, C# makes sense as it’s the only option. But if I were to build, I do not know, a FizzBuzz Widget, why use C# over any other language?

The only answer I can usually come up with is language familiarity. My employer’s answer to that question would be, “Because C# is a Microsoft product.”

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

#288

Earlier quoted context omitted.

Not OP here - but for me it’s the open source ecosystem. Java just wins in terms of scope, scale, and stability. I love C# the language, but the ecosystem is a ghetto.

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

Poor reporting libraries, PDF libraries, multiple popular open source projects have randomly gone proprietary (some after a decade+), etc..

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

#289
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;

Yeah it's bad when it's abused, so don't abuse it.

But not having operator overloading when dealing with vectors is maddening.

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

#290
post #245

Earlier quoted context omitted.

Link?

It starts with the experiment, https://github.com/dotnet/runtimelab/issues/2398 Which ended with, > We have chosen to place the green threads experiment on hold and instead keep improving the existing (async/await) model for developing asynchronous code in .NET. This decision is primarily due to concerns about introducing a new programming model. We can likely provide more value to our users by improving the async mo…

Awesome, thank you!

So it's going to be an internal implementation change -- that is, it generates the MSIL code that's generate when a developer writes async/await code, and won't require changes to how a developer writes async/await code?

Post reply on HN