C# are pushing for type classes https://github.com/dotnet/csharplang/issues/164

which author of F#, previously, didn't like to add to F#. (Not hating on how he wants the language to evolve)

For clarity, the position is that large features like TC/HKT won't be added in a way that could conflict with a later-added .net/IL version of the feature.

There are real problems with IL compatibility. There’s a reason F# doesn’t have ML functors.

Support for .NET Native would be an example.

Default interface methods, not sure about the current support state.

The accessors protected private.

I am also not sure if all low level programming features added to C#, taken from Midori and until C# 7 only usable from C++/CLI, are also exposed to F#.

.NET Native is being replaced by .NET Core and Mono with .NET 5, which has been the plan for some time. Doing work specifically for that toolchain might have been more meaningful 4 years ago, but the amount of investment required relative to the benefit (number of developers targeting it) would have been pretty low too. Incidentally, it also works and publishing to the store is unblocked; just not supported via the VS tooling.

DIMs are set for .NET 5. Cut from Core 3.0 since quality would have been an issue.

_private_ has been supported in F# for ages; _protected_ is explicitly not supported. I'd personally like to see it supported for interop but this is the language designer's call.

All the low-level programming features added to C# have F# "equivalents", and I use quotes because semantics differ between the languages and so your experience using one or the other is going to be quite different depending on what you're doing. But the performance output will be the same.

.Net Native works

For some definition of "works".

Visual Studio tooling support is nowhere to be seen, and the github issue does least some caveats.

well C# 8.0 introduced async streams, for example

Yes, and the F# library for asynchronous sequence processing had support added for them shortly thereafter (https://fsprojects.github.io/FSharp.Control.AsyncSeq/library...)

It's worth noting that this isn't an "IL feature", but a new type that includes some knowledge of the type shape in the C# compiler. The existing F# package for async streams understands the new type, and it "just works" in F#.

F# allows you to implement such features as libraries using computation expressions.

So does C# with LINQ [1]. I guess C# language development tends to lean more on concrete syntax than libraries, which is a shame, but it is possible. It's also a shame LINQ can't be extended like computation expressions.

[1] https://github.com/louthy/language-ext/blob/master/LanguageE...

The async model in F# is entirely different from C#. Not sure if an equivalent of C# async streams would make sense in it.