Hacker News

The C and Rust union types are extremely sharp blades, enough so that I expect the average Rust beginner doesn't even know Rust has unions (and I assume you were thinking of Rust's enum not union)

I've seen exactly one Rust type which is actually a union, and it's a pretty good justification for the existence of this feature, but one isn't really enough. That type is MaybeUninit<T> which is a union of a T and the empty tuple. Very, very, clever and valuable, but I didn't run into any similarly good uses outside that.

Not sure, but I think C++ actually does allow std::variant with multiple choices using the same type. You might not be able to distinguish between them by type (using get<Type>()), but you can by position (get<0>(), get<1>(), ...)

> so our type is really "OneOrMoreOrNone"

If I understand correctly, it’s actually OneOrOneOrMoreOrNone. Because you have two different distinguishable representations of “one”.

The only reason to use this would be if you typically have exactly one, and you want to avoid the overhead of an enumeration in that typical case. In other words, AnyNumberButOftenJustOne<T>.

OneOrMore is more or less an example from the functional world. i.e.:

https://hackage.haskell.org/package/oneormore or scala: https://typelevel.org/cats/datatypes/nel.html

it's for type purists, because sometimes you want the first element of the list but if you do that you will get T? which is stupid if you know that the list always holds an element, because now you need to have an unnecessary assertion to "fix" the type.

`OneOrMore<T>` was an example of using `union` types.

You are free to call it `public union Some<T>(T, IEnumerable<T>)`

> OneOrMoreOrNone

So IEnumerable<T> ? What's up with wrapping everything into fancy types just to arrive at the exact same place.

I went to prove you wrong…

And you’re exactly right.

It’s not “one or more.”

It’s “one or not one.”

Need two or not two.

IME, this is a good thing.

The problem with ad-hoc unions is that without discipline, it invariably ends in a mess that is very, very hard to wrap your head around and often requires digging through several layers to understand the source types.

In TS codebases with heavy usage of utility types like `Pick`, `Omit`, or ad-hoc return types, it is often exceedingly difficult to know how to correctly work with a shape once you get closer to the boundary of the application (e.g. API or database interface since shapes must "materialize" at these layers). Where does this property come from? How do I get this value? I end up having to trace through several layers to understand how the shape I'm holding came to be because there's no discrete type to jump to.

This tends to lead to another behavior which is lack of documentation because there's no discrete type to attach documentation to; there's a "behavioral slop trigger" that happens with ad-hoc types, in my experience. The more it gets used, the more it gets abused, the harder it is to understand the intent of the data structures because much of the intent is now ad-hoc and lacking in forethought because (by its nature) it removes the requirement of forethought.

    "I am here.  I need this additional field or this additional type.  I'll just add it."

So even when I write TS and I have the option of using ad-hoc types and utility types, I almost always explicitly define the type. Same with types for props in React, Vue, etc; it is almost always better to just explicitly define the type, IME. You will thank yourself later; other devs will thank you.

> ad-hoc unions (on the fly from existing types) that are possible in F#

Are you sure? This is a feature of OCaml but not F# IIUIR

Edit: https://github.com/fsharp/fslang-suggestions/issues/538

> It doesn't cover ad-hoc unions

Yes and no. C# unions aren’t sealed types, that’s a separate feature. But they are strictly nominal - they must be formally declared:

    union Foo(Bar, Baz);

    Bar | Baz

Third paragraph from the top:

> unions enable designs that traditional hierarchies can’t express, composing any combination of existing types into a single, compiler-verified contract.

it's basically `union <name>([<type>],*)`, i.e.

=> named sum type implicitly tagged by it's variant types

but not "sealed", as in no artificial constraints like that the variant types need to be defined in the "same place" or "as variant type", they can be arbitrary nameable types

I'm pretty sure at one point there was proposal that allowed declaring something like `int or string`. Not sure what happened with it though.

Right, the default boxes into heap, but unions are different. Some languages pack them as a flat struct (tag + payload, no allocation).

Here is visual layout if anyone is interested - https://vectree.io/c/memory-layout-tagging-and-payload-overl...

Yes, but see the section on custom unions* - you can write non-boxing unions/generators.

* https://devblogs.microsoft.com/dotnet/csharp-15-union-types/...

Yes, but that's just the default behavior. You can implement your own non-boxing version for performance critical applications.

Well off the top of my head...

Active patterns, computation expressions, structural typing, statically resolved type parameters, explicit inlining, function composition, structural equality, custom operators and much richer generators.

type providers, units of measure, active patterns, complete type inference.

Not sure I would want the last thing in C#, I think having boundaries at the function signature for that.

Units of measure

The article mentions that one can implement a union type that doesn't do boxing.

Minimal API is pretty functional.

In C#, all instances have a class, so there is already a discriminant, the class itself.

In the article, the example with the switch works because it switches on the class of the instance.

One step at a time

You aren’t giving enough credit to the careful evaluation of how this adaption is happening.

So far everything that was added to C# very much reduces the amount of dead boilerplate code other languages struggle with.

Really give it an honest try before you judge it based on the summation of headlines.

I personally like the direction C# is taking. A multi-paradigm language with GC and flexibility to allow you to write highly expressive or high performance code.

Better than a new language for each task, like you have with Go (microservices) and Dart (GUI).

