4 ms·

As someone who uses 90% OCaml for work, I would strongly recommend learning Haskell instead. There are only a few very narrow fronts where I prefer OCaml, mostl

As someone who uses 90% OCaml for work, I would strongly recommend learning Haskell instead. There are only a few very narrow fronts where I prefer OCaml, mostly to do with some aspects of the module system and polymorphic variants. I strongly believe Haskell is: * More production ready (including insanely good multithreading - probably the best of any language except perhaps Erlang) * Better for learning - there are more advanced topics you can go into with Haskell, especially around the type system. There is nothing I can think of that you can learn in ocaml that you can’t learn in Haskell * More fun - if you want to, there are lots of entertaining/aesthetically pleasing things you can do with writing concise/elegant programs or proving properties using the type system Also, a lot of the putative advantages of OCaml over Haskell (e.g. “Monads seem complicated”) disappear when you use OCaml in practice. This isn’t to shit on OCaml - it’s better than 95% of languages out there. But if you’re starting from scratch with no prior investment, I would not prefer it in any scenario I can think of.

smabie 6y ago
I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive compared to Haskell or Scala. I would use Haskell, but I don't believe in tracking effects with a type system and also lazy by default causes a lot of problems. Of course I guess I could use unsafePerformIO everywhere, but that seems wrong. I've said this before and I'll say it again, modular implicits would be a game changer for OCaml.
- brmgb 6y ago
  > I've said this before and I'll say it again, modular implicits would be a game changer for OCaml. That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml. The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the time.
  - smabie 6y ago
    You're right that both of those things help OCaml out a lot. But just look at all the powerful stuff people do with Scala and implicits. All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing. All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behavior. For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. You gotta admit there's something just really awesome about that.
    - brmgb 6y ago
      > For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explicit) in its intent.
      - smabie 6y ago
        But what if you're doing a bunch of category theory stuff? Passing in the right monoid or whatever to every function is such a drag. Alternatively using local open is also a drag. Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. Not sure how it came to be that everyone totally ignores it.
        brmgb 6y ago
        But why would you be doing a bunch of category theory stuff while writing softwares ? Local open with let+ and let* make writing monadic and applicative code very easy when needed. Anything more abstract than that is over complex abstraction. OCaml is not Haskell. Trying to write Haskell code in OCaml is always going to result in something highly unidiomatic. > Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. I have written a fair bit of OCaml and never actually encountered these problems. In practice, module prefixing and local open are just fine. You rarely use more than one module per function anyway. I agree that the object system is nice but structural typing is rarely what you want and it leads to convoluted error messages.
- centimeter 6y ago
  > Of course I guess I could use unsafePerformIO everywhere I don't understand comments like this. This is obviously not something that Haskellers actually do, so the simplest conclusion (or, it seemed simplest to me starting Haskell) is that thinking this is necessary is simply indicative of not understanding how to program functionally/monadically. Indeed, once you figure out Haskell idioms this isn't ever an issue. You might also say that OCaml suffers from using unsafePerformIO everywhere, all the time. > modular implicits would be a game changer for OCaml. They would be very nice!
  - smabie 6y ago
    Of course it's not necessary. I have a lot of experience with Haskell, but I still believe the Haskell way of tracking effects puts an undue burden on the developer. I'm simply not interested in keeping track of effects and mutation. In my experience, there's little value in the monadization of all effects and also a non-trivial cost. I much prefer the traditional FP style of avoiding mutation and side-effects but not lifting them into the type system when they are necessary. This does mean you can screw up and accidentally mutate things, but I've personally never had the problem.
octachron 6y ago
I would encourage people to learn both Haskell and OCaml. Between functors, GADTs, recursive types one can already have a lot of fun with the advanced corners of OCaml type system. One point where OCaml and Haskell differs a lot is on the question of abstraction and modularity: Haskell requires a transparent world where type definitions are always visible, and abstract interfaces have always one implementation by type whereas OCaml promotes a world where implementation details might be abstracted away and behavior are not bound to types.
brmgb 6y ago
I see the Haskell community offensive on OCaml is still going strong. Having worked with both, I really like using OCaml but avoid Haskell like the plague. Being lazy by default makes it very difficult to reason about Haskell performance really fast. Admittedly another benefit of using OCaml is that you don't have to deal with the Haskell community and its obsession with looking smart. From experience, OCaml users tend to be a lot more oriented towards practical matters like, you know, building softwares rather than lenses library.
- centimeter 6y ago
  I'm not part of "the Haskell community", just a random hobbyist. You seem to have invented some sort of persecution scenario that I'm pretty sure doesn't exist. > Being lazy by default makes it very difficult to reason about Haskell performance really fast. I think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all. > practical matters like, you know, building softwares rather than lenses library. This is the classic completely idiotic "haskell isn't practical" argument. Let me tell you what's not practical: not having multithreading. Not having a well-functioning asynchronous programming system (Async sucks). Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness.
  - brmgb 6y ago
    > You seem to have invented some sort of persecution scenario that I'm pretty sure doesn't exist. It's not persecution. It's just that recently you can't have a discussion about OCaml without having an Haskell devotee dropping by and implying you should use Haskell instead generally for somewhat spurious reasons (same with Rust but the languages are so different, it's easier to ignore). It gets a bit tiring. > think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all. We might have to agree to disagree on this one. > Not having a well-functioning asynchronous programming system (Async sucks). It's a chance everyone uses Lwt then. Pretty much no one uses Async apart from Jane Street. > Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness. OCaml has multiple lenses libraries including one written by Jane Street which are not used a lot because mutations are fine. This is not being far behind. It is being practical.

