12 ms·

I still feel Microsoft development experience is pretty poor and has been sometimes hostile in the past, and still don't have much confidence nowadays. Maybe b

I still feel Microsoft development experience is pretty poor and has been sometimes hostile in the past, and still don't have much confidence nowadays. Maybe because it's not a popular language, but the F# experience for me has been bad - tried it two years ago with F# 5, and recently with F# 6. The documentation in both cases was immature/inconsistent to broken.

markmark 4y ago
F# is very much a second-class citizen in the Microsoft world.
moonchrome 4y ago
Every time I tried F# with .NET tooling it felt like the implementations were there to tick the "supports F#" checkbox - and nobody actually used it for the thing I tried to do because it broke really early on. Early on one of the big selling points was reading all those type provider articles. Then I've tried it a couple of months ago and it was such a broken mess - not worth the time. From what I've read this isn't just my experience. With, record types, switch expressions, top level expressions, file scoped modules, global usings, etc. C# removed a lot of cruft. Roslyn source generators actually work unlike type providers. If they improved the REPL/scripting aspect of C# I think there would be very little arguments for F# other than catering to FP crowd who like to like |> to |> write |> like |> this instead of this(like(write(to(like))))
throw868788 4y ago
I've used F# in a professional job and its fine - on very large scale apps for large corps. There's features in it that I feel make certain apps much easier to write that have no equivalent in C# or C# is just starting to get them. Its also easier to teach IMO than C# since code typically uses less concepts. The usual features (e.g TP's) that are used to sell the language though I feel are oversold and tbh not the main reason F# users like the language - in fact I think TP's need an overhaul and are a distraction. Inlining code for math (which is just getting an equivalent like feature in the next C#), unions/records together, functions and type inference, leaning to compile time vs runtime dispatch in code style, etc I feel are where its strengths are at. More than features I've found for large scale projects its just easier to spot bad code in F#, less bugs have made it ot Production when .NET teams have tried it, and less of it makes it to code reviews. I've found F# tooling at least for VS Code more stable than the C# equivalent. But that's not saying much - most languages plugins for VS Code don't feel that stable to me if not JS (e.g. the Java one used to crash on me all the time). In VS Studio, Rider, etc are options. Documentation should be improved sure especially for people getting into it; but it is the smaller language and documentation goes out of date quickly. This obviously penalises the new starter without a mentor/senior dev to teach them in the job/elsewhere.

markmark 4y ago

F# is very much a second-class citizen in the Microsoft world.

moonchrome 4y ago

Every time I tried F# with .NET tooling it felt like the implementations were there to tick the "supports F#" checkbox - and nobody actually used it for the thing I tried to do because it broke really early on. Early on one of the big selling points was reading all those type provider articles. Then I've tried it a couple of months ago and it was such a broken mess - not worth the time. From what I've read this isn't just my experience. With, record types, switch expressions, top level expressions, file scoped modules, global usings, etc. C# removed a lot of cruft. Roslyn source generators actually work unlike type providers. If they improved the REPL/scripting aspect of C# I think there would be very little arguments for F# other than catering to FP crowd who like to like |> to |> write |> like |> this instead of this(like(write(to(like))))

throw868788 4y ago

I've used F# in a professional job and its fine - on very large scale apps for large corps. There's features in it that I feel make certain apps much easier to write that have no equivalent in C# or C# is just starting to get them. Its also easier to teach IMO than C# since code typically uses less concepts. The usual features (e.g TP's) that are used to sell the language though I feel are oversold and tbh not the main reason F# users like the language - in fact I think TP's need an overhaul and are a distraction. Inlining code for math (which is just getting an equivalent like feature in the next C#), unions/records together, functions and type inference, leaning to compile time vs runtime dispatch in code style, etc I feel are where its strengths are at. More than features I've found for large scale projects its just easier to spot bad code in F#, less bugs have made it ot Production when .NET teams have tried it, and less of it makes it to code reviews. I've found F# tooling at least for VS Code more stable than the C# equivalent. But that's not saying much - most languages plugins for VS Code don't feel that stable to me if not JS (e.g. the Java one used to crash on me all the time). In VS Studio, Rider, etc are options. Documentation should be improved sure especially for people getting into it; but it is the smaller language and documentation goes out of date quickly. This obviously penalises the new starter without a mentor/senior dev to teach them in the job/elsewhere.