Uhh, Span/Memory support is coming soon https://github.com/fsharp/fslang-suggestions/issues/648

Channel<T> uses ValueTask<T> which is kinda painful in F# for now.

https://github.com/fsharp/fslang-suggestions/issues/581

It's a little sad to hear that this wasn't considered part of MS core effort for the 2.1 rollout. I think the challenge is C# is viewed as 'good enough' with incremental language improvements, while F# gets dragged behind via support from the community (although dedicated, they are not large). I'm wondering if this situation will ever change. I already know of companies sceptical of adopting F# because of lack of perceived commitment by MS.

I feel your pain. F# has effectively been punished for being so innovative.

They had tuples, async/await, and match statements a decade ago and every time C# adopts one of their feature they change the implementation and make F# retool. It's kinda awful.

At this point I want F# to do a hard reset, rebuild on top of Roslyn, natively adopt ValueTuple and Task/ValueTask then grow alongside C# like VB tried to.

> At this point I want F# to do a hard reset, rebuild on top of Roslyn, natively adopt ValueTuple and Task/ValueTask then grow alongside C# like VB tried to.

I've been hoping for basically the same thing. That said, putting any new language on top of Roslyn (not just using it for IL generation, but actually making it a proper provider a la C#) is 1) not supported, and 2) not seeming like it's going to be. I have a language on .NET that I would love to build into a first-class Roslyn provider but there just isn't any support for that right now. Maybe F# folks inside MS can work to change that.

C# has a large network effect and it also has very few disadvantages, so there is little motivation to switch to F# for C# devs.

C# does keep getting better, and making the delta between what it offers and what F# offers smaller, at least from what I can see. I've really wanted to get on the F# train, but I just haven't been able to get it out of the station yet.

I'm somewhat astounded that VB.Net is still a thing, however.

F# always suffered from lack of VS tooling support, I was always on the edge waiting for it to be supported on GUI designers just like VB.NET and C#.

Using it mostly for scripting like tasks only.

Then it wasn't relevant for .NET Native support, and finally Microsoft keeps ignoring some vocal anti-MS/C# members in the community, which made me loose any remaining interest.

I rather have C# with some FP like features, than a FP language without tooling support and needless forum discussions.

Regarding VB.NET, it is used quite a lot in some enterprise shops.

I have seen many apps that started as office macros and eventually grew up to be VB.NET ones.

Even if VB.NET is more complex than VB was, it still easier than C# for those office employees that know one or two things about coding.