4 ms·

The original OCaml is more interesting. It has language flexibility F# lacks, gets new features every year, crossplatform, and compiles into the native code, th

by xvilka 6y ago

The original OCaml is more interesting. It has language flexibility F# lacks, gets new features every year, crossplatform, and compiles into the native code, thus faster. Once Multicore OCaml [1] project is finished the major painpoint of it will go away. [1] https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/5898 https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/...

gameswithgo 6y ago
f# also has language flexibility that ocaml lacks. and ocaml isn’t always faster
- laylomo2 6y ago
  Always love seeing a good rivalry between siblings.
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
kyberias 6y ago
Is this competition?. F# has intentional limitations due to the decision to work on CLR.
dunefox 6y ago
> Once Multicore OCaml [1] project is finished the major painpoint of it will go away. The major pain points are the tools. I tried setting everything up two years ago, or so, and I couldn't do it. While the language might be good (modules) everything else isn't.

by xvilka 6y ago

gameswithgo 6y ago

f# also has language flexibility that ocaml lacks. and ocaml isn’t always faster

laylomo2 6y ago
Always love seeing a good rivalry between siblings.

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

kyberias 6y ago

Is this competition?. F# has intentional limitations due to the decision to work on CLR.

dunefox 6y ago

> Once Multicore OCaml [1] project is finished the major painpoint of it will go away. The major pain points are the tools. I tried setting everything up two years ago, or so, and I couldn't do it. While the language might be good (modules) everything else isn't.