Live data from Hacker News

Official proposal for Type Unions in C#

github.com

81–90 of 315 posts

Re: Official proposal for Type Unions in C#

#81

Earlier quoted context omitted.

F# has it's own warts, tooling isn't as polished, stuff like type providers sound really cool but suck in practice IMO, file ordering being relevant for compilation is bleh... Every time I try to use it I'm left with a feeling it's not worth the hassle over C#. C# has been quite nice for 10 years and they keep improving consistently with every version.

The language itself is nice, the code bases that companies produce with it is not, and sadly that reputation plays into your decision to choose a career stack. You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project. I envy people who only do hobbyist C# so get to work on code bases that have all the…

>You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project.

I've been spending the past couple years migrating various platforms from Framework to the new .NET and as long as you've got a head on your shoulders it's not too bad. Also, new projects in .NET are fantastic to work with, imo.

Re: Official proposal for Type Unions in C#

#82

Every time the question of preferred programming languages comes up, I'm usually in the extreme minority with my preferences being Rust (for small/fast) and C# (for productive and easy, where GC is acceptable), a combination that doesn't seem to appeal to too many people. But for the projects that fall right about in the middle where it could go either way and I could see either language working, I almost always pick…

You must really hate REPLs. You cling to your ADTs, I cling to my REPLs.

Re: Official proposal for Type Unions in C#

#83

Every time the question of preferred programming languages comes up, I'm usually in the extreme minority with my preferences being Rust (for small/fast) and C# (for productive and easy, where GC is acceptable), a combination that doesn't seem to appeal to too many people. But for the projects that fall right about in the middle where it could go either way and I could see either language working, I almost always pick…

> It's incredibly hard to go back to a language without even basic ADTs after seeing the light. How did we ever prioritize implementation inheritance over ADTs? I don't know, but it was a mistake.

Probably bescuse OOP was a great fit for desktop GUI’s. This drove OOP into the mainstream. ML-style languages never had a similar killer application.

Re: Official proposal for Type Unions in C#

#84

Earlier quoted context omitted.

Nah, people continue to pick Java or Go when they want to build their enterprise systems if they're not already married to Microsoft. There's not a single widely distributed infra application in C# out there. When people want to build stuff like kafkas, kubernetes, consuls, they still go to Java/Go/C++.

This comment is kind of out of the blue because no one in this thread is advocating for using C# for infrastructure projects. Java is frankly a bad choice for that too these days for a new project, and for the same reason: why would you develop infrastructure in a language that requires shipping a runtime when Rust and Go exist? That made a lot more sense back when C/C++ was your only other real choice. Meanwhile, pl…

Java has been fine for infrastructure projects. There is so much out there that relies on things like elasticsearch, Kafka, or any aws service. Heck even the columnar dbs like pinot and Druid are most likely more used than clickhouse.

C# is also fine for this, just way less popular. Recently ms put out https://github.com/microsoft/Garnet when the redis debacle happened.

The Apache project has helped put out quite a few large infra projects, most of them in Java (I don’t know why this is but assume they have lots of resources to help with that, and also that people don’t like debugging memory crashes).

Ms has just been not the greatest collaborators with their open source community. A lot of the time it seems like they want to do the initial foundation, then leave “drawing the rest of the owl” to the community, which ends with lots of partially functional things. GUI frameworks, f# tooling, drivers for commonly used critical infra. At the same time, people get upset when ms tries to build a better version of an existing open source project, so there’s no winning. They’ve just put themselves in such a poor spot.

Re: Official proposal for Type Unions in C#

#85

Earlier quoted context omitted.

This comment is kind of out of the blue because no one in this thread is advocating for using C# for infrastructure projects. Java is frankly a bad choice for that too these days for a new project, and for the same reason: why would you develop infrastructure in a language that requires shipping a runtime when Rust and Go exist? That made a lot more sense back when C/C++ was your only other real choice. Meanwhile, pl…

It's even worse, plenty of Azure itself is C#, and I don't mean a few dashboards, I mean the infrastructure itself, heck the serverless infrastructure's open source and its basically C#. I'm sure the same could be said of AWS and Java (making an assumption), or Google Cloud Platform and Go / Python.

Ironically, given the past history that lead to .NET existence,

https://devblogs.microsoft.com/java

https://www.microsoft.com/openjdk

https://code.visualstudio.com/docs/languages/java

Because it turns out, making Java running on Azure, on those 60% Linux workloads, is lot of money.

Also plenty of Azure, anything CNCF related, is mostly Go and Rust.

Which is kind of sad, I would expect Azure to be a good contributor for having a .NET presence in the CNCF project landscape.

Re: Official proposal for Type Unions in C#

#86

Earlier quoted context omitted.

C# is great, likely the best mainstream programming language nowadays, but its in the hands of microsoft and microsoft didn't really care much about building a community or getting it to work natively in other OSes/toolchains. Its a shame, they even had a second change when Oracle bought sun and no one knew what was going to happen with Java, but fumbled that as well.

