Live data from Hacker News

Official proposal for Type Unions in C#

github.com

211–220 of 315 posts

Re: Official proposal for Type Unions in C#

#211

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…

I've been writing C, C++, C# and some js/sql/ts/python for money. Lua for lulz. And *nothing* gets even fucking close in terms of productivity to C#. Great language, mature and robust ecosystem with sane compilation times and great tooling: package manager, test runner, strong debugger, one CLI with almost all tools needed. I wish C++ was half as enjoyable as C# is.

I've programmed damn-near everything at some point, with a long period of x86 assembler plus C++. Really unpopular opinion: VB.NET was the most enjoyable, most readable language I ever programmed in.

I've only begrudgingly moved to C# over the last few years as my primary since MS has pretty much killed VB.

Re: Official proposal for Type Unions in C#

#212
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?

I found this video quite useful in showing the new proposal in action.

https://youtu.be/aksjZkCbIWA

Re: Official proposal for Type Unions in C#

#213
post #53

I’ve lost track of all of the red/blue/white/black pill color metaphors, but unions with exhaustive pattern matching is one of the toughest of all programming language features to live without once you become aware of it. I’ve never felt like I’ve fully understood the implications of the expression problem https://en.wikipedia.org/wiki/Expression_problem but my best/latest personal hypothesis is that providing extens…

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

When statement will be exhaustive thanks to the sealed class, so compiler catches this, one of the great things about Kotlin.

Re: Official proposal for Type Unions in C#

#214

Earlier quoted context omitted.

> Seems more confusing than useful. Are you suggesting that these design decisions make it through the entire process and into the language without the feature bringing a clear advantage in its use case? What would you say are the worst two or three of these C# features approved in the last decade? Let’s assume for the sake of argument that you are correct though. The Roslyn compiler diagnostics are second to none, a…

> These guys aren’t writing feature proposals the way you write comments. You’re comparing the effort of a mainstream language design proposal to a pseudonymous internet comment, wow, just wow. Do you truly know real software developers using any these new features? I must not be working anywhere cool because I’m always having to explain what they mean in code reviews. Imagine writing a full C# compiler in 2024, imag…

Appreciate the earnest reply. This is a much better discussion now.

> Do you truly know real software developers using any these new features? I must not be working anywhere cool because I’m always having to explain what they mean in code reviews.

If you mean 9-5 devs, I am not even afforded the luxury of working with C# at all! Haven’t been since before .net core. I do ruby and devops. That being said, I have a side project with dozens of real users, closing in on double digit “market” share. I’ve needed to do some serious performance optimizations (it is a fork). The ValueType flexibility makes it easier to do these improvements.

Init applies to properties, readonly to fields (and methods in structs, or valuetype parameters).

The switch expression is something I’m also not sure about yet, but makes for less clutter in the editor. I think it’s part of a general strategy of providing the language with more compact syntax options. It reminds me of the pattern matching in F#. Did the language need those? Not really, but my biggest annoyance with older C# was the verbose syntax, and it factored into my perception at the time that it was a dinosaur language.

Roslyn is open source, cross-platform, written in C#, and can be forked. The analyzers can be linked as dependencies to any source project. I don’t understand the VS/Windows connection. They are just basically hooked methods that run during compilation steps and can emit compiler warnings, errors, suggestions, or automatically fix code. I think you are shooting yourself in the foot if you throw that feature out on pride.

Nullable reference types are optional on the file or project level and function more as type assertions, and don’t represent separate classes. I understand the frustration with it though. I think the language needed this in order to be able to statically analyze the expressions for nullability instead of relying on runtime checks. Those runtime checks are notoriously unreliable as a safety net because you have to remember to use it, and make a decision on using it. They made a tough call but I think it was the right one.

Structs are not records and are in fact mutable by default! It can be converted to a ref and then mutated, without unsafe code. The readonly modifier prevents that. I haven’t studied the nuances of readonly structs vs record structs yet. It’s considered a bad practice to use mutable structs (and undermines compiler optimization) but if you’ve ever had to refactor a class to a struct, with hundreds of usages, having the mutability can make the task much easier to do incrementally.

I think they are careful, but the decisions are very difficult and sometimes it’s a loss in either direction. C# prefers to change with the times but remain backwards-compatible, but I don’t envy the jobs of the language committee.

Re: Official proposal for Type Unions in C#

#215

Earlier quoted context omitted.

Unironically this. Having "interfaces" and "abstract classes" is just a kludge, multiple inheritance covers all of this with one language construct. The "diamond problem" is a C++ issue, every other language solved it.

I think they solved the problem by not supporting multiple inheritance, instead supporting interfaces and/or traits. But also "composition over inheritance" pretty much won, thankfully imho.

Mixins via inheritance is a sweet pattern that I miss in C# sometimes.

Re: Official proposal for Type Unions in C#

#216

Earlier quoted context omitted.

> 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

At this point, calling it by its correct name (Sum Types) would leave them looking stupid for not using the correct name (Product Types) for their “records”

But then what name would they use for tuples, which are distinct from records?

Re: Official proposal for Type Unions in C#

#217

Really excited for this proposal as it's been the main thing I have to apoligize for when extolling the values of C#. Outside of this it's hard to think of other major features C# lacks for a language. Additionally, excited to now watch this go in and people on HN still act like C# is the same it was 10 years ago.

Proper type aliases would be nice, but I have to say I really enjoy coding C# these days.

Re: Official proposal for Type Unions in C#

#218
post #196

Earlier quoted context omitted.

No linters in C#? That’s a good one. C# as a language has always been cross-platform. Though the last few versions have made incredible gains in performance optimizations. You won’t get the flexibility of C++ but the performance comes close to it in most cases, when written optimally. And you don’t have to deal with arcane, bullshit build systems with a learning curve that is worse than the language, and breaks down…

> C# as a language has always been cross-platform. Not really. Like, it notionally ran on FreeBSD, but nontrivial programs never actually worked until recently, and even now they mostly still don't.

https://www.freshports.org/lang/dotnet

    pkg install lang/dotnet
Not everything works, and support is community-maintained, but “mostly doesn’t run” does not reflect actual state of affairs.

Re: Official proposal for Type Unions in C#

#219

Earlier quoted context omitted.

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

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/

Re: Official proposal for Type Unions in C#

#220
post #10
post #7

Earlier quoted context omitted.

Good news is that you can achieve this with relatively little boilerplate in Java with sealed interfaces and records now. Relative to Java that is

Yeah, I know, and I have started using those, though that doesn't undo the last 15 years of Java code that I've written where that wasn't really an option. Still, good to see Java joining the 21st century at least.

> that doesn't undo the last 15 years of Java code that I've written where that wasn't really an option.

Same for C# with this new feature. Sum types (as I like to call tagged/type unions) are such an important tool to have, not having it makes languages resort to all kinds of abominations, e.g. exceptions, product types (= records, structs, etc) that are actually sum types, "null to signify something went wrong", etc.

Not having them from a language's start results in an std lib that does not use them and hence teaches new comer to the language a bad way to do it.

Post reply on HN