5 ms·

How does F# compare to OCaml or Haskell?

fsloth 7y ago
F# started as Ocaml for .Net and then added all sorts of pragmatic language constructs. I'm not an expert - F# AFAIK misses some of the higher level type theoretic stuff, but you can write 'basic' Ocaml that would be isomorphic with F#. The key high level features that F# inherits from Ocaml is a succint syntax due to type inference and 'if it compiles it's bug free' development.
- lolinder 7y ago
  Does "if it compiles it's bug free" actually work in practice? I've heard a lot of advocates for Haskell and Rust use similar lines to this, but it seems to me like it can only be true for a limited subset of all bugs. Elm's "no runtime errors in production" claim has a more reasonable-sounding scope.
  - fsloth 7y ago
    Sure, it's limited to a subset of all bugs but with a proper typesystem the category of bugs you can remove from code by just encoding the semantics and algebra into the types is quite large. So if you know how to formulate the problem so it leans heavily on the type system, you can implement something like a binary tree container, and presume it is correct when it compiles. Following the same parameters bestows rest of the codebase with this robustness. See for example the ACM article "Ocaml for the masses" by Yaron Minsky of Jane Street for very lucid practical examples https://queue.acm.org/detail.cfm?id=2038036 https://queue.acm.org/detail.cfm?id=2038036
  - fsloth 7y ago
    ... to be fair, it takes a bit getting used to a compiler that is as strict, but, when you learn how you need to implement various things, it increases your velocity since you can type stuff and not bother with too much intermediary testing because you can trust you've pretty much typed as you meant.
  - FullyFunctional 7y ago
    "It doesn't eliminate bugs, but the bugs that remain are better bugs". Better bugs in this context is bugs at a higher level, eg. application logic issues.
- bad_user 7y ago
  F# is missing OCaml modules and functors, which are the biggest reason to prefer OCaml versus other similar languages. OCaml also has structural typing via row polymorphism. And GADTs. It's easy to dismiss this as "type theoretic stuff", however these features we are talking about are very natural to use and when dealing with static typing and FP you bump into them quite a lot. And given that OCaml has some of the best type inference in the business, this happens without you even knowing about it. F# is also missing a means for doing ad-hoc polymorphism like in Haskell. So no type class capabilities, no higher kinded types either. This greatly diminishes what you can express in it and the gymnastics you have to pull off to work around it are not fun. Here's for example what you need to do in absence of GADTs: http://fssnip.net/mq http://fssnip.net/mq (n.b. this pattern is called "tagless final", resembling "visitor" from OOP land). I love this sample because if it looks complex, well it's in fact more complex than it seems, as the type system is actually not fine with this usage either, so you end up with forced type castings anyway. --- F# is a fine language, all things considering and not having certain features might be considered an advantage in certain circles. However do learn OCaml and Haskell, because they have plenty to offer and you'll learn useful abstractions that in F# are not very accessible.
  - rienbdj 7y ago
    F# has operator overloading, which is missing from ocaml?
    - phillipcarter 7y ago
      I'm not sure if I'd phrase it in terms of something missing from OCAML (or F# for that matter). There's a substantial diff between OCAML and F# at this point, once you get past "core" programming with functions in both languages. Some of the more prominent things F# has that * Computation Expressions * Perf abstractions and compiler analysis for them, namely Span<'T> * Type Providers * The .NET generics system * Anonymous Records * Slices and ranges for slicing or generating list-like data And as the parent user said, there's plenty OCAML offers that is missing from F#. I think it's a good idea to consider them quite differently, despite having the same functional core.

F# started as Ocaml for .Net and then added all sorts of pragmatic language constructs. I'm not an expert - F# AFAIK misses some of the higher level type theoretic stuff, but you can write 'basic' Ocaml that would be isomorphic with F#. The key high level features that F# inherits from Ocaml is a succint syntax due to type inference and 'if it compiles it's bug free' development.

lolinder 7y ago
Does "if it compiles it's bug free" actually work in practice? I've heard a lot of advocates for Haskell and Rust use similar lines to this, but it seems to me like it can only be true for a limited subset of all bugs. Elm's "no runtime errors in production" claim has a more reasonable-sounding scope.
- fsloth 7y ago
  Sure, it's limited to a subset of all bugs but with a proper typesystem the category of bugs you can remove from code by just encoding the semantics and algebra into the types is quite large. So if you know how to formulate the problem so it leans heavily on the type system, you can implement something like a binary tree container, and presume it is correct when it compiles. Following the same parameters bestows rest of the codebase with this robustness. See for example the ACM article "Ocaml for the masses" by Yaron Minsky of Jane Street for very lucid practical examples https://queue.acm.org/detail.cfm?id=2038036 https://queue.acm.org/detail.cfm?id=2038036
- fsloth 7y ago
  ... to be fair, it takes a bit getting used to a compiler that is as strict, but, when you learn how you need to implement various things, it increases your velocity since you can type stuff and not bother with too much intermediary testing because you can trust you've pretty much typed as you meant.
- FullyFunctional 7y ago
  "It doesn't eliminate bugs, but the bugs that remain are better bugs". Better bugs in this context is bugs at a higher level, eg. application logic issues.
bad_user 7y ago
F# is missing OCaml modules and functors, which are the biggest reason to prefer OCaml versus other similar languages. OCaml also has structural typing via row polymorphism. And GADTs. It's easy to dismiss this as "type theoretic stuff", however these features we are talking about are very natural to use and when dealing with static typing and FP you bump into them quite a lot. And given that OCaml has some of the best type inference in the business, this happens without you even knowing about it. F# is also missing a means for doing ad-hoc polymorphism like in Haskell. So no type class capabilities, no higher kinded types either. This greatly diminishes what you can express in it and the gymnastics you have to pull off to work around it are not fun. Here's for example what you need to do in absence of GADTs: http://fssnip.net/mq http://fssnip.net/mq (n.b. this pattern is called "tagless final", resembling "visitor" from OOP land). I love this sample because if it looks complex, well it's in fact more complex than it seems, as the type system is actually not fine with this usage either, so you end up with forced type castings anyway. --- F# is a fine language, all things considering and not having certain features might be considered an advantage in certain circles. However do learn OCaml and Haskell, because they have plenty to offer and you'll learn useful abstractions that in F# are not very accessible.
- rienbdj 7y ago
  F# has operator overloading, which is missing from ocaml?
  - phillipcarter 7y ago
    I'm not sure if I'd phrase it in terms of something missing from OCAML (or F# for that matter). There's a substantial diff between OCAML and F# at this point, once you get past "core" programming with functions in both languages. Some of the more prominent things F# has that * Computation Expressions * Perf abstractions and compiler analysis for them, namely Span<'T> * Type Providers * The .NET generics system * Anonymous Records * Slices and ranges for slicing or generating list-like data And as the parent user said, there's plenty OCAML offers that is missing from F#. I think it's a good idea to consider them quite differently, despite having the same functional core.