smabie 6y ago

I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive compared to Haskell or Scala. I would use Haskell, but I don't believe in tracking effects with a type system and also lazy by default causes a lot of problems. Of course I guess I could use unsafePerformIO everywhere, but that seems wrong. I've said this before and I'll say it again, modular implicits would be a game changer for OCaml.

brmgb 6y ago
> I've said this before and I'll say it again, modular implicits would be a game changer for OCaml. That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml. The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the time.
- smabie 6y ago
  You're right that both of those things help OCaml out a lot. But just look at all the powerful stuff people do with Scala and implicits. All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing. All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behavior. For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. You gotta admit there's something just really awesome about that.
  - brmgb 6y ago
    > For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explicit) in its intent.
    - smabie 6y ago
      But what if you're doing a bunch of category theory stuff? Passing in the right monoid or whatever to every function is such a drag. Alternatively using local open is also a drag. Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. Not sure how it came to be that everyone totally ignores it.
      - brmgb 6y ago
        But why would you be doing a bunch of category theory stuff while writing softwares ? Local open with let+ and let* make writing monadic and applicative code very easy when needed. Anything more abstract than that is over complex abstraction. OCaml is not Haskell. Trying to write Haskell code in OCaml is always going to result in something highly unidiomatic. > Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. I have written a fair bit of OCaml and never actually encountered these problems. In practice, module prefixing and local open are just fine. You rarely use more than one module per function anyway. I agree that the object system is nice but structural typing is rarely what you want and it leads to convoluted error messages.
centimeter 6y ago
> Of course I guess I could use unsafePerformIO everywhere I don't understand comments like this. This is obviously not something that Haskellers actually do, so the simplest conclusion (or, it seemed simplest to me starting Haskell) is that thinking this is necessary is simply indicative of not understanding how to program functionally/monadically. Indeed, once you figure out Haskell idioms this isn't ever an issue. You might also say that OCaml suffers from using unsafePerformIO everywhere, all the time. > modular implicits would be a game changer for OCaml. They would be very nice!
- smabie 6y ago
  Of course it's not necessary. I have a lot of experience with Haskell, but I still believe the Haskell way of tracking effects puts an undue burden on the developer. I'm simply not interested in keeping track of effects and mutation. In my experience, there's little value in the monadization of all effects and also a non-trivial cost. I much prefer the traditional FP style of avoiding mutation and side-effects but not lifting them into the type system when they are necessary. This does mean you can screw up and accidentally mutate things, but I've personally never had the problem.

octachron 6y ago

I would encourage people to learn both Haskell and OCaml. Between functors, GADTs, recursive types one can already have a lot of fun with the advanced corners of OCaml type system. One point where OCaml and Haskell differs a lot is on the question of abstraction and modularity: Haskell requires a transparent world where type definitions are always visible, and abstract interfaces have always one implementation by type whereas OCaml promotes a world where implementation details might be abstracted away and behavior are not bound to types.

brmgb 6y ago

I see the Haskell community offensive on OCaml is still going strong. Having worked with both, I really like using OCaml but avoid Haskell like the plague. Being lazy by default makes it very difficult to reason about Haskell performance really fast. Admittedly another benefit of using OCaml is that you don't have to deal with the Haskell community and its obsession with looking smart. From experience, OCaml users tend to be a lot more oriented towards practical matters like, you know, building softwares rather than lenses library.

centimeter 6y ago
I'm not part of "the Haskell community", just a random hobbyist. You seem to have invented some sort of persecution scenario that I'm pretty sure doesn't exist. > Being lazy by default makes it very difficult to reason about Haskell performance really fast. I think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all. > practical matters like, you know, building softwares rather than lenses library. This is the classic completely idiotic "haskell isn't practical" argument. Let me tell you what's not practical: not having multithreading. Not having a well-functioning asynchronous programming system (Async sucks). Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness.
- brmgb 6y ago
  > You seem to have invented some sort of persecution scenario that I'm pretty sure doesn't exist. It's not persecution. It's just that recently you can't have a discussion about OCaml without having an Haskell devotee dropping by and implying you should use Haskell instead generally for somewhat spurious reasons (same with Rust but the languages are so different, it's easier to ignore). It gets a bit tiring. > think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all. We might have to agree to disagree on this one. > Not having a well-functioning asynchronous programming system (Async sucks). It's a chance everyone uses Lwt then. Pretty much no one uses Async apart from Jane Street. > Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness. OCaml has multiple lenses libraries including one written by Jane Street which are not used a lot because mutations are fine. This is not being far behind. It is being practical.