It's fascinating to see FP being used in the "real world" rather than academia! I absolutely love OCaml and use it all the time to write major projects. I've always loved the type inferencing and super strict static typing of the ML family of languages. I wish people would embrace statically typed languages more...there's a lot to be said for code correctness and OCaml does it in a very natural way. That and the compiler can usually generate significantly better performing code.
I always notice those at Jane Street rip on the OO aspects of OCaml. The place I found classes/objects to come in handy are when you write extensible software frameworks...though I agree, usually you can do without. However, it is worth taking a look at how OCaml approaches objects...quite different from what you would find in your typical C++/Java/C# style language.
The lack of concurrent garbage collector is really becoming a limitation with the trend towards higher number of cores on a single die. However, because the GC and compiler are so simple, OCaml is one of those languages where you can look at object code and understand what the compiler is doing. What's even more interesting is that even though the compiler is really simple, it does a fantastic job at optimization. The creator of the language, Xavier Leroy, is often quoted as saying that "worst case 50% performance of C code".
Oh one other thing...for those that have not tried a functional language, I think OCaml gives the best introduction. You can code imperatively with it if you want, but you'll ween yourself off of it in time in exchange for more declarative, functional techniques. Oh and you won't look back! ;)
> even though the compiler is really simple, it does a fantastic job at optimization.
The paper also refers to OCaml's simple compiler and optimizer. This is surprising, considering OCaml's fast benchmark showings and functional languages' reputation for slow, memory intensive code. Is the OCaml team researching more advanced optimizations or is "worst case 50% performance of C code" considered good enough (compared to the tradeoff of a more complex implementation)?
You know how it is with benchmarks...it can vary so much. I'm not sure how much work is done these days on the OCaml compiler. I recall there being a big debate a few years back about it, a lot of people cried foul that OCaml benchmarks were close to C/C++ speeds because of the heavy use of OCaml's imperative constructs (rather than writing functional style implementations of the code).
In my experience with OCaml, you can write efficient code that approaches C/C++ speeds if you know how functional language compilers work. The biggest performance killer in functional languages is efficiently implementing closures on a stack based machine (i.e. funarg problem). OCaml is smart in that it implements activation records on the stack if it can tell that a function won't return a closure. If you're writing in a heavily functional style, you'll inherently create a lot of closures and lots of heap-based activation records (i.e. less efficient). At the same time, the compiler can do a lot of interesting optimizations that would be difficult in an imperative language. Pretty much every OCaml book including the official manual describes all the various places where you can have performance penalties and what OCaml is doing underneath the hood. Also like any half decent functional compiler, OCaml performs a lot of inlining which results in huge performance gains.
One thing to note, a big part of the reason why OCaml as well as other ML languages and Haskell have such great performance compared to other functional languages is because of very strict and static typing. For example, one of the interesting restrictions of the OCaml type system when dealing with objects is that you cannot downcast an object once it has been upcast (i.e. like a C++ dynamic_cast). Though this restriction is annoying, the generated code never has to do any runtime type checking - everything is statically verified!
I always notice those at Jane Street rip on the OO aspects of OCaml. The place I found classes/objects to come in handy are when you write extensible software frameworks...though I agree, usually you can do without. However, it is worth taking a look at how OCaml approaches objects...quite different from what you would find in your typical C++/Java/C# style language.
The lack of concurrent garbage collector is really becoming a limitation with the trend towards higher number of cores on a single die. However, because the GC and compiler are so simple, OCaml is one of those languages where you can look at object code and understand what the compiler is doing. What's even more interesting is that even though the compiler is really simple, it does a fantastic job at optimization. The creator of the language, Xavier Leroy, is often quoted as saying that "worst case 50% performance of C code".
Oh one other thing...for those that have not tried a functional language, I think OCaml gives the best introduction. You can code imperatively with it if you want, but you'll ween yourself off of it in time in exchange for more declarative, functional techniques. Oh and you won't look back! ;)