6 ms·

After learning Elm I wanted to understand ML/OCaml a bit more, so I worked through some documentation from the OCaml site and walked away pleasantly surprised.

After learning Elm I wanted to understand ML/OCaml a bit more, so I worked through some documentation from the OCaml site and walked away pleasantly surprised. After using it for a couple of weeks I am confused why ML/OCaml aren't more popular. They are safe, functional, stable, fast, and have great tooling. They seem poised to take over the functional domain. While the syntax took a little getting used to ( emphasis on little) once you are used to it, it's very natural. Union types are wonderful, and the implicit type safety within programs was nice.

akhilcacharya 10y ago
>After using it for a couple of weeks I am confused why ML/OCaml aren't more popular For me, the issue is the GIL, although that is being worked on as we speak.
- nv-vn 10y ago
  Sadly, I'm starting to lose my hope over multicore. It's been in the works for as long as I've used the language with much speculation of it being "almost done" or "in the next release" that have failed to materialize. That said, I don't have the time to really follow along with the compiler's development so take that with a grain of salt.
  - 59nadir 10y ago
    Precisely this is the reason I've lost hope with regards to OCaml as a main language. Multicore, specifically, is one of those things that has been "close" for so long that it's looking like a Duke Nuke'em Forever feature. I keep track of OCaml regularly because I love the language and I find that it's probably the best combination of features in one place, both in terms of my enjoyment as a programmer and in terms of the performance of the language. I've come to realize later, though, that there's one glaring problem: Runtime inspection really is much more valuable to me than clean syntax and programmer comfortability when I'm building a system. With that in mind, maybe it'll never be very interesting to build a bigger system in a language like OCaml, even though it offers you a lot in terms of programmer efficiency as well as high performance. Maybe it's better to glue together OCaml programs on the BEAM (The Erlang VM) so that you're able to orchestrate them and introspect them and get proper handling and oversight of the different components of your system. Maybe all that makes multicore in OCaml mostly pointless for you in practise. Of course, not everyone will use the BEAM and OCaml together, so for them it matters a lot. I've come to see it as a worrying sign of a community that doesn't care to evolve enough, more than anything, and that's why OCaml is not as interesting as it could be. It should be said that languages that supposedly are made for building systems also lack this runtime introspection and oversight. They have no way to locate and refer to their threads and no way to automatically handle their successes and failures. These languages are wildly popular, and so none of the above apparently matters to the vast majority of people. I think it's an interesting argument around (or against?) multicore in OCaml.
    - macintux 10y ago
      Good news, there is indeed Alpaca: ML for the BEAM. https://github.com/alpaca-lang/alpaca https://github.com/alpaca-lang/alpaca
- ihodes 10y ago
  What does the lack of multi core keep you from doing?
  - jldugger 10y ago
    In web-apps architectures, you have a choice: multithread or multiprocess. Multithreading is far more memory friendly, and occasionally a bit faster, but many interpreted language runtimes aren't prepared for multithreading. Python / OCaml have a big global lock on certain things (interpreter, garbage collection) that are needed frequently enough that even requests aren't really interfering at the DB transactional level will block one another under multithreading. So instead you have to take the hit of multiprocessing, where each web worker has its own memory space and set of locks. So if you're going to justify writing a webapp in OCaml, it would be helpful if the language was more efficient than whatever your alternative is.
    - klibertp 10y ago
      > In web-apps architectures, you have a choice: multithread or multiprocess. No, the choice is definitely not that limited. Saying something like this is like saying there's no Nginx, only Apache available as an HTTP server. For the concurrent, IO-bound code you can leverage all kinds of concurrency approaches (coroutines, green threads, callbacks). In these use cases, multiple threads are actually a bad idea from the memory efficiency perspective. On the other hand, multiple threads would be viable for CPU-bound and/or long-running code were it not for the GIL, that's true. With the GIL you don't have that option and have to resort to multiprocessing. Multiprocessing is not so bad, actually, although it does make the code more complicated. Unless your problem is massively parallel (but then you'd use GPU instead), spawning n x 2 processes for n cores is definitely possible with how much RAM is available nowadays on the servers. You get optimal parallelism at the cost of serialization overhead (or other complexities if you want to directly share memory). There are some languages which do support most existing concurrency mechanisms and they may be a better fit for a particular project. However, not supporting parallelism via multi-threading hardly disqualifies any language, provided the other tools are in place, solid and widely used.
