Why you should learn F#
dusted.codes
Why you should learn F#
1–10 of 179 posts
Re: Why you should learn F#
#2Re: Why you should learn F#
#3Re: Why you should learn F#
#4I do like that F# is very practical about OO though.[0] I feel that the language often strikes a balance of programming paradigms that enables me to be very productive.
[0] https://eiriktsarpalis.wordpress.com/2017/03/20/why-oo-matte...
Re: Why you should learn F#
#5That said, it's quite hard to actually get to use it in production at the places I've worked. My college's are scared of it (that is pretty reasonable, considering c# is a good stable language and my team is confident that what we develop will make the customers happy).
One thing that makes me hesitant to really try to get this adopted in my company is the tooling. My experience hasn't been great. It works, but it has been pretty unreliable. Some documentation was more focused on the "pre dotnet core" era of f#. I know i've been spoiled, but stuff like debugging, tooling and refactor tools can't touch Visual Studio.
There are some decent options, Jetbrains Rider and VS Code are a couple of them.
Small things, like creating a record type while typing is inconvenient.
type Customer = { Id: int; Name: string; Age : int; }
While typing an instance of the record
let c1 : Customer = {Id = 1;
gives you a bunch of compiler warnings, I know I'm not done, Compiler knows there are more properties. But without looking at the record type it's hard to see what order things are.
I'm not sure if this is just OCaml thing, but C kind of languages are better at predicting what you want to create. It's weird that with the very predictable Hindley–Milner type system it can't provide the developer with good information.
I know it's a small thing, but when working with large projects, I don't want to look everything up, I have the compiler have my back.
I'll really think Microsoft should help the Fsharp Foundation more, seeing what an amazing language f# is. But it really could use some more love from MS. Perhaps they should help the community be more confident that they can solve the business problems they run into. I hope Microsoft would say: "Hey this is how you create The Boring Line Of Business App, with all the bells and whistles you normally need". From how to deal with Dependencies in large projects (No, a couple of (amazing) conference video's of Mark Seemann do not give me enough confident that after 6 months of development it still is manageable)
Until the Tooling is done, I just keep enjoying the language and learn how to become a better developer with it.
Re: Why you should learn F#
#6Re: Why you should learn F#
#7Do HN users have any F# references, books, or guides they recommend? I've always been intrigued by F# but haven't found a good project / use case for it, but I suspect that's because I need to know more about it first.
https://www.manning.com/books/get-programming-with-f-sharp
Think it gives a good overview of the language and it's easy to read. Considering that after a day of working I'm not that sharp anymore it was a good read for me.
Also mentioned in the article, but Scott Wlaschin book really show the strengths of the language. Most of his stuff is great actually, but his website (FSharp for fun and profit) is not the most coherent read, I love using it as reference. I also recommend his conference talks, it has quite a bit wide range of topics.
https://pragprog.com/book/swdddf/domain-modeling-made-functi...
There are also few courses on pluralsight, but cannot remember which ones I really enjoyed.
Re: Why you should learn F#
#8Do HN users have any F# references, books, or guides they recommend? I've always been intrigued by F# but haven't found a good project / use case for it, but I suspect that's because I need to know more about it first.
Re: Why you should learn F#
#9I've never worked with dependent typing but is it true? Does the F# really take away the need for all unit testing on a project?
Re: Why you should learn F#
#10I'd always assumed F# was to C# what Scala is to Java - and I think that probably does represent their design goals, so I wonder what the different considerations were that led to them being relatively quite far apart.