5 ms·

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/20

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.
    - yawaramin 6y ago
      From https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/parameters-and-arguments#named-arguments https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe... > Named arguments are allowed only for methods, not for let-bound functions, function values, or lambda expressions. > ... > Optional parameters are permitted only on members, not on functions created by using let bindings.
      - jolux 6y ago
        I concede that point.

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.
  - yawaramin 6y ago
    From https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/parameters-and-arguments#named-arguments https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe... > Named arguments are allowed only for methods, not for let-bound functions, function values, or lambda expressions. > ... > Optional parameters are permitted only on members, not on functions created by using let bindings.
    - jolux 6y ago
      I concede that point.