- cies 10y ago
  Now that JaneStreet and Facebook are investing so much in the language, I think this feature is more likely to be implemented then ever.
- LeonidasXIV 10y ago
  I always found that strange since Python has the same GIL and it hasn't stopped the massive adoption, same with MRI Ruby (though one could argue JRuby is more popular, but don't see any massively multicore applications in Ruby either), so that reason does not convince me.
- hajile 10y ago
  CML/MLton or Manticore will deal with most of those issues.
throwaway7645 10y ago
Crappy windows support for OCaml. F# is similar to OCaml, but is very difficult for beginners and those not familiar with .NET. I also don't see a lot of beginner material for OCaml.
- nv-vn 10y ago
  True, but at least for compilers Windows support shouldn't be a big deal. This is because the Windows support is mostly only an issue when using certain libraries, and since compilers rarely have many dependencies it's often a non-issue. The beginner material is kind of true as well, although I do believe that the little beginner material that exists for OCaml (pretty much just the official documentation/Learn OCaml and Real World OCaml) are much easier to get started with than the tutorials of many other languages. OCaml's learning material is pretty short and to-the-point, and I found it to be a good set of boot-strap knowledge: I pretty much learned the core language in 3-4 days or so and then went on to explore the various libraries, tools, and language features not covered by the basic tutorials at my own pace.
- poizan42 10y ago
  At computer science at the University of Copenhagen F# has been used for the introduction courses the past couple of years, which as far as I know has been a big success, so I'm doubtful of it not being beginner friendly
  - throwaway7645 10y ago
    Mileage is probably not representative when you're in a university setting being taught by professors in an intro course versus a professional trying to use a multitude of the data science libraries and having trouble tying it together. Python has a zillion books published and a large percentage of them are beginner oriented. F# has only a few books and they are almost all for experts.
    - jackfoxy 10y ago
      The community surrounding F# today is very supportive and helpful with people of all experience levels. Compared to when I learned F# in 2010 it is orders of magnitude easier and more social. So many resources: the F# Foundation website http://fsharp.org/ http://fsharp.org/ is a good place to start. http://fsharpforfunandprofit.com/ http://fsharpforfunandprofit.com/ and the book form of the site's articles on github https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/site-contents/index.html https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/... has great information for people at all levels. And finally just get on twitter #fsharp to start meeting people in the community.
nv-vn 10y ago
I think MLs are kind of in limbo in regards to functional vs. imperative and OO vs. procedural programming. While they offer good OO, it's utilized very little. The functional features are used a ton, but don't dare approach the complexity of Scala, Haskell, etc., which is disappointing to a lot of more advanced functional programmers. They have reasonably good facilities for imperative programming, but these are mostly frowned upon. The whole language is, to an extent, a compromise over various paradigms that are very nearly mutually exclusive outside of ML.
- Drup 10y ago
  I would actually argue the opposite: ML languages propose the sweet spot of having functional features but still being flexible. Mutability, OO and various other feature are all there just when you need them. You don't need, like in Haskell, to do incredible contortions to be able to express things naturally. Regardless which algorithm and API you want, there is a pretty good chance you can express it in OCaml naturally, and it'll almost always be reasonably efficient by default. Also, everyone underestimate modules a lot. They're the best software development tool in any language by a long shot.
  - hyperpallium 10y ago
    So, what's your answer to the question being asked, "why ML/OCaml aren't more popular" ? Sounds like you're in the same boat as the asker.
    - Drup 10y ago
      I simply made my peace with the fact that popularity has little to do with merit. :)
    - 59nadir 10y ago
      In practice languages don't need to be popular for you to use them. They might be hard sells to bosses and the like, but there is room for impopular technology in the market as well. All you need is a main advocate with enough sway with bosses and the like. There are positions at companies using niche languages. Even though most companies prefer not to make broad technical decisions (even though they have CTOs, etc.), plenty of them do and so you're not going to find them making massively concurrent backends in Java. Even in the situation where there are no jobs for a language, why would you really not use it if it's the best tool you have? The onus is not on the language/technology to make people realize it's great. The reverse is true too: It's not Java's, JavaScript's, C++, Ruby's or any other language's fault that people are stupid enough to make backends in them. Even if the majority of those languages/platforms were good it'd be stupid to use them for things they're designed not to do.
