3 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# a

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.

daeken 8y ago
> 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.
zenovision 8y ago
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.
- megaman22 8y ago
  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.
  - pjmlp 8y ago
    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.

daeken 8y ago

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

zenovision 8y ago

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.

megaman22 8y ago
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.
- pjmlp 8y ago
  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.