I'm using F# on a personal project and while it is a great language I think the syntax can be less readable than that of C#. C# code can contain a bit too much boilerplate keywords, but it has a clear structure. Lack of parenthesis in F# make it harder to grasp the structure of the code at a glance.

> big bag of stuff, with no direction.

also called general purpose, general style langue

> that still can't really be done in C#

I would think about it more as them including features other more general purpose languages with a "general" style have adopted then "migrating F# features into C#, as you have mentioned there are major differences between how C# and F# do discriminated sum types.

I.e. it look more like it got inspired by it's competition like e.g. Java (via. sealed interface), Rust (via. enum), TypeScript (via structural typing & literal types) etc.

> Was a functional approach really so 'difficult'?

it was never difficult to use

but it was very different in most aspects

which makes it difficult to push, sell, adapt etc.

that the maybe most wide used functional language (Haskel) has a very bad reputation about being unnecessary complicated and obscure to use with a lot of CS-terminology/pseudo-elitism gate keeping doesn't exactly help. (Also to be clear I'm not saying it has this properties, but it has the reputation, or at least had that reputation for a long time)

Purity is overrated. C# is a kitchen sink language but you need give credit to the language designers. Compared to C++, for example, C# feels feature rich and consistent even though it abandons purity.

Absolutely agree. Modern C# language design feels very much lacking in vision or direction. It's mostly a bunch of shiny-looking language features being bolted on, all in ways that make the language massively more complex.

Just look at this feature: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...

Was this needed? Was this necessary? It's reusing an existing keyword, fine. It's not hard to understand. But it adds a new syntax to a language that's already filled to the brim, just to save a few keystrokes?

Try teaching someone C# nowadays. Completely impossible. Really, I wish they would've given F# just a tenth of the love that C# got over the years. It has issues but it could've been so much more.

    > I don't really get it

It does each reasonably well (with web APIs being where I think they truly shine).

    > Was a functional approach really so 'difficult'

Union is almost a net positive to C# in my opinion.

But I do agree. C# is heading to a weird place. At first glance C# looks like a very explicit language, but then you have all the hidden magical tricks: you can't even tell if a (x) => x will be a Func or Expression[0], or if a $"{x}"[1] will actually be evaluated, without looking at the callee's signature.

[0]: https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

[1]: https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

Microsoft's management has always behaved as if it was a mistake to have added F# into Visual Studio 2010, and being stuck finding a purpose for it.

Note that most of its development is still by the open source community and its tooling is an outsider for Visual Studio, where everything else is shared between Visual Basic and C#.

With the official deprecation of VB, and C++/CLI, even though the community keeps going with F#, CLR has changed meaning to C# Language Runtime, for all practical purposes.

Also UWP never officially supported F#, although you could get it running with some hacks.

Similarly with ongoing Native AOT, there are some F# features that break under AOT and might never be rewritten.

A lost opportunity indeed.

>Is this the last of the F# features to be migrated into C#? >What a missed opportunity.

Not adding functional features to F# doesn't mean F# would have gained more usage. And if someone wants to use F#, no one is stopping him or her.

> Pulling them all into C# just makes C# seem like a big bag of stuff, with no direction.

Agreed. Java is on the same trail.

Depends on what you mean by ecosystem, it hasn't been trapped on Windows for about a decade now. The variety of third party libraries available is quite good, while the standard library is robust enough that you don't need NPM nonsense like LeftPad and IsEven and IsNumber.

Are there particular things about the ecosystem that you worry about (or have heard about)? Biggest complaint I would have is that it seems like many popular open source libraries in the .NET ecosystem decide to go closed source and commercial once they get popular enough.

C# is a language that serves many masters and if you trace the origin of its featureset, you can see why each was created. Take the `dynamic` keyword: created to support interfacing with COM interop easier[0].

It serves many audiences so it can feel like the language is a jack of all trades and master of none (because it is) and because it is largely backwards compatible over its 20+ years of existence.

That said, I think people make a mountain out of a molehill with respect to keyword sprawl. Depending on what you're building, you really only need to focus on the slice of the language and platform you're working with. If you don't want to use certain language features...just don't use them?

I think it excels in a few areas: web APIs and EF Core being possibly the best ORM out there. For me, it is "just right". Excellent platform tooling, very stable platform, very good performance, hot reload (good, but not perfect), easy to pick up the language if you already know TypeScript[1]; there are many reasons it is a good language and platform.

[0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

[1] https://typescript-is-like-csharp.chrlschn.dev/

Its a great language in a very good ecosystem. Try it. Its great.

It has a bad rep because Microsoft could Microsoft as they do.

> terrible ecosystem

.NET is a fantastic ecosystem. Has a decent build and dependency system (NuGet, dotnet run/build, declarative builds in XML). Massive standard library, with a consistent and wide focus on correctness, ergonomics, and performance across the board.

You can write everything in many languages, all on the same runtime: business logic in C#; hot paths interfacing with native libraries in C++/CLI; shell wrappers in PowerShell, document attachments with VB, data pipelines in F#.

I feel more people should use it, or at least try it, but sadly it is saddled with the perception that it is Windows-only, which hasn't been true for a decade (also, IMO, not necessarily a negative, because Windows is a decent OS, sue me).

Why is the ecosystem bad? I haven't ran any .net code on anything but Linux in years. The open source community is great. I don't know why it gets a bad rep.

It's a very nice language embedded in a very nice ecosystem. There is no catch, really.

C# can be used inside Unity game engine. Does this makes it trapped?