10 ms·

OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haske

by axaxs 9y ago

OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. Does anyone have experience to say yay/nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?

0xcde4c3db 9y ago
As far as I know, Jane Street is the go-to example for commercial users. It's also unsurprisingly used within INRIA itself (for e.g. Coq).
- nv-vn 9y ago
  Facebook and Bloomberg are both industrial users as well.
  - danieldk 9y ago
    And Citrix for XenServer and xapi: https://github.com/xapi-project https://github.com/xapi-project
- fulafel 9y ago
  Docker too. https://github.com/moby/datakit https://github.com/moby/datakit https://github.com/moby/vpnkit https://github.com/moby/vpnkit
flunhat 9y ago
IMO the best part about OCaml is that it's just so fun to write code in. The type system is a million times more expressive and elegant than anything the world of Java/C# offers and more rigorous to boot. And unlike Haskell, you can cheat a little and write imperative code if you really need to. The library ecosystem could be better with OCaml though, but this is a chicken-egg problem and not an indictment of the language itself.
- deleted 9y ago
  [deleted]
- vog 9y ago
  > you can cheat a little and write imperative code if you really need to I'm not sure if this is cheating. Yes, this can be misused to introduce side-effects where there should be none. However, the strict evaluation by default (and lazy evaluation only when explicitly marked) has a huge benefit that you can not only reason easily about correctness (as in Haskell), but also reason easily about performance. The latter you can't do in Haskell without huge assumptions about the optimizer. In that regard, Haskell is similar to SQL: For small SQL queries it is pretty clear how it will be executed, but for large SQL queries it isn't clear at all which route the query planner will choose. Having said that, reasoning about performance is even better in Rust, which is heavily inspired by OCaml but allows to to reason about memory access, closing the gap that you can reason about OCaml's performance only while ignoring the GC.
  - willtim 9y ago
    You are offering a one-sided argument with regard to strict versus lazy! Lazy evaluation can make space usage difficult to reason about, but time complexity should be unchanged. Lazy evaluation, by default, is also a huge benefit to Haskell. Strict evaluation is often a huge impediment to function reuse.
    - thedufer 9y ago
      Time _complexity_ is unchanged, but laziness makes it difficult to reason about when the time will be taken. This, more so than the space usage, is the reason laziness is avoided when run time is important. > Strict evaluation is often a huge impediment to function reuse. This reads like an argument for having laziness as a language construct, rather than for having it as a default.
  - mercurial 9y ago
    > Having said that, reasoning about performance is even better in Rust, which is heavily inspired by OCaml but allows to to reason about memory access, closing the gap that you can reason about OCaml's performance only while ignoring the GC. Rust is a really different topic. It's an imperative low-level language with functional trappings, not the reverse. First off, "reasoning about memory access" really means "think about what part of code owns which data", which is non-trivial, especially considering the various ways for sharing data in Rust. Secondly, trying to do idiomatic OCaml in Rust is a terrible idea. Idiomatic OCaml is all about immutability and recursion. Immutability means allocation, and idiomatic Rust is pretty much all about avoiding allocations. And recursion is also a bad idea, especially considering Rust does not have TCO. It's not a dig at Rust, which is an exceedingly interesting language of its own, but Rust and OCaml have completely different philosophies.
logicchains 9y ago
OCaml has many of the good qualities people attribute to Go (simplicity, speed, relatively low-latency GC, well-engineered compiler&runtime) and none of the downsides. Its weakness is terrible support for multithreading (like CPython it has a global lock, such that only one thread can execute OCaml code at a time), but there's work in progress to fix that. Personally I'm of the opinion that if the developers had taken multicore more seriously a decade ago, and improved Windows support, it would/could be used now for most of the things for which Go is used.
- deleted 9y ago
  [deleted]
