4 ms·

> F# is underwhelming by comparison with Scala Please elaborate. This is the first I have heard from someone experienced in both F# and Scala to assert this.

louthy 9y ago
I like F# but the lack of higher kinds means F# is mostly just C# with a teaser grammar. It doesn’t really allow for a fundamentally different library envronment.
- akra 9y ago
  Disagree as someone who has programmed in both Scala and F#; I found F# pretty much could do the same things just in different ways. In F# I found more ways to squeeze performance than in Scala which by comparison is bloated. For the data applications ive written F# wins usually especially with ad-hoc tactical apps and in my experience was easier to teach than Scala which is not as coherent of a language.
  - louthy 9y ago
    > could do the same just in different ways Write a function that works with any monad? No? Write a function that works with any numeric type? No? You can fake type-classes, but it’s in no way a first class citizen. You can’t easily fake higher kinds. You may not need those features, it doesn’t make my original statement any less true.
    - akra 9y ago
      I agree with the first missing feature as you state; I just don't know how much value-add those features actually add in real world apps - often people use them in weird and unintitutive ways as well. F# has other features that other languages don't have as well. I find the workflow syntax eliminates some of the need for the first; and I find I can write functions that work with most numeric types at least a lot more so than C#/Java/etc. As a simple example the in-built F# library comes with functions that work on most number types (e.g SumBy works with anything that supports (+) including my own types). Sure there might be advanced examples that I wish I could do but they don't come often. I do find F# more concise, generally less "smart" and more explicit than Scala code which I think is a good thing. I've seen some funky Scala code in the past. Ease of code/learning/etc, and a maintainable codebase at least for me trumps features most of the time.

louthy 9y ago

I like F# but the lack of higher kinds means F# is mostly just C# with a teaser grammar. It doesn’t really allow for a fundamentally different library envronment.

akra 9y ago
Disagree as someone who has programmed in both Scala and F#; I found F# pretty much could do the same things just in different ways. In F# I found more ways to squeeze performance than in Scala which by comparison is bloated. For the data applications ive written F# wins usually especially with ad-hoc tactical apps and in my experience was easier to teach than Scala which is not as coherent of a language.
- louthy 9y ago
  > could do the same just in different ways Write a function that works with any monad? No? Write a function that works with any numeric type? No? You can fake type-classes, but it’s in no way a first class citizen. You can’t easily fake higher kinds. You may not need those features, it doesn’t make my original statement any less true.
  - akra 9y ago
    I agree with the first missing feature as you state; I just don't know how much value-add those features actually add in real world apps - often people use them in weird and unintitutive ways as well. F# has other features that other languages don't have as well. I find the workflow syntax eliminates some of the need for the first; and I find I can write functions that work with most numeric types at least a lot more so than C#/Java/etc. As a simple example the in-built F# library comes with functions that work on most number types (e.g SumBy works with anything that supports (+) including my own types). Sure there might be advanced examples that I wish I could do but they don't come often. I do find F# more concise, generally less "smart" and more explicit than Scala code which I think is a good thing. I've seen some funky Scala code in the past. Ease of code/learning/etc, and a maintainable codebase at least for me trumps features most of the time.