ue_ 10y ago
I've heard the concurrency situation with OCaml isn't very good, though I know nothing about that. Weirdly, this kind of bias and the idea that it doesn't have as many libraries for my particular domain (web programming) has put me off it, as much as I'd like to use it. Using functional languages without Lisp-like macros will always be sort of weird to me, like I'm missing out on something.
- nv-vn 10y ago
  Just to clarify, it's not concurrency that's the issue but parallelism. You can write nice concurrent code pretty easily, but writing code that runs on multiple cores is still a problem. Also, if you're interested in using OCaml for web programming, there is some pretty cool stuff you might wanna check out [1] [2] [3]. That said, there's no great solution to the lack of macros :/ [1] https://github.com/dannywillems/ocaml-for-web-programming https://github.com/dannywillems/ocaml-for-web-programming [2] https://github.com/rizo/awesome-ocaml#web-development https://github.com/rizo/awesome-ocaml#web-development [3] https://facebook.github.io/reason/ https://facebook.github.io/reason/ [2]
  - ue_ 10y ago
    Thanks for the links and info, I'll be looking into Ocaml more.
  - rbehrends 10y ago
    Strictly speaking, it's not parallelism, but multi-threaded code that operates on shared memory and which is not limited to arrays over scalars.
    - Symmetry 10y ago
      You're talking about data parallelism, the OP is talking about task parallelism. Since in both cases things are occurring in parallel it makes sense to use 'parallelism' as an umbrella term for both and it was clear from context here that it was task parallelism under discussion.