- mercurial 9y ago
  People often don't like the syntax too much (which is why Facebook invented Reason). There are other weaknesses as well: - the stdlib is good for data structures and not much else, which in turn gave rise to at least three different stdlib extensions - it does not have typeclasses, so implementing a generic "to_string" for your data type is not a thing - it has some really unfortunate ideas like "universal compare" - in general, there is little focus on creature comforts (this is 2017 and despite often relying on exceptions for error handling, there is no "finally" clause in the language) - in the same spirit, strings are simply bytes, it's up to the developer to ensure they have the right encoding - the language separates the code itself from the type declaration, a feature which, combined with its type inference, can make reading OCaml code similar to reading Python (in the "what type is this 'e' variable" sense) - its most widely used build system is pretty terrible That said, it has some solid features as well, despite the small community size. The packaging system is top-notch, it has good text editor integration via Merlin, and while not always numerous, the libraries are often high-quality, and it is an exceedingly pleasant language to develop with. It strikes a really good balance between solidity and ease-of-use.
  - deleted 9y ago
    [deleted]
  - arthurbrown 9y ago
BoiledCabbage 9y ago
From what I understand F# is a pretty close version of Ocaml, but has the benefit of all the libraries of the full .net ecosystem.
- 35bge57dtjku 9y ago
  If you compare the two it's obvious the F# author blatantly copied as much as he possibly could.
  - mercurial 9y ago
    F# is pretty much Microsoft's version of OCaml, but it diverges in some key features (for instance, it can do multicore but it does not have OCaml's functors).
    - Layla454 9y ago
      Im making over $7k a month working part time. I kept hearing other people tell me how much money they can make online so I decided to look into it. Well, it was all true and has totally changed my life. This is what I do... http://www.joinmate2.Com http://www.joinmate2.Com
    - davidgl 9y ago
      F# has added some new features on top of OCaml like: - Lightweight syntax - Active Patterns to extend pattern matching - Type Providers to make it easy to interact with json/sql in a type safe way It's a joy to work in https://stackoverflow.com/questions/179492/f-changes-to-ocaml#2485277 https://stackoverflow.com/questions/179492/f-changes-to-ocam...
      - nv-vn 9y ago
        F#'s features don't feel that useful after working in OCaml though. I've tried it for various projects, but OCaml is honestly just as good in all those situations. I wonder if there's some specific type of project where F#'s features will really shine.
trishume 9y ago
You might want to check out https://reasonml.github.io/ https://reasonml.github.io/. It's a new syntax and set of tools for OCaml that are better in many ways but compatible with the existing ecosystem and tools.
- openplatypus 9y ago
  DON'T! Check the Facebook licensing issues (HN is full of them today). Stay away from all-Facebook things.
seanwilson 9y ago
> OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. You should just spend a few hours and try it. Once you get used to inductive types, pattern matching, immutability and recursion over for loops there really isn't a lot of syntax to learn before you can be productive. Either way, it'll teach you to be a better coder in other languages.
tom_mellior 9y ago
> or why I should try Haskell instead Haskell has some nice things going for it. Its syntax is cleaner than OCaml's, for example. Still, it makes some things (like having a mutable variable, or a hash table) much harder than they should be. It's worthwhile looking at both over some rainy weekends. Whichever you end up preferring, you'll have learned useful things about both languages. (OCaml is better, though ;-)) > any large cleany written codebases from which to study? There is a big list of projects using OCaml at https://github.com/rizo/awesome-ocaml https://github.com/rizo/awesome-ocaml Obviously, I can't vouch for cleanly-writtenness of any of them. Whichever you study would presumably depend on your area of expertise. There are packages there for anything from theorem proving to bioinformatics to web development. If you're into compilers, you could look at the OCaml compiler itself...
- mookid11 9y ago
  > Haskell has some nice things going for it. Its syntax is cleaner than OCaml's, for example. While I find the ocaml syntax very far from perfect, the whitespace sensitivity of Haskell makes it immediately worse. What a silly design.
  - beeforpork 9y ago
    Youmeanwhitespaceisbad?C64basicrules!
  - mercurial 9y ago
    IMHO, it's not so much that as the ASCII operator galore. $, <*>, the horrible lambda syntax... Sometimes it looks an opinionated Perl.
    - ice109 9y ago
      I don't know if you've worked with a production Haskell code base but it cannot be over stated what a poor decision operator overloading is. if they got rid of that it would immediately make Haskell an order of magnitude more practical
