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)

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'

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.

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.