Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Official proposal for Type Unions in C#

github.com

Post reply on HN
Print view View original

281–290 of 315 posts

Re: Official proposal for Type Unions in C#

#281

Post by LtWorf »

metaltyphoon wrote: post #280
LtWorf wrote: post #271

Earlier quoted context omitted.

apt install dotnet-sdk-8.0 Building dependency tree... 0% Error: Unable to locate package dotnet-sdk-8.0 Error: Couldn't find any package by glob 'dotnet-sdk-8.0' Works like a charm. Any more irrelevant things to say?

All this means is Pop OS doesn’t have it published. You don’t have to throw a piss because MS doesn’t publish it for Pop https://github.com/dotnet/core/blob/main/linux.md#packages

I use regular proper debian.

The fact that it's not there (and it can't be there) was exactly my point.

I use toilets normally. I don't throw excrements.

Re: Official proposal for Type Unions in C#

#282

Post by neonsunset »

LtWorf wrote: post #272
nickcox wrote: post #141

Earlier quoted context omitted.

In what ways?

Basically it's not included in any distribution. Mostly for license problems. Which means anything you write with it can't be included in any distribution. It's quite limiting. Basically it's only useful for proprietary software shipped by 3rd party.

The entirety of https://github.com/dotnet/dotnet (which is a VMR for full-source build of Roslyn, runtime and everything else that goes into runtime-only and SDK packages) is MIT, which is as permissive as it gets, save for CC0 or Unlicense.

Quick search shows that SDK and runtime packages are available in the official feeds for

Archlinux: https://archlinux.org/packages/?sort=&q=dotnet

Fedora: https://packages.fedoraproject.org/pkgs/dotnet8.0/

Ubuntu: https://pkgs.org/search/?q=dotnet

I always wondered what is the motivation behind the negative comments like these on .NET submissions. Is this because .NET is mostly made by MS employees instead of Google (which is an AdTech company) or Oracle (which has a license trap JDK distribution)?

Re: Official proposal for Type Unions in C#

#283

Post by throw868788 »

wk_end wrote: post #12
ComputerGuru wrote: post #8

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…

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.

Indeed. The company I work for uses F# for large revenue workloads across many services; mostly coming from non .NET dev's. It handles large scale customer traffic quite well without a hiccup and with the C# interop we never find we are blocked (e.g enterprise/vendor libs). They found it easier to learn F# than C# - it has a lot more in common with JS/Go/etc in how code is structured and maintained from their POV. Good mentorship is critical for learning and deriving extra value from it especially if coming from old C#/Java/etc. The push for C# to minimal APIs, less classes, etc from our experience has slowly made it less necessary to have F# wrappers as well - the interop ugliness usually only resides in one file (e.g. ASP.NET Startup.fs or equilvalent in given C# framework). Given our proprietary nature however we don't broadcast a lot of our dev effort/development online - I assume many F# shops are/were similar.

We've created very large scale applications in it requiring significant throughput. One of its benefits is also its disadvantages - we typically are quite productive in it and so don't feel the need to hire as many people in the team. Before LLM's were a thing we found we were wasting less time with boilerplate in general than our C# code for example. YMMV.

Re: Official proposal for Type Unions in C#

#284

Post by Archelaos »

neonsunset wrote: post #219
Archelaos wrote: post #60

Earlier quoted context omitted.

That F# has no native GUI framework is the reason why I stick with C#. When coding something with a GUI, the majority of my development time is typically spent in the GUI layer. The rest is some more or less straightforward object relational mapping with some validation an calculations in a business layer where I use Linq to emulate functional programming in C#. Adding F# to the game would only complicate the scenari…

There is! https://funcui.avaloniaui.net/

It is just a wrapper around Avalonia, which is written in C#.

Re: Official proposal for Type Unions in C#

#285

Post by neonsunset »

Archelaos wrote: post #284
neonsunset wrote: post #219

Earlier quoted context omitted.

There is! https://funcui.avaloniaui.net/

It is just a wrapper around Avalonia, which is written in C#.

It is (together with FuncUI Elmish) an extension for Avalonia to write GUI applications in F#. What difference does it make if Avalonia itself is written in C#?

Re: Official proposal for Type Unions in C#

#286

Post by neonsunset »

lmm wrote: post #278
neonsunset wrote: post #275

Earlier quoted context omitted.

Do you have a specific scenario and a package name in mind when you say "Nontrivial programs mostly don't run"? This is the only way for this statement to be true. If it's something niche, the question is to the package maintainers, as usual, if it's actively maintained that is. As a sibling comment pointed out, .NET assemblies within Nuget packages are by-definition portable, unless they use platform intrinsics with…

> Do you have a specific scenario and a package name in mind when you say "Nontrivial programs mostly don't run"? Not a specific single program (not package) just my general experience of how "find useful-sounding program written in C#" -> "download it, try to run it" usually goes. I could probably dig up the name of the most recent thing I tried it with if you really want (I think it was a video renaming tool) but t…