This comment feels like it's been written 20 years ago. C# runs natively anywhere and this has been true for at least a decade.

I'd like a supported port of .NET to the BSDs.

Re: Official proposal for Type Unions in C#

#87
post #16
post #13

Is the terminology slightly off? AIUI TypeScript has type unions. But this looks like a discriminated union which I'd recognise from F# or Haskell. The distinction I'd draw is that for a DU there are named case constructors. Yes?

TypeScript has "union types". This proposal refers to them as "ad hoc unions". I don't think "type union" is a term of the art - at least I haven't heard it before. It seems to be something the C# people are making up to describe sum types.

> I don't think "type union" is a term of the art

"sum type" is the term of art in Computer Science theory, but "union type" is also used.

See

https://en.wikipedia.org/wiki/Type_theory#Sum_type

https://en.wikipedia.org/wiki/Tagged_union

Re: Official proposal for Type Unions in C#

#88

Earlier quoted context omitted.

A very common modern setup is PostgreSQL, C#/.NET, Linux & using JetBrains Rider for the IDE. You don't have to go all in Microsoft to use C#, F# or .NET. Also .NET has been about "run everywhere on any platform" as their tagline for quite a few years now. They have had plenty of community fumbles without question. I can't speak to those though. I've seen lots of vocal high up Microsoft employees try to win those fig…

A very common modern setup is PostgreSQL, C#/.NET, Linux & using JetBrains Rider for the IDE You just described the startup I'm at. All devs are on Arm64 MacBooks and we deploy to Arm64 AWS T4g Linux instances. I'm all VS Code, others are primarily Rider. .NET is a highly underrated platform for backend; it always puzzles me when teams think about moving from TypeScript to Rust or Go instead of C# because it seems a…

I'm itching to try and deep dive into go as a C# dev. I'm getting sick of enterprise C#, even if it is .NET8

I guess the grass is always greener somewhere

Re: Official proposal for Type Unions in C#

#89
post #14

Earlier quoted context omitted.

I do like Scala, and I haven't touched Scala3, but I've found it pretty unwieldy for actual use. It feels like I'm constantly fighting with the type system in a way that ends up being annoying an unpleasant. To be clear, it's not like I'm new to functional languages and their type systems, I've been doing Haskell for forever, and I did F# for a multiple years, but Scala has never really clicked for me. Personally, fo…

> I definitely recommend giving F# a try. I think it's an extremely underrated language. Do you have any recommendations for people who do not have C#/.NET experience who want to rip their toes in F#? The last time I tried the language I bumped my head on the .NET parts. :/

It is a dream learning guest languages, while trying to avoid the platform, one really needs to understand UNIX, Web, .NET, Java, Erlang... for using whatever alternative leaky abstractions are provided on top of them.

In F#'s case, there are plenty of good books, and then it is really needed to learn the platform.

Some well known ones => Stylish F#, F# in Action, Domain Modeling Made Functional

Re: Official proposal for Type Unions in C#

#90
post #53

Earlier quoted context omitted.

Maybe I'm off, but to me the gist of the expression problem can be explained by contrasting how code extensibility is achieved in OOP/FP. OOP Approach with interface/inheritance: Easy: Adding new types (variants) of a base class/interface. Hard: Adding new functionality to the base class/interface, as it requires implementing it in all existing types. FP Approach with Discriminated Unions: Easy: Adding new functions.…

I think you've nailed the definitions. However the definitions make the 2 choices (adding new types vs adding new functions/operations) sound like a toss-up. It is the fact that I tend to find the FP/DU approach so much more frequently useful for my/my team's own code that makes me wonder if I'm missing something. Perhaps the important distinction I've been missing is in Wikipedia's definition: "The goal is to define…

The reason why it matters less than people intuitively think is precisely that it matters a lot less when you're in full control of both the operations and the types anyhow, and that's actually the most common case. Generally you are "composing" in library code, that is, just using it, not extending the library itself.

When you are extending, you actually want to choose the correct thing depending on what you need. Going the wrong direction is painful in both directions.

Personally I think one of the reasons sum types are greeted with such "oh my gosh where have you been all my life" reactions is precisely that we had type extension as our only option for so long. If we had had only sum types, and type extension was given to us for the first time in obscure languages 20 years ago and they only really started getting popular in the last 5 or so, I think they'd be considered in much the same way. Just as in a world with only screwdrivers, the invention of the hammer would be hailed as a revolution... and in a world with only hammers, the invention of the screwdriver would be hailed as a revolution. But in both cases the real mystery is how the hypothetical world got that far in the first place.

Not that they aren't useful; consider what it means that I'm analogizing them to something like a hammer and a screwdriver, not an oil filter remover or something. It is weird that we were missing one of them for as long as we were in the mainstream.

Post reply on HN