rbehrends 9y ago
I think as a computer scientist you should really have at least some familiarity with both Haskell and one of the ML languages, just because it'll expand your thinking. Whether to invest deeply in one of them is a matter of whether you have the time (especially if it's just as a hobby) and how well one or the other matches your preferences. I don't generally evangelize OCaml – because as a language it can be a bit of a mixed bag – but end up using it a lot because in the end it's a pragmatic language and a really solid workhorse. The niche that it fills for me is that of a statically typed language with native compilation and a GC, a niche that has historically not been served all that well. Things I like: * The language itself is not too opinionated. It's a multi-paradigm, functional-first language, that allows me to use imperative or OO styles when that's the best fit. * The compiler is fast. * While the ecosystem has some gaps, it's very solid in those areas that I need (such as systems programming or language tooling). * The language does not prioritize speed at the expense of correctness; this includes the compiler. There are languages where, let's say, I have trust issues. Code quality is still pretty darn good. * I really like ML functors for parametric polymorphism. While more verbose than other approaches, they are simple and powerful. * Having a time-traveling debugger can occasionally be very helpful. * For all their warts, the language and the compiler are mature.
rmathew 9y ago
You might find these Reddit threads interesting: * OCamlers on Haskell - https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocamlers_critiques_of_haskell/ https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocam... * Haskellers on OCaml - https://www.reddit.com/r/haskell/comments/3huexy/what_are_haskellers_critiques_of_f_and_ocaml/ https://www.reddit.com/r/haskell/comments/3huexy/what_are_ha...
ernst_klim 9y ago
>or know of any large cleany written codebases from which to study? * unison (a great file sync tool for win/posix from Benjamin Pierce, the author of Software foundations and TAPL) https://github.com/bcpierce00/unison https://github.com/bcpierce00/unison * mirage (which also has a bunch of interesting subprojects, like irmin) https://github.com/mirage https://github.com/mirage * coq https://github.com/coq/coq https://github.com/coq/coq * flow https://github.com/facebook/flow https://github.com/facebook/flow * CompCert https://github.com/AbsInt/CompCert https://github.com/AbsInt/CompCert * frama-c https://github.com/Frama-C https://github.com/Frama-C * 0install https://github.com/0install/0install https://github.com/0install/0install

by axaxs 9y ago

0xcde4c3db 9y ago

As far as I know, Jane Street is the go-to example for commercial users. It's also unsurprisingly used within INRIA itself (for e.g. Coq).

nv-vn 9y ago
Facebook and Bloomberg are both industrial users as well.
- danieldk 9y ago
  And Citrix for XenServer and xapi: https://github.com/xapi-project https://github.com/xapi-project
fulafel 9y ago
Docker too. https://github.com/moby/datakit https://github.com/moby/datakit https://github.com/moby/vpnkit https://github.com/moby/vpnkit

flunhat 9y ago

IMO the best part about OCaml is that it's just so fun to write code in. The type system is a million times more expressive and elegant than anything the world of Java/C# offers and more rigorous to boot. And unlike Haskell, you can cheat a little and write imperative code if you really need to. The library ecosystem could be better with OCaml though, but this is a chicken-egg problem and not an indictment of the language itself.

deleted 9y ago
[deleted]
vog 9y ago
> you can cheat a little and write imperative code if you really need to I'm not sure if this is cheating. Yes, this can be misused to introduce side-effects where there should be none. However, the strict evaluation by default (and lazy evaluation only when explicitly marked) has a huge benefit that you can not only reason easily about correctness (as in Haskell), but also reason easily about performance. The latter you can't do in Haskell without huge assumptions about the optimizer. In that regard, Haskell is similar to SQL: For small SQL queries it is pretty clear how it will be executed, but for large SQL queries it isn't clear at all which route the query planner will choose. Having said that, reasoning about performance is even better in Rust, which is heavily inspired by OCaml but allows to to reason about memory access, closing the gap that you can reason about OCaml's performance only while ignoring the GC.
- willtim 9y ago
  You are offering a one-sided argument with regard to strict versus lazy! Lazy evaluation can make space usage difficult to reason about, but time complexity should be unchanged. Lazy evaluation, by default, is also a huge benefit to Haskell. Strict evaluation is often a huge impediment to function reuse.
  - thedufer 9y ago
    Time _complexity_ is unchanged, but laziness makes it difficult to reason about when the time will be taken. This, more so than the space usage, is the reason laziness is avoided when run time is important. > Strict evaluation is often a huge impediment to function reuse. This reads like an argument for having laziness as a language construct, rather than for having it as a default.
