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

291–300 of 300 posts

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

#291

Post by Rohansi »

aksss wrote: post #160
Rohansi wrote: post #91

Earlier quoted context omitted.

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

I agree but there are people out there who are productive enough without a full IDE. Or it just suits their use case.

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

#293

Post by jaen »

troad wrote: post #281
nvlled wrote: post #259

Earlier quoted context omitted.

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

You seem to be aggressively misreading what I said, stuck in your own "world" and instead of asking for clarifying questions, making unfounded assumptions.

> I began by noting that TS has literals and set theoretic types

Can you please quote me exactly the part of your original comment that implies that literal types are structural and have subtyping? Because that is what I said. If you did imply that, well, excuse me for helping you by clarifying then.

> aggressively trying to prove that TS is somehow "better" than Haskell

Sorry, what? Refer to the first line of this comment. Just saying that some type system features are extensions or harder to use in Haskell says nothing about the superiority of TS. This is completely your imagination.

Here's me criticizing TS 4 months ago: https://news.ycombinator.com/item?id=46501061

> I wasn't the one to bring Zod into a discussion of type systems...

Not sure why this is even relevant, but this was a direct reply to: "...language like TS, which is not type safe at runtime, and which will happily ingest an unexpected value, silently coerce it in all sorts of fun and wacky ways"

Zod (just a random library) is a direct counter-example to that. There may be better counter-examples. One just needs a proof of existence - it doesn't have to be good.

I then had to repeat that I am also talking about static types because of: "...exhaustive runtime schema for your zero-first non-empty integer array example...". TS can both enforce that as a type (which you never presented for Haskell) and as a value. (nominally typed solutions quickly run into ergonomic problems like phantom types not being composable across library boundaries - eg. refinement types, which are even safer by nature, are structural!)

In any case, I'd estimate 99% of people using TS don't encounter any type safety issues caused by the design of TS. Haskell has `unsafeCoerce` too, just a bit wordier than in TS.

If wanting to talk about real unsoundness, one would mention something like bivariance (see also: linked comment), but even then almost all of that is entirely irrelevant in most practical software engineering.

> (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".

Huh, what? Again, I'm thinking none of that. Again, you imply you know better what I'm thinking...

> Structural typing would be a gaping hole in Haskell's strict type safety

I mean, yeah, let me just repeat OCaml and Scala here, both also famously type safe languages... Why make an argument when there's two immediate counterexamples that were already mentioned?

> but I do note I seem to have the edge there

This pretty much sums up the difference in attitude, I'm not here to score internet points in an argument.

I just wanted to comment on why the world is not black and white and even technically flawed languages like TS have something to learn from.

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

#294

Post by moomin »

Metasyntactic wrote: post #199
moomin wrote: post #5

AFAICT, this means you won’t be able to define Either , which is definitely a thing you sometimes want to do.

Hi there. One of the C# lang designers here. You're correct. The unions we're working on right now are 'type unions'. So the type is inherent in the union distinction, and you would not be able to distinguish that case. That said, we're also looking at full blown discriminated unions (you can look at one of my proposals for that here: https://github.com/dotnet/csharplang/blob/main/meetings/work... ), which would allo…

Thank you! Even what’s there is going to be really useful to me but I’ll continue to look forward to a full-fat implementation.

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

#295

Post by [deleted] »

jaen wrote: post #293
troad wrote: post #281

Earlier quoted context omitted.

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

You seem to be aggressively misreading what I said, stuck in your own "world" and instead of asking for clarifying questions, making unfounded assumptions. > I began by noting that TS has literals and set theoretic types Can you please quote me exactly the part of your original comment that implies that literal types are structural and have subtyping? Because that is what I said. If you did imply that, well, excuse m…

[deleted]

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

#296

Post by pjmlp »

Metasyntactic wrote: post #197
ComputerGuru wrote: post #156

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…

It would help if generators usability and related docs would be improved, though.

They still feel like something only .NET team masters, and a few MVPs that wrote key reference blog posts about them.

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

#297

Post by throw1234567891 »

eterm wrote: post #49
throw1234567891 wrote: post #12

Earlier quoted context omitted.

but can you define T1 and T2 of string, then use Either ?

Could you be clearer about what you mean, since string is a sealed type in C#, so what exactly do you mean T1 and T2 of string?

    type T1 string
    type T2 string
    type Meh Either

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

#298

Post by dale_glass »

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!

Apparently it's sort of sensible, but weird.

msoTriStateMixed applies to aggregates. Eg, text.isBold() can be true, false, or a mix. Partly bold, partly not bold.

msoTriStateToggle isn't a real value but only used as a sort of flag. So eg, text.setBold(tristate), where "Mixed" would be invalid, and "Toggle" would flip the bold-ness of the text.

The msoCTrue one is where it gets really weird, no clue what's that for. I suppose an ill-conceived attempt to support the other way to express True.

True being -1 was a thing in Visual Basic and I suppose by some other Windows stuff. Logic being all the bits are 1.

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

#299

Post by biglyburrito »

joe_mwangi wrote: post #274
biglyburrito wrote: post #231

Earlier quoted context omitted.

Speaking as somebody that spent 2yrs as a full-time Java dev before returning to the Microsoft stack: yes. Java’s Optional sucks compared to how C# (and Kotlin) implement support for nullable types. C#’s async/await syntax is better than… however the hell Java says to implement asynchronous calls now (Thread? CompletableFuture? idk, I never figured it out). ffs, Java doesn’t even have support for string templates yet…

Damn. You're old school. Java’s answer is virtual threads, not async/await. The idea is that most server-side IO can stay in direct style enabling blocking-looking code, cheap virtual threads underneath. So you don’t split the whole codebase into sync vs async functions just to avoid blocking OS threads. CompletableFuture and reactive APIs still exist, but Loom reduces the need to use them as the default application…

Not so much old school as I was new to JDK, there was no prior art anywhere in our codebase that implemented async (somehow, in 2022), and we started off with JDK 8 (I helped upgrade everything to JDK 17). I REALLY TRIED, OK!?

Even when I was building stuff in Kotlin, I couldn't figure out how to make async -- coroutines? RX? I forget already -- work, either. But that was all in the last few months before I left & moved back to the .NET stack.

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

#300

Post by stevefan1999 »

pjmlp wrote: post #167
paavohtl wrote: post #162

Earlier quoted context omitted.

More like 25. C# 1.0 already had capabilities Java developers are still dreaming of, like structs / value types, properties and operator overloading. C# 2.0 in 2005 introduced generics, implemented far more competently than Java ever did.

The difference is BDFL or design by committee, a big difference between both ecosystems.

Well, what's the difference between a (benefactory or not) dictator or an oligarch?
Post reply on HN