> If most package owners act a certain way that's what culture is. I doubt either of us has the time to do a statistically valid survey of what's out there. Maybe your experience is different, but let me ask: are you actually using C# programs on non-Windows, and e.g. reporting bugs in them? And finding maintainers take them seriously when you do?

Yes, I do, but only those that I personally encounter, which almost never happens, my daily driver is macOS but .NET treats it very similarly to Linux. Linux is the most well-polished platform though. I can't actually believe we still have to have this kind of conversation in 2024. It's like talking to a street madman who keeps asking "no but is the sky blue? are you sure?". Yes, it is.

And no, it's not something you have to actively think about - just send an http request, write to a file, render a button with avalonia, etc. None of these require thinking about underlying OS. It just works.

In fact, the first version which was called back then .NET Core 1.0 was released 8 years ago, and was already cross-platform. By the time .NET Core 3.1 got released, it was battle-tested and stable, many businesses were moving their applications to linux hosts, often to containerized deployments at the time. This was about 5 years ago. A blink of an eye for enterprise, but a long time ago given the development pace.

> Obviously there are levels of "not supported" here, but "well, your patch sounds ok so I'll merge it, can't promise we won't break FreeBSD again in the future since we don't have the resources to test it" is still better than I've gotten from most C# projects when I've tried.

FreeBSD support is "well, your patch sounds ok so I'll merge it, can't promise we won't break FreeBSD again in the future since we don't have the resources to test it". There are considerations to not break community-supported platforms though.

> I think projects that assume the whole-world is Linux and don't support e.g. FreeBSD or Illumos (I assume that's what you meant by SunOS?) are very much anti-OSS, and complain loudly about them when I encounter them, yes.

I'm sure maintainers appreciate it and are grateful for this kind of attitude :)

Re: Official proposal for Type Unions in C#

#287

Post by LtWorf »

neonsunset wrote: post #282
LtWorf wrote: post #272

Earlier quoted context omitted.

Basically it's not included in any distribution. Mostly for license problems. Which means anything you write with it can't be included in any distribution. It's quite limiting. Basically it's only useful for proprietary software shipped by 3rd party.

The entirety of https://github.com/dotnet/dotnet (which is a VMR for full-source build of Roslyn, runtime and everything else that goes into runtime-only and SDK packages) is MIT, which is as permissive as it gets, save for CC0 or Unlicense. Quick search shows that SDK and runtime packages are available in the official feeds for Archlinux: https://archlinux.org/packages/?sort=&q=dotnet Fedora: https://packages.fedora…

> I always wondered what is the motivation

This is the motivation ↓

    apt install dotnet-sdk-8.0
    Error: Unable to locate package dotnet-sdk-8.0
    Error: Couldn't find any package by glob 'dotnet-sdk-8.0'

Re: Official proposal for Type Unions in C#

#288

Post by orthoxerox »

kriiuuu wrote: post #11
Eji1700 wrote: 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 feel the same about Scala. I use Scala3 daily and almost every other language is such a step back. I have looked at F# and it looks like one of the only other languages I would enjoy as much as Scala. Haskell is nice too, but the ecosystem is just not quite there. F# being able to tap into the rich C# ecosystem and Scala being able to tap into the Java ecosystem is such a win and makes them feel a lot less niche wh…

When I have to use Scala, I am always confused by the amount of magic that is happening behind the scenes. It's so much magic that even the best IDEs become confused with me. C# is smarter in that regard: 99% of useful syntax is method calls, and typing the dot doesn't drown you in overly generic suggestions.

From what I've seen, Scala3 is better in this regard (at least the magic part), but I since Spark doesn't support it yet, my exposure to it has been limited.

Re: Official proposal for Type Unions in C#

#289

Post by orthoxerox »

tubthumper8 wrote: post #95

Can anyone explain why this is called "type unions"? I've never heard it named that before. It's a bit weird, because it's not a union across types (like ALGOL68), it appears to be a tagged union like in ML-family languages. Is this just a case of "C# developers like to make up different names than established terminology"? (see: SelectMany, IEnumerable, etc.)

Because the proposal is about several kinds of unions:

- closed hierarchies of reference types that the compiler will verify at build time

- value types that use compiler tricks to behave like closed hierarchies (tagged unions)

- custom types that can have any implementation but can hook into the same compiler mechanisms to behave like a union of types

- ad-hoc unions of existing types

Re: Official proposal for Type Unions in C#

#290

Post by sbergot »

arnath wrote: post #206

As a long time C# dev, I feel like I’m missing something about this proposal. The use case for this doesn’t seem well defined to me. Could someone give me a real world example? I’m pretty sure you can implement the example in this proposal by declaring an empty interface and having some record classes that “implement” it. Does that lose something that I’m not seeing?

A simple example is the Result which could have either Ok(T value) or Error(string message). In order to get the value you need to switch over both cases, forcing you to handle the error case locally.
Post reply on HN