zem 10y ago
the toolchain was pretty damn bad for years. it's only very recently gotten better with the rise of opam, oasis and some decent build systems.
lacampbell 10y ago
Ocaml is a great language. But the sad fact is I'm not going to be as productive in it as I would be in worse languages that have more libraries and tools.
rbehrends 10y ago
As a rule, functional programming languages tend to have trouble with gaining adoption. It's simply a programming paradigm that a great many programmers don't seem to be comfortable with. Now, the ML family of languages (SML, OCaml, F#) is technically a family of multi-paradigm, functional-first languages, but that doesn't help with clearing the "functional" hurdle in popular perception.
scythe 10y ago
Like C++ and Perl, there's a bit of caution required to avoid writing unreadable OCaml code. A disadvantage of pattern matching is that it's relatively easy to write a function where you define a variable and then first access it 500 lines later. IDE support for obscure languages is also often weak or requires extensions or idiosyncratic IDEs which are unfamiliar to many people (and often you want some kind of tool to collapse a 500-line function). OCaml has good vim plugins but not everyone uses vim. That's my experience with it anyway.
- wtetzner 10y ago
  > A disadvantage of pattern matching is that it's relatively easy to write a function where you define a variable and then first access it 500 lines later. I've written plenty of OCaml, and I can't see how this would ever be a problem. Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml. An why would pattern matching cause it? Maybe I'm misunderstanding something.
  - jldugger 10y ago
    I've done it when writing translators / compilers for school. If you're pattern matching against an AST, its easy to to have a pretty big list of possible types the AST can contain. Probably this is a code smell that should be rearchitected.
    - abhirag 10y ago
      Haven't used OCaml but the recommended practice in Erlang/Elixir is to break down complex pattern matches into separate function clauses, as function calls are also driven by pattern matching.
  - scythe 10y ago
    > Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml. Me, no; my colleagues, yes. I am averse to writing long functions even more than most people. I agree with 'jldugger that this is a sign that some cleanup is needed but the point is that bad code exists in cool languages too (there are also Mondays in Australia).
sitkack 10y ago
Because of package manager and library issues. Things aren't popular because of their inherent qualities or flaws. Popularity is driven by itself and external factors.

akhilcacharya 10y ago

>After using it for a couple of weeks I am confused why ML/OCaml aren't more popular For me, the issue is the GIL, although that is being worked on as we speak.

nv-vn 10y ago
Sadly, I'm starting to lose my hope over multicore. It's been in the works for as long as I've used the language with much speculation of it being "almost done" or "in the next release" that have failed to materialize. That said, I don't have the time to really follow along with the compiler's development so take that with a grain of salt.
- 59nadir 10y ago
  Precisely this is the reason I've lost hope with regards to OCaml as a main language. Multicore, specifically, is one of those things that has been "close" for so long that it's looking like a Duke Nuke'em Forever feature. I keep track of OCaml regularly because I love the language and I find that it's probably the best combination of features in one place, both in terms of my enjoyment as a programmer and in terms of the performance of the language. I've come to realize later, though, that there's one glaring problem: Runtime inspection really is much more valuable to me than clean syntax and programmer comfortability when I'm building a system. With that in mind, maybe it'll never be very interesting to build a bigger system in a language like OCaml, even though it offers you a lot in terms of programmer efficiency as well as high performance. Maybe it's better to glue together OCaml programs on the BEAM (The Erlang VM) so that you're able to orchestrate them and introspect them and get proper handling and oversight of the different components of your system. Maybe all that makes multicore in OCaml mostly pointless for you in practise. Of course, not everyone will use the BEAM and OCaml together, so for them it matters a lot. I've come to see it as a worrying sign of a community that doesn't care to evolve enough, more than anything, and that's why OCaml is not as interesting as it could be. It should be said that languages that supposedly are made for building systems also lack this runtime introspection and oversight. They have no way to locate and refer to their threads and no way to automatically handle their successes and failures. These languages are wildly popular, and so none of the above apparently matters to the vast majority of people. I think it's an interesting argument around (or against?) multicore in OCaml.
  - macintux 10y ago
    Good news, there is indeed Alpaca: ML for the BEAM. https://github.com/alpaca-lang/alpaca https://github.com/alpaca-lang/alpaca
ihodes 10y ago
What does the lack of multi core keep you from doing?
- jldugger 10y ago
  In web-apps architectures, you have a choice: multithread or multiprocess. Multithreading is far more memory friendly, and occasionally a bit faster, but many interpreted language runtimes aren't prepared for multithreading. Python / OCaml have a big global lock on certain things (interpreter, garbage collection) that are needed frequently enough that even requests aren't really interfering at the DB transactional level will block one another under multithreading. So instead you have to take the hit of multiprocessing, where each web worker has its own memory space and set of locks. So if you're going to justify writing a webapp in OCaml, it would be helpful if the language was more efficient than whatever your alternative is.
  - klibertp 10y ago
    > In web-apps architectures, you have a choice: multithread or multiprocess. No, the choice is definitely not that limited. Saying something like this is like saying there's no Nginx, only Apache available as an HTTP server. For the concurrent, IO-bound code you can leverage all kinds of concurrency approaches (coroutines, green threads, callbacks). In these use cases, multiple threads are actually a bad idea from the memory efficiency perspective. On the other hand, multiple threads would be viable for CPU-bound and/or long-running code were it not for the GIL, that's true. With the GIL you don't have that option and have to resort to multiprocessing. Multiprocessing is not so bad, actually, although it does make the code more complicated. Unless your problem is massively parallel (but then you'd use GPU instead), spawning n x 2 processes for n cores is definitely possible with how much RAM is available nowadays on the servers. You get optimal parallelism at the cost of serialization overhead (or other complexities if you want to directly share memory). There are some languages which do support most existing concurrency mechanisms and they may be a better fit for a particular project. However, not supporting parallelism via multi-threading hardly disqualifies any language, provided the other tools are in place, solid and widely used.