- mercurial 9y ago
  > Having said that, reasoning about performance is even better in Rust, which is heavily inspired by OCaml but allows to to reason about memory access, closing the gap that you can reason about OCaml's performance only while ignoring the GC. Rust is a really different topic. It's an imperative low-level language with functional trappings, not the reverse. First off, "reasoning about memory access" really means "think about what part of code owns which data", which is non-trivial, especially considering the various ways for sharing data in Rust. Secondly, trying to do idiomatic OCaml in Rust is a terrible idea. Idiomatic OCaml is all about immutability and recursion. Immutability means allocation, and idiomatic Rust is pretty much all about avoiding allocations. And recursion is also a bad idea, especially considering Rust does not have TCO. It's not a dig at Rust, which is an exceedingly interesting language of its own, but Rust and OCaml have completely different philosophies.

logicchains 9y ago

OCaml has many of the good qualities people attribute to Go (simplicity, speed, relatively low-latency GC, well-engineered compiler&runtime) and none of the downsides. Its weakness is terrible support for multithreading (like CPython it has a global lock, such that only one thread can execute OCaml code at a time), but there's work in progress to fix that. Personally I'm of the opinion that if the developers had taken multicore more seriously a decade ago, and improved Windows support, it would/could be used now for most of the things for which Go is used.

deleted 9y ago
[deleted]
mercurial 9y ago
People often don't like the syntax too much (which is why Facebook invented Reason). There are other weaknesses as well: - the stdlib is good for data structures and not much else, which in turn gave rise to at least three different stdlib extensions - it does not have typeclasses, so implementing a generic "to_string" for your data type is not a thing - it has some really unfortunate ideas like "universal compare" - in general, there is little focus on creature comforts (this is 2017 and despite often relying on exceptions for error handling, there is no "finally" clause in the language) - in the same spirit, strings are simply bytes, it's up to the developer to ensure they have the right encoding - the language separates the code itself from the type declaration, a feature which, combined with its type inference, can make reading OCaml code similar to reading Python (in the "what type is this 'e' variable" sense) - its most widely used build system is pretty terrible That said, it has some solid features as well, despite the small community size. The packaging system is top-notch, it has good text editor integration via Merlin, and while not always numerous, the libraries are often high-quality, and it is an exceedingly pleasant language to develop with. It strikes a really good balance between solidity and ease-of-use.
- deleted 9y ago
  [deleted]
- arthurbrown 9y ago

BoiledCabbage 9y ago

From what I understand F# is a pretty close version of Ocaml, but has the benefit of all the libraries of the full .net ecosystem.

35bge57dtjku 9y ago
If you compare the two it's obvious the F# author blatantly copied as much as he possibly could.
- mercurial 9y ago
  F# is pretty much Microsoft's version of OCaml, but it diverges in some key features (for instance, it can do multicore but it does not have OCaml's functors).
  - Layla454 9y ago
    Im making over $7k a month working part time. I kept hearing other people tell me how much money they can make online so I decided to look into it. Well, it was all true and has totally changed my life. This is what I do... http://www.joinmate2.Com http://www.joinmate2.Com
  - davidgl 9y ago
    F# has added some new features on top of OCaml like: - Lightweight syntax - Active Patterns to extend pattern matching - Type Providers to make it easy to interact with json/sql in a type safe way It's a joy to work in https://stackoverflow.com/questions/179492/f-changes-to-ocaml#2485277 https://stackoverflow.com/questions/179492/f-changes-to-ocam...
    - nv-vn 9y ago
      F#'s features don't feel that useful after working in OCaml though. I've tried it for various projects, but OCaml is honestly just as good in all those situations. I wonder if there's some specific type of project where F#'s features will really shine.

trishume 9y ago

You might want to check out https://reasonml.github.io/ https://reasonml.github.io/. It's a new syntax and set of tools for OCaml that are better in many ways but compatible with the existing ecosystem and tools.

