Look, I love OCaml and it's my favorite language syntax-wise, but the real big elephant in the room is not its JS-backend maturity. Rather it doesn't have kernel thread support...all threads are user-level just like Python due to a global lock for garbage collection. This means threads do not run concurrently across multiple cores. This is UNACCEPTABLE in 2014 - roughly 8 years since processors went multi-core. Intel is talking about having hundreds of cores on a single die by next decade and having programs that can't take advantage of that is extremely limiting.<p>Xavier Leroy (the creator of OCaml) and his team at INRIA didn't think this was a big deal because when they were writing this stuff, processors were single core and had been since the beginning. Sure there were multiprocessor machines (not the same as multicore as there are multiple die), but those were only meant for servers/workstations. OCaml seemed very promising around 2006, the peak and end of the single core era with the Intel Pentium 4. What made OCaml so impressive was not only was it this beautifully simple, high-level functional language, but that the native compiler produced very fast code that was comparable to C/C++ performance. However, as multicore processors were introduced (Intel Core, Core 2), not having this capability made writing new code in OCaml less appealing. There are solutions like MPI, but that's lame. The same excuses you hear in the Python world about having true multithreading you hear in the OCaml world. Microsoft was able to do it with F#, which is essentially a clone of Caml by targeting their .NET CLR. Haskell is able to do it with GHC.<p>I still think OCaml is a wonderful language -- not having true multithreading doesn't make it useless. However, to me it has become more like a statically-typed Python which I can use for scripting. Having to use hacks like MPI to do multicore processing is a huge turn off in a multicore world. This is again nothing against the language, but the standard implementation needs a concurrent garbage collector and kernel threads. Otherwise I think OCaml may be doomed to irrelevance in the long run, which would be truly sad.
I'm glad that the author is picking up a new functional programming language, but choosing OCaml over Haskell because of support for the Javascript implementations strikes me as choosing a BMW over a Mercedes[0] because of the number of cupholders it has.<p>If you don't have a particular goal in mind (ie, "I work at Jane Street and need to be compatible with our existing code"), there are a number of other factors in the OCaml vs. Haskell discussion that are far more important.<p>> JS is the only realistic way to write web apps<p>Javascript is the only realistic way to write <i>the front-end</i> of webapps. But that doesn't mean you're wedded to it for your backend technology. And I don't think <i>either</i> OCaml or Haskell have sufficiently advanced DOM bindings, etc. that I'd recommend using either one for client-side work in the browser.<p>[0] I'm not sure if this is a flamewar topic for car nerds - my point is to pick two high-end luxury cars that are both well-respected and each have their own merits.
Felix is to C++ what F# is to C# <a href="http://felix-lang.org/share/src/web/tut/tutorial.fdoc" rel="nofollow">http://felix-lang.org/share/src/web/tut/tutorial.fdoc</a> (I am not the author, just excited about this language) OCaML programmers will feel immediately at home.<p>It is a mature yet actively developed whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ and has coroutines and threads baked in, although use of threads is somewhat discouraged. It has type-classes as well as modules. Functions written in it may be exported as a CPython module. This might be useful if one wants to gradually transition from a Python based src tree.<p>It uses a mix of lazy and eager evaluation for performance and compiles down to C++. Execution speed is comparable to hand written C++, mostly better. Its grammar is programmable in the sense that it is loaded as a library. So in the same way that languages may acquire libraries, Felix may acquire domain specific syntax.<p>It is also mostly a one man effort but with a feverish pace of development so it comes with its associated advantages and disadvantages.<p>Tooling info is here <a href="http://felix-lang.org/share/src/web/ref/tools.fdoc" rel="nofollow">http://felix-lang.org/share/src/web/ref/tools.fdoc</a><p>The author likes to call it a scripting language but it really is a full-fledged statically compiled language with a single push button build-and-execute command. <a href="http://felix-lang.org/" rel="nofollow">http://felix-lang.org/</a> The "fastest" claim is a bit playful and tongue in cheek, but it is indeed remarkably fast.
If ocaml is a language waiting for a killer app, this might be it: <a href="http://www.openmirage.org/" rel="nofollow">http://www.openmirage.org/</a><p>There was a presentation at the FP eXchange in London
last Friday about mirage and many a mind was blown!
I've found it interesting that OCaml hasn't had more interest given the amount of recent momentum in Haskell.<p>Haskell is an Ivory Tower. The features that generally draw one to the language also tend to be the things that eventually push one away. Haskell has grown a lot over the years however as the language evolves to allow general programming within a pure framework.<p>OCaml on the other hand tends to make a compromise, acknowledging that the programmer occasionally needs a different tool for the job. OCaml allows the programmer to opt into things like mutability and objected oriented code when the need arises. These compromises can also be seen as the languages downside however.<p>I find it interesting that the driver for the author into OCaml is JavsScript... but it's nice to see OCaml come up a bit more often. :)
For me Scala has been the not-quite-as-good-as-haskell-but-more-industrially-acceptable language. I'd be very interested to see a more neutral comparison of functional languages for compile-to-JS, because if anything Haskell seems more popular for that - I hadn't heard anything about compiling OCaml to JS before this.
OCaml is actually taught in the second level computer science course at my university. I think its a great language for learning topics like recursion especially with its pattern matching. Its also a great intro to functional programming
This might be entirely superficial of me, but I always preferred Haskell over OCaml simply because OCaml required me to type ";;" after every line.<p>The only real reason that I can see to choose OCaml over Haskell is that if you learn OCaml, you might be able to work at Jane Street. Is there a strong argument for abandoning my Haskell-ing for OCaml?
OCaml is Object Caml right? What about SML? I always loved SML, but it never got any traction at all. The O in Ocaml always turned me off, they cluttered up the syntax with all the object notation.<p>Does anyone have any insight into why OCaml rose to (relative) prominence and not SML?
Considering how strongly opposed the author is to dynamic typing, I'm actually kind of surprised they'd consider OCaml's type system to be acceptable.<p>Technically, yes, it's a statically typed system. But its use of structural typing instead of nominative typing effectively means it takes half the compiler assistance you can get out of static type checking and chucks it out the window. Using structural typing means that a type is nothing more than the sum of its parts; nominative typing makes it possible to add further specificity to types by naming them. This is huge. A language that doesn't do this is a language that can't be taught to understand the difference between 12 meters and 12 Newtons.
"...Facebook created ... a statically typed PHP variant..." - so happy to see another major tech company understand the merits of static typing.
How do those "to js" code generator behave when used together with frameworks like backbone or angular ?<p>I know things like typescript or dart have special versions of the framworks, but i'm curious to know how the ocaml to js tools behave ( since i've searched for a decent strongly typed server side technology for years, that would be an argument for me to try that language).
Here's the plan -- eliminate perl, python, ruby, php or java or any slow-starting jvm-based language(the featureless landscape of clojure for example), and use just bash, sed, awk, ocaml(to replace the fear of 'C'), and we can also do f# on windows, so there would be crossover between the worlds and peace throughout the land.