Live data from Hacker News

Official proposal for Type Unions in C#

github.com

41–50 of 315 posts

Re: Official proposal for Type Unions in C#

#41
post #4

Earlier quoted context omitted.

F# is so hard to walk back from. I wish Microsoft would support it better and actually push it, because it's such a perfect sweet spot. Most of the functional advantages without being shackled to pure functions and the like is so easy to develop in. Instead they've been, very slowly, turning C# into F#, which is even weirder to watch.

I'm glad they're simply turning C# into F#. They're coming to us where we are, rather than forcing us to make a jump. I'm a relatively "blue collar" developer, I know a little about FP (not enough to be productive in F#) but I have tons of C# experience. I appreciate them taking the good stuff from F# and making it understandable to C# developers. It's been a delightful progression; no big jumps, no paradigm shifts,…

So the issue for those of us in F# land, is that it's really not a big jump from C#. I've taught it (lightly) to at least one C# dev who basically picked it up in a weekend.

Something that helps, a ton, is as you're transitioning, you can write code almost identically to how you did before. It doesn't force FP on you at all. It's less useful if you try to do that, because you're not taking advantage of the language, but it makes testing your beliefs on how things work SUPER easy because you can set it up in the OOP way, get the result you expect, then set up in what you think is the correct FP way, and see if it matches.

The only issue is there's a severe lack of beginner friendly documentation (although it's leagues better than it used to be). I honestly think that if you're a C# dev, it's probably worth giving it a weekend or two to play with. ESPECIALLY if you like linq syntax.

Re: Official proposal for Type Unions in C#

#42
post #12

Earlier quoted context omitted.

Instead of C#, why not F#? You get proper ADTs among many other great features, but you still get all the utility of the .NET ecosystem.

The benefits of F# only really apply when using a 100% F# codebase. Try doing WinForms in F#...

I mean that's mostly pretty easy bindings, but yeah it's annoying that you have to do them and feels like you're losing out on the whole damn point of using F#

Re: Official proposal for Type Unions in C#

#43

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…

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.

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 fights on the side of the community but no idea what happens internally.

Re: Official proposal for Type Unions in C#

#44
post #12

Earlier quoted context omitted.

Instead of C#, why not F#? You get proper ADTs among many other great features, but you still get all the utility of the .NET ecosystem.

I get the feeling F# is a second-class citizen in the ecosystem. How likely is it (or is it at all possible) that I'm going to run into some library that doesn't work with F#?

Just to add to the other comments, in my experience a large majority of libraries work fine. Maybe a little tweak here or there, or maybe you need to use some C# esq syntax (which is harder in my case because I so rarely do now).

Generally though, it's pretty easy. Sometimes you'll want to make bindings around various things (not that you need to, but it'll make things smoother).

It's not actually awful, it's just that there's no real documentation of "hey today we're going to take Serilog/whatever and show you how to configure it in F#" style videos, so depending on where your weaknesses lie it can feel frustrating.

Re: Official proposal for Type Unions in C#

#45

Earlier quoted context omitted.

> 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. That statement was true - until 2016. Times change, Microsoft changed.

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, plenty of people are in this thread telling you that they do in fact use C# to distribute cross-platform applications, but you seem to be uninterested in hearing that.

Re: Official proposal for Type Unions in C#

#46
post #34

I'm currently using nested records with a private constructor in combination with the nuget package https://github.com/shuebner/ClosedTypeHierarchyDiagnosticSup... to make sure the switch types do not require a `_` case. This is essentially the desugared version of their "Union Classes" proposal. This already works very well. Still, I like this proposal because it would be nice if the nuget package would become unnec…

Do note that record types aren't closed even with a private constructor. The compiler will generate a protected constructor for copy operations which can then be inherited from. To prevent this, you have to define your own protected constructor and have it throw a runtime exception if it isn't a valid case.

Re: Official proposal for Type Unions in C#

#47

Earlier quoted context omitted.

> 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. That statement was true - until 2016. Times change, Microsoft changed.

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

> There's not a single widely distributed infra application in C# out there.

Azure has entered the chat.

Microsoft Orleans has entered the chat.

ASP .NET Core has entered the chat.

Ever played Halo online?

Used StackOverflow? (very likely)

Visited any website on Azure? (most likely)

Microsoft Orleans (Virtual Actor framework) powers the Halo server infrastructure since at least 2011 if not sooner, which arguably the Halo series is insanely popular, especially for online gaming. Also powers plenty of Azure itselfs own infrastructure. I've worked on dozens of scalable C# projects, and know plenty of devs from all over who have as well.

Orleans was so good, EA made their own version in Java which was extensively used there as well, though it looks to be dead, but Orleans is as alive as ever.

Not to mention plenty of Azure itself is open source, like say... Azure Functions, which run inside of ASP .NET Web Services... and are... you guessed it, C#. Plenty of services running on that platform.

https://github.com/Azure/azure-functions-host

Re: Official proposal for Type Unions in C#

#49

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…

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.

Re: Official proposal for Type Unions in C#

#50
post #34

I'm currently using nested records with a private constructor in combination with the nuget package https://github.com/shuebner/ClosedTypeHierarchyDiagnosticSup... to make sure the switch types do not require a `_` case. This is essentially the desugared version of their "Union Classes" proposal. This already works very well. Still, I like this proposal because it would be nice if the nuget package would become unnec…

Do note that record types aren't closed even with a private constructor. The compiler will generate a protected constructor for copy operations which can then be inherited from. To prevent this, you have to define your own protected constructor and have it throw a runtime exception if it isn't a valid case.

You are technically correct (the best kind of correct), but in practice I've not found this to be a problem, certainly not something that is ofsetting the vast usefulness of this data pattern.
Post reply on HN