3 ms·

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

by kzisme 9y ago

mookid11 9y ago
It depends if you enjoy NullPointerExceptions.
sremani 9y ago
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.
- kzisme 9y ago
  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.
jackmott 9y ago
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#)
wyoung2 9y ago
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.

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

by kzisme 9y ago

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

mookid11 9y ago

It depends if you enjoy NullPointerExceptions.

sremani 9y ago

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.

kzisme 9y ago
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.

jackmott 9y ago

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#)

wyoung2 9y ago

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.