News for hackers. Stuff that matters.
Re:Why F#? by gwbas1c on Tuesday April 01, 2025 @09:34AM (#43546618)
> 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!

Re:Why F#? by malakai521 on Tuesday April 01, 2025 @11:52AM (#43548267)
A nicer, cleaner and simpler syntax, superior pattern matching, active patterns, discriminated unions and computation expressions
Re:Why F#? by int_19h on Tuesday April 01, 2025 @12:58PM (#43549041)
C# has the equivalent of active patterns these days.
Re:Why F#? by malakai521 on Tuesday April 01, 2025 @03:21PM (#43550425)
It does not
Re:Why F#? by kowalgta on Tuesday April 01, 2025 @11:25AM (#43547924)
I've worked with .net professionally for almost 20 years. At the beginning with C# while last decade almost exclusively with F#.

F# is just a better language. Simpler, more concise, more readable with stronger type safety. I will never go back to writing C# as I'm finding it too frustrating at times and unproductive.

Re:Why F#? by Foofoobar12345 on Tuesday April 01, 2025 @12:37PM (#43548811)
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.

Re:Why F#? by arwhatever on Tuesday April 01, 2025 @05:09PM (#43551372)
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.

Re:Why F#? by DeathArrow on Wednesday April 02, 2025 @11:06AM (#43557515)
Also C#:

bar = foo switch

{

   true => 7,

   false => 11

}
Re:Why F#? by arwhatever on Wednesday April 02, 2025 @01:13PM (#43558937)
Ah yes that is definitely a nice addition to the C# language, albeit still with a couple of shortcomings compared to F#:

1. It doesn’t support code blocks, so if you need multiple lines or statements you have to define a function elsewhere. 2. To get exhaustiveness checking on int-backed enums you have to fiddle with compiler preprocessor directives.

And for #2 any data associated with each enum variant is left implied by C# and has to be inferred from a reading of the surrounding imperative code, whereas in F# the union data structure makes the relationship explicit, and verifiable by the compiler.