Why F#?

> Why F#?

I'm kinda wondering if anyone here with decent C#/.net experience can give their version of the answer?

---

The article really didn't answer its own question. It basically says "How" instead of "Why"...

...Which as someone who's spent over 20 years in C#, and tends to advocate for "functional" style, leaves me with more questions than answers!

Everything is an expression (i.e. its an actual functional programming language), and along with it comes a different way of thinking about problems. Coupled with a really good type system which has discriminated unions, you'll have much fewer bugs.

Pro tip: don't write F# like you would write C# - then you might as well write C#. Take the time to learn the functional primitives.

if I may elaborate on "everything is an expression," F# allows you to do things like (with apologies for being a tad rusty with the syntax)

  let bar = 
      if foo then  
         7  
      else  
         11

or

  let bar = 
      try
        // code that might throw
        7
      with ex ->
        11

and will ensure that both/all code branches return a compatible type for the `let` binding.

Whereas in C# you have to do like

  int bar;

  if (foo) {
     bar = 7;
  } else {
     bar = 11;
  }

And C# will let you know if you omit the `else` on accident ...

Except that most C# developers do

  int bar = 0; // or some other default value`

to get the red squiggly to go away while they type the rest of the code, unknowingly subverting the compiler's safety check.

This doesn't seem like a big deal given these examples. But it becomes a much bigger deal when the if/else grows super large, becomes nested, etc.

Also C#:

bar = foo switch

{

   true => 7,

   false => 11

}