cies 10y ago
Now that JaneStreet and Facebook are investing so much in the language, I think this feature is more likely to be implemented then ever.
LeonidasXIV 10y ago
I always found that strange since Python has the same GIL and it hasn't stopped the massive adoption, same with MRI Ruby (though one could argue JRuby is more popular, but don't see any massively multicore applications in Ruby either), so that reason does not convince me.
hajile 10y ago
CML/MLton or Manticore will deal with most of those issues.

throwaway7645 10y ago

Crappy windows support for OCaml. F# is similar to OCaml, but is very difficult for beginners and those not familiar with .NET. I also don't see a lot of beginner material for OCaml.

nv-vn 10y ago
True, but at least for compilers Windows support shouldn't be a big deal. This is because the Windows support is mostly only an issue when using certain libraries, and since compilers rarely have many dependencies it's often a non-issue. The beginner material is kind of true as well, although I do believe that the little beginner material that exists for OCaml (pretty much just the official documentation/Learn OCaml and Real World OCaml) are much easier to get started with than the tutorials of many other languages. OCaml's learning material is pretty short and to-the-point, and I found it to be a good set of boot-strap knowledge: I pretty much learned the core language in 3-4 days or so and then went on to explore the various libraries, tools, and language features not covered by the basic tutorials at my own pace.
poizan42 10y ago
At computer science at the University of Copenhagen F# has been used for the introduction courses the past couple of years, which as far as I know has been a big success, so I'm doubtful of it not being beginner friendly
- throwaway7645 10y ago
  Mileage is probably not representative when you're in a university setting being taught by professors in an intro course versus a professional trying to use a multitude of the data science libraries and having trouble tying it together. Python has a zillion books published and a large percentage of them are beginner oriented. F# has only a few books and they are almost all for experts.
  - jackfoxy 10y ago
    The community surrounding F# today is very supportive and helpful with people of all experience levels. Compared to when I learned F# in 2010 it is orders of magnitude easier and more social. So many resources: the F# Foundation website http://fsharp.org/ http://fsharp.org/ is a good place to start. http://fsharpforfunandprofit.com/ http://fsharpforfunandprofit.com/ and the book form of the site's articles on github https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/site-contents/index.html https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/... has great information for people at all levels. And finally just get on twitter #fsharp to start meeting people in the community.

nv-vn 10y ago

I think MLs are kind of in limbo in regards to functional vs. imperative and OO vs. procedural programming. While they offer good OO, it's utilized very little. The functional features are used a ton, but don't dare approach the complexity of Scala, Haskell, etc., which is disappointing to a lot of more advanced functional programmers. They have reasonably good facilities for imperative programming, but these are mostly frowned upon. The whole language is, to an extent, a compromise over various paradigms that are very nearly mutually exclusive outside of ML.

Drup 10y ago
I would actually argue the opposite: ML languages propose the sweet spot of having functional features but still being flexible. Mutability, OO and various other feature are all there just when you need them. You don't need, like in Haskell, to do incredible contortions to be able to express things naturally. Regardless which algorithm and API you want, there is a pretty good chance you can express it in OCaml naturally, and it'll almost always be reasonably efficient by default. Also, everyone underestimate modules a lot. They're the best software development tool in any language by a long shot.
- hyperpallium 10y ago
  So, what's your answer to the question being asked, "why ML/OCaml aren't more popular" ? Sounds like you're in the same boat as the asker.
  - Drup 10y ago
    I simply made my peace with the fact that popularity has little to do with merit. :)
  - 59nadir 10y ago
    In practice languages don't need to be popular for you to use them. They might be hard sells to bosses and the like, but there is room for impopular technology in the market as well. All you need is a main advocate with enough sway with bosses and the like. There are positions at companies using niche languages. Even though most companies prefer not to make broad technical decisions (even though they have CTOs, etc.), plenty of them do and so you're not going to find them making massively concurrent backends in Java. Even in the situation where there are no jobs for a language, why would you really not use it if it's the best tool you have? The onus is not on the language/technology to make people realize it's great. The reverse is true too: It's not Java's, JavaScript's, C++, Ruby's or any other language's fault that people are stupid enough to make backends in them. Even if the majority of those languages/platforms were good it'd be stupid to use them for things they're designed not to do.

