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

191–200 of 300 posts

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

#191

Post by mrsmrtss »

le-mark wrote: post #8

I used to see some excitement around .net core several years ago. I haven’t heard or seen much in the wild. Is anyone using .net on systems other than windows nowadays?

For almost 10 years now, we have not published anything .NET to the Windows platform. .NET is more performant on Linux today than Windows, and I would say development is also better there (using Rider). However, we do still have devs who prefer Windows. We have built many critical systems on .NET and they just work, so they may be boring to some of the folks who like to have more excitement from their systems.

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

#192

Post by mrsmrtss »

joe_mwangi wrote: post #186
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.

Notice you point out features that were easy to add during the beginning where there was no concern of backward compatibility? Now that java is porting value classes to mainline and we might have them soon, and planned operator overloading through type class, I believe java approach is making careful design choices that are semantically sound, rather than adding features that create edge cases such as boxing invarian…

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.

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

#193

Post by JohannesH »

Rohansi wrote: post #117
antonymoose wrote: post #114

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?

A good built-in/open xslt3 processor.

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

#194

Post by littlecranky67 »

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.

Java wasn’t open source at all from the beginning.

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

#195

Post by troad »

jaen wrote: post #188
troad wrote: post #110

Earlier quoted context omitted.

String literal typing appears to be a common feature of type systems bolted onto dynamic languages: # Python MyStringBool = Literal("Yes") | Literal("No") // TypeScript type MyStringBool = "Yes" | "No" I assume it exists to compensate for the previous lack of typing, and consequent likelihood of ersatz typing via strings. It would seem pretty unnecessary in Haskell, where you can just define whatever types you want w…

String literals are structural types which are way more expressive than regular (Haskell) ADTs, which are nominal types. In TS in particular, in combination with other features (mapped types), they are equivalent to row polymorphism + whatever Haskell/GHC features enable type families to specialize on constant literal arguments (or you can use atomic types, but that's not structural / open-world)... so pretty advance…

I know. I literally gave the example of a Python Literal in the post you're replying to. TS too. :)

My overall point is that Haskell's type system is sufficiently expressive (you may not have "A" | "B" | "C", but you do have A | B | C) that there's no obvious remaining use case for string literals, unless you're thinking of typing input by way of expected literals instead of actually parsing it, which is... a choice. :P

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

#196

Post by mrsmrtss »

za3faran wrote: post #113
lol768 wrote: post #30

Earlier quoted context omitted.

Yes; many (Alpine/Debian) containers in K8s on GKE for production rail ticketing infra in the UK. There's not tons of noise being made because for the most part it all, Just Works and that's fairly boring. Perf, memory usage etc gets better every release. As an ecosystem, I'm pretty happy with it. I reach for other languages for smaller microservices.

What's preventing you from using C# for smaller microservices? And what do you reach for?

Maybe startup time was a problem before AOT?

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

#197

Post by Metasyntactic »

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 release. However, it's a non-trivial area. There's no one correct 'non-boxed' implementation. For example, do you have separate fields for all your unmanaged data? or do you have a blob of bytes that is large enough to align all your unmanaged data from teh largest set of of unmanaged fields, and you unsafe index into that?

Similar question for managed data. Do you have strongly typed fields for that data? Or do you attempt to use objects, to compact to as little space as possible? The former avoids casting costs. The latter allows you to minimize space. You can also potentially use unsafe casts. But those might introduce memory holes in tearing situations. etc. etc.

Because of this, i think the best outcome is to define the pattern (which we've done) and then use generators to allow you to control precisely the impl strategy, giving you all the bells and knobs you want to best fit your domain.

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

#198

Post by Metasyntactic »

bartwe wrote: post #97

As a big user and fan of c# but this is a miss, as it always boxes value types.

Hi there, one of the C# lang designers here. I discuss this a bit in https://news.ycombinator.com/item?id=48255658.

Contrary to what a lot of people guess, boxing is actually a really good strategy most of the time. And, is indeed what many people are doing here anyways. The design supports a pattern that allows for non-boxing, and I expect that we will both supply an implementation for that with reasonable defaults, and that source generators will be a great way to augment this to get highly specialized impl strategies for non-boxing depending on the varying domain needs any specialized customer may have.

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

#199

Post by Metasyntactic »

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 allow for that. Syntax entirely tbd, but you'd do something like:

  enum struct Either // or enum class
  {
     First(T1 value),
     Second(T2 value)
  }
We view these features as complimentary. Indeed, if you look at the extended enum proposal, you'll see it builds on top of unions and closed types (another proposal coming in the next version of the lang).

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

#200

Post by Metasyntactic »

SuperV1234 wrote: post #77

Boxed, and needs complex incantations to avoid the boxing. Meh.

Hi there! One of the C# lang designers here. I discuss that here: https://news.ycombinator.com/item?id=48255658

Note that my expectation would be that the non-boxed form would be as trivial as adding `[NonBoxedUnion(SomeImplStrategyChoiceEnum)]` (or `[NonBoxedUnion]` for some default strategy choices that likely are ok).

This would give you extremely fine grained flexible choice on how you wanted your non-boxing union to work. There's no single right answer. There are just tradeoffs in terms of space/speed/copying-costs/memory-safety/etc.

I think it would make the most sense as people who care about boxing will have very different views and needs in terms of things like space, casting costs, copying speed etc.

The vast vast majority of users do not need to care at all. And for that, a boxed approach works exceptionally well.

Post reply on HN