openplatypus 9y ago
DON'T! Check the Facebook licensing issues (HN is full of them today). Stay away from all-Facebook things.

seanwilson 9y ago

> OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. You should just spend a few hours and try it. Once you get used to inductive types, pattern matching, immutability and recursion over for loops there really isn't a lot of syntax to learn before you can be productive. Either way, it'll teach you to be a better coder in other languages.

tom_mellior 9y ago

> or why I should try Haskell instead Haskell has some nice things going for it. Its syntax is cleaner than OCaml's, for example. Still, it makes some things (like having a mutable variable, or a hash table) much harder than they should be. It's worthwhile looking at both over some rainy weekends. Whichever you end up preferring, you'll have learned useful things about both languages. (OCaml is better, though ;-)) > any large cleany written codebases from which to study? There is a big list of projects using OCaml at https://github.com/rizo/awesome-ocaml https://github.com/rizo/awesome-ocaml Obviously, I can't vouch for cleanly-writtenness of any of them. Whichever you study would presumably depend on your area of expertise. There are packages there for anything from theorem proving to bioinformatics to web development. If you're into compilers, you could look at the OCaml compiler itself...

mookid11 9y ago
> Haskell has some nice things going for it. Its syntax is cleaner than OCaml's, for example. While I find the ocaml syntax very far from perfect, the whitespace sensitivity of Haskell makes it immediately worse. What a silly design.
- beeforpork 9y ago
  Youmeanwhitespaceisbad?C64basicrules!
- mercurial 9y ago
  IMHO, it's not so much that as the ASCII operator galore. $, <*>, the horrible lambda syntax... Sometimes it looks an opinionated Perl.
  - ice109 9y ago
    I don't know if you've worked with a production Haskell code base but it cannot be over stated what a poor decision operator overloading is. if they got rid of that it would immediately make Haskell an order of magnitude more practical

rbehrends 9y ago

I think as a computer scientist you should really have at least some familiarity with both Haskell and one of the ML languages, just because it'll expand your thinking. Whether to invest deeply in one of them is a matter of whether you have the time (especially if it's just as a hobby) and how well one or the other matches your preferences. I don't generally evangelize OCaml – because as a language it can be a bit of a mixed bag – but end up using it a lot because in the end it's a pragmatic language and a really solid workhorse. The niche that it fills for me is that of a statically typed language with native compilation and a GC, a niche that has historically not been served all that well. Things I like: * The language itself is not too opinionated. It's a multi-paradigm, functional-first language, that allows me to use imperative or OO styles when that's the best fit. * The compiler is fast. * While the ecosystem has some gaps, it's very solid in those areas that I need (such as systems programming or language tooling). * The language does not prioritize speed at the expense of correctness; this includes the compiler. There are languages where, let's say, I have trust issues. Code quality is still pretty darn good. * I really like ML functors for parametric polymorphism. While more verbose than other approaches, they are simple and powerful. * Having a time-traveling debugger can occasionally be very helpful. * For all their warts, the language and the compiler are mature.

rmathew 9y ago

You might find these Reddit threads interesting: * OCamlers on Haskell - https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocamlers_critiques_of_haskell/ https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocam... * Haskellers on OCaml - https://www.reddit.com/r/haskell/comments/3huexy/what_are_haskellers_critiques_of_f_and_ocaml/ https://www.reddit.com/r/haskell/comments/3huexy/what_are_ha...

ernst_klim 9y ago

>or know of any large cleany written codebases from which to study? * unison (a great file sync tool for win/posix from Benjamin Pierce, the author of Software foundations and TAPL) https://github.com/bcpierce00/unison https://github.com/bcpierce00/unison * mirage (which also has a bunch of interesting subprojects, like irmin) https://github.com/mirage https://github.com/mirage * coq https://github.com/coq/coq https://github.com/coq/coq * flow https://github.com/facebook/flow https://github.com/facebook/flow * CompCert https://github.com/AbsInt/CompCert https://github.com/AbsInt/CompCert * frama-c https://github.com/Frama-C https://github.com/Frama-C * 0install https://github.com/0install/0install https://github.com/0install/0install