ue_ 10y ago

I've heard the concurrency situation with OCaml isn't very good, though I know nothing about that. Weirdly, this kind of bias and the idea that it doesn't have as many libraries for my particular domain (web programming) has put me off it, as much as I'd like to use it. Using functional languages without Lisp-like macros will always be sort of weird to me, like I'm missing out on something.

nv-vn 10y ago
Just to clarify, it's not concurrency that's the issue but parallelism. You can write nice concurrent code pretty easily, but writing code that runs on multiple cores is still a problem. Also, if you're interested in using OCaml for web programming, there is some pretty cool stuff you might wanna check out [1] [2] [3]. That said, there's no great solution to the lack of macros :/ [1] https://github.com/dannywillems/ocaml-for-web-programming https://github.com/dannywillems/ocaml-for-web-programming [2] https://github.com/rizo/awesome-ocaml#web-development https://github.com/rizo/awesome-ocaml#web-development [3] https://facebook.github.io/reason/ https://facebook.github.io/reason/ [2]
- ue_ 10y ago
  Thanks for the links and info, I'll be looking into Ocaml more.
- rbehrends 10y ago
  Strictly speaking, it's not parallelism, but multi-threaded code that operates on shared memory and which is not limited to arrays over scalars.
  - Symmetry 10y ago
    You're talking about data parallelism, the OP is talking about task parallelism. Since in both cases things are occurring in parallel it makes sense to use 'parallelism' as an umbrella term for both and it was clear from context here that it was task parallelism under discussion.

zem 10y ago

the toolchain was pretty damn bad for years. it's only very recently gotten better with the rise of opam, oasis and some decent build systems.

lacampbell 10y ago

Ocaml is a great language. But the sad fact is I'm not going to be as productive in it as I would be in worse languages that have more libraries and tools.

rbehrends 10y ago

As a rule, functional programming languages tend to have trouble with gaining adoption. It's simply a programming paradigm that a great many programmers don't seem to be comfortable with. Now, the ML family of languages (SML, OCaml, F#) is technically a family of multi-paradigm, functional-first languages, but that doesn't help with clearing the "functional" hurdle in popular perception.

scythe 10y ago

Like C++ and Perl, there's a bit of caution required to avoid writing unreadable OCaml code. A disadvantage of pattern matching is that it's relatively easy to write a function where you define a variable and then first access it 500 lines later. IDE support for obscure languages is also often weak or requires extensions or idiosyncratic IDEs which are unfamiliar to many people (and often you want some kind of tool to collapse a 500-line function). OCaml has good vim plugins but not everyone uses vim. That's my experience with it anyway.

wtetzner 10y ago
> A disadvantage of pattern matching is that it's relatively easy to write a function where you define a variable and then first access it 500 lines later. I've written plenty of OCaml, and I can't see how this would ever be a problem. Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml. An why would pattern matching cause it? Maybe I'm misunderstanding something.
- jldugger 10y ago
  I've done it when writing translators / compilers for school. If you're pattern matching against an AST, its easy to to have a pretty big list of possible types the AST can contain. Probably this is a code smell that should be rearchitected.
  - abhirag 10y ago
    Haven't used OCaml but the recommended practice in Erlang/Elixir is to break down complex pattern matches into separate function clauses, as function calls are also driven by pattern matching.
- scythe 10y ago
  > Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml. Me, no; my colleagues, yes. I am averse to writing long functions even more than most people. I agree with 'jldugger that this is a sign that some cleanup is needed but the point is that bad code exists in cool languages too (there are also Mondays in Australia).

sitkack 10y ago

Because of package manager and library issues. Things aren't popular because of their inherent qualities or flaws. Popularity is driven by itself and external factors.