[Dangeranger]

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.

[throwaway7645]

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.

[batmansmk]

In France, my two first years of CS were taught in OCaml. 20k+ students are learning that way every year over there. We learn about recursions, complexity, types, compilers, language theory, graph theory ... without leaving the confort of one expressive language. I terribly missed OCaml when I had to realign with the technologies promoted in job offers and expected within the industry.

[throwaway7645]

I imagine Inria has some influence there as well as FP is good to teach in college. It's always a tough balance choosing between what is more relevant as computer science (Lisp, Prolog, OCaml...etc) versus what will get students paid money (Java, JavaScript, C++, or Python). I'm glad you had a positive experience and as i asked below, do you have the course material? And outside of the basic things you learn in school/mention above, could you use it in your daily job? Is there enough library support?

[poizan42]

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]

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]

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/ is a good place to start. http://fsharpforfunandprofit.com/ and the book form of the site's articles on github 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.

[throwaway7645]

I've gone through all of those and although it's nice, it is not what I'd call beginner friendly at all. Python has books teaching you to program in Python which is a really good way to learn a programming language. Scott's tutorial using Frankenstein to explain Monads is interesting, but I need to see how to build simple programs and modules first. How does one organize a program using pure FP, or what's the best way to mix in OOP and it is really confusing to learn all the pragmas and compiler directives. I'm not sure if I'm using the right terminology, but a lot of example code uses FSI which has to call the modules differently than if you make an executable. I really would love nothing more than F# to be my go to language, but I need a little more help getting there. I realize not all users have this problem though.

[jackmott]

i am an expert and Scott's website is usually bananas to me. For some people his approach doesn't seem to click.

A good beginner book for F# is a good idea.

[dogfishbar]

I have been teaching OCaml in CS1 at Boston College for 4 years now. Of hundreds of students who went on to learn Java in our CS2 course (joining Python-trained students from other sections of CS1), nearly unanimous happy campers. When OCaml is their first programming language, they're good to go.

[throwaway7645]

Is the course material online?

[ms013]

I've moved to doing ocaml development on my windows 10 machine under the windows subsystem for Linux. The Linux ocaml tool chain works pretty seamlessly there. Works very smoothly relative to past experiences with native ocaml compilers on windows.

[nv-vn]

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.

[haskellandchill]

OCaml from the Very Beginning is amazing beginner material.

[throwaway7645]

Thanks, I'll take a look again. He has some sample chapters posted that look really short(3 pages), but I'm guessing that is just a chapter snippet as the book itself is 200 pages?

[haskellandchill]

The book is short, but there are plenty of exercises and worked solutions in the back. Do the exercises and you will get your money's worth. I suggest buying it with the bundle because More OCaml is good also.

[nv-vn]

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]

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]

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.

[59nadir]

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.

[Drup]

I simply made my peace with the fact that popularity has little to do with merit. :)

[cies]

> The whole language is, to an extent, a compromise over various paradigms that are very nearly mutually exclusive outside of ML.

I'd say the MLs are functional-first (with imperative/OO on top). Like Ruby OO-first (with some functional on top).

For me this type of multi-paradigm is ok. It starts to hurt when all the paradigms are "first", which I see in Scala.

[akhilcacharya]

>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]

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]

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]

Good news, there is indeed Alpaca: ML for the BEAM.

https://github.com/alpaca-lang/alpaca

[LeonidasXIV]

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.

[cies]

Now that JaneStreet and Facebook are investing so much in the language, I think this feature is more likely to be implemented then ever.

[ihodes]

What does the lack of multi core keep you from doing?

[jldugger]

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]

> 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.

[hajile]

CML/MLton or Manticore will deal with most of those issues.

[lacampbell]

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.

[sitkack]

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.

[rbehrends]

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]

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]

> 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.

[scythe]

> 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).

[jldugger]

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]

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.

[zem]

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.

[ue_]

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]

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

[2] https://github.com/rizo/awesome-ocaml#web-development

[3] https://facebook.github.io/reason/ [2]

[rbehrends]

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]

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.

[rbehrends]

I am talking about both. You can have task parallelism in a distributed system with no shared memory, after all.

[ue_]

Thanks for the links and info, I'll be looking into Ocaml more.