4 ms·
I really like F#, but it has a few major pain points that hinder adoption: The first is that once a user reads over the various functional things like let stat
by 6thaccount2 7y ago
I really like F#, but it has a few major pain points that hinder adoption:
The first is that once a user reads over the various functional things like let statements, record types, union types...etc, you still don't really know how to code in F# unless you already have a .NET and in particular C# background. Nearly all the documentation and books (I have 3 of them) assume you're a C# dev making the switch. This is similar to learning Clojure/Kotlin/Scala on the JVM without knowing any Java. Everytime I post this someone tells me that is untrue, so I give it another shot and an dissapointed. With Python, there are dozens of books written for beginners that show you the building blocks (lists, control flow, dictionaries, tuples, functions, classes, file IO...etc) and how to use the blocks to build useful programs. With F# you get three sentences in and then hear how this is just like this thing in C# that I also know nothing about.
Microsoft also seems to not be very dedicated to providing F# tooling support.
On the plus side, I've found the community to be super smart and helpful and the language itself is very beautiful from an aesthetics point of view to me somehow (just looking at a bunch of code ). In comparison to C#, there is sooo much less noise (); everywhere.
Go is a pretty simple language that compiles to static binaries. F# ain't that as there is all the bloat and baggage of .NET. Even with .NET core, that is more confusion for me.
- AdeptusAquinas 7y agoYou are not wrong. In fact I would argue it would be very hard to learn F# without knowing C# even if resources did not assume you did, since one of F#'s major strengths is the ability to use the entire .NET ecosystem just like Clojure as you said, and the .NET ecosystem is written for C# semantics (usable from F# but generally with some slight syntax switching). On the tooling front, Microsoft include it as a prime language with C# and VB.NET in dotnet core, and ship F# tools with their latest IDEs, which I appreciate and is almost more than I would expect, since their flagship is C#. It would be nice if it was better, but that would require it to be a lot more popular which is fair enough. Static binaries are something that would be real nice. I've done it with F# using CoreRT, but its certainly not as simple as Go.
- pjmlp 7y agoNot really prime still, not even on .NET Core, there are several VS tools that only work with C# and VB.NET. CLR is multiple language runtime and actually the only language that has full control over all possible bytecodes is C++/CLI, not C#. CoreRT is on its way out, going to be replaced by Crossgen. They did a talk on AOT compilation at Java Language Summit last week.
- 6thaccount2 7y agoMaybe I've been looking at it wrong. Those books don't exist as you have to go through C# first unless you're just gifted maybe. I've thought OCaml might be a good F# replacement as it has its own compiler and interpreter that doesn't need the CLR/JVM and F# was mostly based off of OCaml, but it's a little awkward to me on Windows and OCaml itself seems to be a little painful (more boilerplate than expected) for doing things like IO (which I do a lot of).
- thelazydogsback 7y agoWell, it's pretty easy to treat F# as OCaml then if you're not doing .Net interop, and mind the edge cases. Not the newest, but J.H.'s books are great: http://www.ffconsultancy.com/products/fsharp_for_technical_computing/ http://www.ffconsultancy.com/products/fsharp_for_technical_c... (I particularly like the old spiral-bound F# for Scientists.) F# is pretty close to a first-class citizen in VS and VSCode (Ionide, etc.) at this point and the community seems good -- what support are you lacking?