Hacker News Reader

Comment by marvel_boy | Hacker News Reader

Newbie here. Somebody can point to useful other resources for F#?

https://fsharpforfunandprofit.com is great. I'm enjoying Don Syme's book "Expert F# 4.0" as well.

This website if one of the best I've read, and I recommend it even if you have no interest in F#. I learned more about how to write OOP and think about types than years of reading other blogs.

If you are a C# developer you may appreciate these translations I've put together:

https://github.com/rspeele/CSharpFSharpPhrasebook

This does not sell the language -- it doesn't show off anything interesting you can do in F# that you can't in C#. There are other resources for "why F#". This is for C# developers who are convinced that they want to learn, but are annoyed by not being able to quickly look up how to do the things that they're familiar with from C#.

https://fsharpforfunandprofit.com/

Seconding the f# for fun and profit suggestions, especially the railway oriented programming section, I've also heard the following is good, but I have yet to try them:

http://www.fsharpworkshop.com/ http://products.tamizhvendan.in/fsharp-applied/

Is there a really good reason to choose to use F# over C#? Or does it really just come down to preference?

It depends if you enjoy NullPointerExceptions.

The returns on choosing F# are very much reliant of level of proficiency attained.

Once you are proficient, you will write

- less code for similar functionality

- have lot less dependency cycles

- using Option types over null helps in the long run

- improvement in productivity

The only problem is that you have attain a level of proficiency and flip the "train" of thought from OOP to Functional, and that can take some good time.

Gotcha - thanks! I haven't touched functional languages other than for fun lately, so I may take a look sooner or later. I've always been interested.

pros: less typing less null pointer exceptions

cons: performance (doesn't have to be bad but if you do things idiomatically will tend to be) tooling and other externalities (better that most niche languages but not as good as c#)

Just to add to what the others have said:

1. Immutable values by default avoids whole categories of problems. Just for one example, you can't have a data race between two threads if all the public values accessible from each thread are guaranteed immutable.

2. F# forces all cases to be handled. You've doubtless run into C# code that has a switch statement that doesn't have cases for all possible inputs, and no default case. F# doesn't have a direct equivalent of "switch" at all, but it does enforce completeness in the equivalents it does have. For example, it's illegal in F# to say something like "if foo > 1 then ... elif foo < 1 ..." since that leaves the 0 case unhandled. This is not just about better compiler warnings: it's required by the very fact that "if/else" is an expression, not a statement, so all branches must produce a value for all inputs.

3. F# has units of measure data types. Ever had an application bug because you've incorrectly passed a bare "int" value holding milliseconds to a function expecting seconds? I have. F# lets you define your units as part of the data type, so that it's a compiler error to pass milliseconds to a function expecting seconds.

I could go on, but as you can see, there really are substantial differences in practice between F# and C# code.

Reply on news.ycombinator.com