3 ms·

I love OCaml. F#, if you squint, is kind of philosophically like Clojure for the CLR: it leverages a heavily object-oriented but nonetheless very powerful runti

by jolux 6y ago

I love OCaml. F#, if you squint, is kind of philosophically like Clojure for the CLR: it leverages a heavily object-oriented but nonetheless very powerful runtime to allow developers to create strongly-typed functional programs that interoperate with a massive array of first- and third-party libraries that already exist. I wouldn't go so far as to say OCaml is more interesting. F# has things like computation expressions, async, units of measure, and type providers, none of which are trivial (or exist in OCaml), several of which are incredibly influential, and all of which are interesting. The long slog towards multicore for the OCaml community has been kind of embarrassing, with Haskell having offered arguably the best concurrent and parallel programming support in all of software development for years and years now. I will also note that F# gets new features fairly frequently as well, is cross-platform, and is extremely fast by virtue of running on the CLR, which I would not underestimate: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fsharp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... The features that it is missing from OCaml are admittedly pretty major, though. Row polymorphic records and the structurally typed object system are missed, not to mention rich modules and functors.

xvilka 6y ago
Thanks for the benchmarks link! This is definitely interesting and worth investigating.
yawaramin 6y ago
OCaml has the equivalent of computation expressions since 2018: http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-syntax.html http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-s... It definitely has async: https://github.com/ocsigen/lwt https://github.com/ocsigen/lwt It doesn't have units of measure but due to strong abstraction properties of modules we can fairly easily roll abstract types. It doesn't have type providers but it does have plugins for type-directed derivation of JSON codecs, equality, comparison, printing, etc. > The long slog towards multicore for the OCaml community has been kind of embarrassing IMHO it's been refreshing to see the pushback against 'multicore at all costs'. There is a benefit to taking the time to do things the right way. OCaml is a 30+ year-old language with an even longer ML heritage. It's going to be around for a while; it doesn't need to rush into a sub-par implementation. Meanwhile, people are writing highly concurrent, multi-threaded applications with it right now, and using multiple processes just fine for parallel computing.
- jolux 6y ago
  I’m glad to see that the language is moving forward in these areas, but I don’t think you understand how F# implements units of measure. It’s not just another data type, they’re fully inferred and checked and work with generics: https://stackoverflow.com/questions/21538563/can-f-units-of-measure-be-implemented-in-ocaml https://stackoverflow.com/questions/21538563/can-f-units-of-... Type providers are a native feature, no plugins required. I have no animosity towards OCaml (in syntax and semantics, I prefer it!) but this is a bit of a stretch. I don’t think anyone would say Haskell does multicore the “wrong” way, and OCaml as you say has had decades to solve these problems. I love the language but the community is very small and the language evolution has been extremely conservative for the most part.
  - yawaramin 6y ago
    > I don’t think you understand how F# implements units of measure. It’s not just another data type, they’re fully inferred and checked and work with generics Yes, units of measure are really cool, and I understand they support dimensional analysis out of the box. It's quite unique, and I fully agree that abstract types don't fully replace them. Just saying that that's what people do in OCaml. > I don’t think anyone would say Haskell does multicore the “wrong” way And it certainly is not something that I said. > OCaml as you say has had decades to solve these problems. The 'problems' being the lack of multicore support? As I said, this is not really stopping people from getting real work done in industry–see everyone using OCaml currently in highly concurrent and multi-process parallelized applications, or in fact even people using NodeJS, Python, Ruby. > the community is very small Correct, but it is definitely growing. > and the language evolution has been extremely conservative for the most part. Not so correct. There have been massive amounts of changes in the last few years: https://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/ https://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/ And this is not even taking into account the features which OCaml had before then beyond F#: - Polymorphic variant types - Structural subtyped object types - Named arguments - Optional arguments - Functors
    - jolux 6y ago
      F# has named and optional arguments and I named everything else as real differences in my initial comment in this thread. I’ve interviewed with Jane Street and gotten an offer on the basis of my OCaml and F# skills. I understand where these ecosystems differ. I rest my case.

by jolux 6y ago

xvilka 6y ago

Thanks for the benchmarks link! This is definitely interesting and worth investigating.

yawaramin 6y ago

OCaml has the equivalent of computation expressions since 2018: http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-syntax.html http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-s... It definitely has async: https://github.com/ocsigen/lwt https://github.com/ocsigen/lwt It doesn't have units of measure but due to strong abstraction properties of modules we can fairly easily roll abstract types. It doesn't have type providers but it does have plugins for type-directed derivation of JSON codecs, equality, comparison, printing, etc. > The long slog towards multicore for the OCaml community has been kind of embarrassing IMHO it's been refreshing to see the pushback against 'multicore at all costs'. There is a benefit to taking the time to do things the right way. OCaml is a 30+ year-old language with an even longer ML heritage. It's going to be around for a while; it doesn't need to rush into a sub-par implementation. Meanwhile, people are writing highly concurrent, multi-threaded applications with it right now, and using multiple processes just fine for parallel computing.

jolux 6y ago
I’m glad to see that the language is moving forward in these areas, but I don’t think you understand how F# implements units of measure. It’s not just another data type, they’re fully inferred and checked and work with generics: https://stackoverflow.com/questions/21538563/can-f-units-of-measure-be-implemented-in-ocaml https://stackoverflow.com/questions/21538563/can-f-units-of-... Type providers are a native feature, no plugins required. I have no animosity towards OCaml (in syntax and semantics, I prefer it!) but this is a bit of a stretch. I don’t think anyone would say Haskell does multicore the “wrong” way, and OCaml as you say has had decades to solve these problems. I love the language but the community is very small and the language evolution has been extremely conservative for the most part.
- yawaramin 6y ago
  > I don’t think you understand how F# implements units of measure. It’s not just another data type, they’re fully inferred and checked and work with generics Yes, units of measure are really cool, and I understand they support dimensional analysis out of the box. It's quite unique, and I fully agree that abstract types don't fully replace them. Just saying that that's what people do in OCaml. > I don’t think anyone would say Haskell does multicore the “wrong” way And it certainly is not something that I said. > OCaml as you say has had decades to solve these problems. The 'problems' being the lack of multicore support? As I said, this is not really stopping people from getting real work done in industry–see everyone using OCaml currently in highly concurrent and multi-process parallelized applications, or in fact even people using NodeJS, Python, Ruby. > the community is very small Correct, but it is definitely growing. > and the language evolution has been extremely conservative for the most part. Not so correct. There have been massive amounts of changes in the last few years: https://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/ https://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/ And this is not even taking into account the features which OCaml had before then beyond F#: - Polymorphic variant types - Structural subtyped object types - Named arguments - Optional arguments - Functors
  - jolux 6y ago
    F# has named and optional arguments and I named everything else as real differences in my initial comment in this thread. I’ve interviewed with Jane Street and gotten an offer on the basis of my OCaml and F# skills. I understand where these ecosystems differ. I rest my case.