4 ms·
FP is great but not necessarily at all costs. OCaml is immediate by default instead of lazy, and allows imperative code with side-effects. Both escape hatches
by mbac32768 1y ago
FP is great but not necessarily at all costs.
OCaml is immediate by default instead of lazy, and allows imperative code with side-effects. Both escape hatches from the pure FP world.
So, performance is easier to reason about and you can interact with your side-effecty real world stuff without having to reorganize your whole program around the correct monad.
Most of the time you want your loops to be higher order functions but once in awhile you want to just build a vector from a for loop. OCaml let's you do it without it being a whole intervention.
- droideqa 1y agoWhat about Haskell STM versus OCaml Multicore Eio?
- kcsrk 1y agoKcas is the Haskell STM analogue in OCaml https://github.com/ocaml-multicore/kcas/ https://github.com/ocaml-multicore/kcas/
- nextos 1y agoAlso, a major differentiator is that Haskell deals with effects primarily by using monads, whereas many modern functional languages (e.g. Koka or Flix) are being designed from the ground up to use algebraic effects instead. OCaml is also embracing effects. Haskell has some effect libraries as well, but monadic code is everywhere. IMHO, as someone who loves Haskell, algebraic effects will make FP much more approachable.
- djtango 1y agoIt's really worth noting that one of the biggest real world Haskell codebases in the world (ie Standard Chartered) wrote their own compiler to make Haskell evaluation strict and make it easier to do interop with C++ Laziness by default was definitely an opinionated design choice for a language when using it in production
- tome 1y agoWhen I worked for Standard Chartered I was told that Mu, the compiler in question, was only strict because it was originally written to target an existing strict runtime (called Lambda, and Mu is the next letter in the Greek alphabet), not because they particularly wanted a strict language.
- Mk2000 1y agoI really like Ocaml, but the error handling is very bad, some libraries use Option/Result, some use exceptions, the inconsistency makes it a little hard to work with. I much prefer Rust in this regard.
- mbac32768 1y agodoesn't the Rust ecosystem also inconsistently mix Option and Result? anyway, it's a fairly trivial wrapper to handle the odd annoying thing that raises Option.try_with (fun () -> thing_that_exns ()) Result.try_with (fun () -> thing_that_exns ()) (it would be nice if you could tell if something raises by the type signature somehow though)