It is a whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ code and has coroutines baked in. Its own demo webserver is based on coroutines. It uses a mix of lazy and eager evaluation for performance and compiles down to C++. Execution speed is comparable to C++, mostly better. Its grammar is programmable in the sense that it is loaded as a library.
With inaccuracies in analogies assumed, Felix is to C++ what F# is to C# or to some extent Scala is to Java.
It is also mostly a one man effort but with a feverish pace of development so it comes with its associated advantages and disadvantages.
Tooling info is here http://felix-lang.org/share/src/web/tools.fdoc
The author likes to call it a scripting language but it really is a fullfledged statically compiled language with a single push button build-and-execute command. http://felix-lang.org/ The "fastest" claim is a bit playful and tongue in cheek, but it is indeed quite fast and not hard to beat or meet C with.
Felix "targets" people that would like to use Haskell or Ocaml but have a ton of code in C and C++ to interface with. Felix is a C++ upgrade: it discard the syntax, but retains ABI compatibility, at quite some cost to things like safety for example.
Felix is more or less guaranteed to perform on par with C/C++ or better for the simple reason you can embed C++ directly into Felix, this works because Felix generates C++. And of course you can link to your favourite libraries with minimal syntax.
type mytype = "My::Type";
ctor mytype : int = "My::Type ($1)";
fun addup : mytype * mytype -> mytype = "$1.addup($2)";
To do something nontrivial with it you would need to be on the mailing list though.
@dllthomas as far as I know OCaML doesnt, by no standards am I an OCaML user, although want to get better.
Uh, what. Can you clarify?
Objective Caml (OCaml) is an implementation of the ML language, based on the Caml Light dialect extended with a complete class-based object system and a powerful module system in the style of Standard ML.
OCaml comprises two compilers. One generates bytecode which is then interpreted by a C program. This compiler runs quickly, generates compact code with moderate memory requirements, and is portable to essentially any 32 or 64 bit Unix platform. Performance of generated programs is quite good for a bytecoded implementation: almost twice as fast as Caml Light 0.7. This compiler can be used either as a standalone, batch-oriented compiler that produces standalone programs, or as an interactive, toplevel-based system.
The other compiler generates high-performance native code for a number of processors. Compilation takes longer and generates bigger code, but the generated programs deliver excellent performance, while retaining the moderate memory requirements of the bytecode compiler. It is not available on all arches though.
Although in practices the arches that lack a native OCaml compiler don't matter.
In RHEL we ship OCaml natively for everything except S/390 and AArch64. AArch64 will be important, but since hardware doesn't exist in a form you can buy for servers, we're happy to wait for upstream to implement this. We'll probably help them out with hardware too.
Edit: We maintain our own PPC64 backend.
Thankfully, Jane Street and the Batteries Included projects are supplementing it, but I'm still of the opinion that the standard library should be torn out and replaced with something nice.
We took an explicit decision not to use the compiler standard library in Real World OCaml, and instead work using the Core stdlib from Jane Street. I think it's quite a testament to the modular power of OCaml that they managed to not only separate the standard library from millions of lines of internal code, but also to make it so usable for external users in a brief 12 months.
There are a lot more developments coming soon, of course: see my groups research page at http://ocaml.io for some of the projects. I've been lapse at updating it in the past few months, but normal service shall resume very shortly...
fear not; support for module aliases in signatures will resolve that problem quite soon, and quite elegantly too.
ocaml.org have a list of users: http://ocaml.org/companies.html
Some "big" companies in the list: Facebook, Citrix, Dassault Système.
I've yet to play much with ocaml — we had a bit of standard ml in our programming paradigms-class at university (at the time the course used [1] "Programming Languages: Concepts and Constructs (2nd Edition) by Ravi Sethi" — now they've (unfortunately, yet understandably) replaced standard ml with Haskell). I've since had a little trouble adapting to similar-yet-different languages like both Haskell and OCaml.
[1] http://www.amazon.com/Programming-Languages-Concepts-Constru...
qcon link: http://qconsf.com/presentation/my-other-internet-mirage my slides: http://decks.openmirage.org/qcon13/
I find it interesting as it seems to generate little "buzz", but has two new books this year, and is a pre-cursor to another functional language that itself seems to be gaining traction, and is yet produced my Microsoft: F#
My observational / untested impression is OCaml seems to be more practical, and maybe a little easier to transition to for someone like me who uses mostly Python and Go, and a lot of bash/awk/sed/grep.
That said it's great to program in (like Haskell with convenient IO and semicolons) and it compiles to blazing fast executables.
Edit: Deciding which to read first.
"Unix system programming in OCaml", http://ocamlunix.forge.ocamlcore.org/
For future reference, all books should be listed here: http://ocaml.org/books.html
I also moved from OCaml to Scala for my primary programming, and have really enjoyed it. The functional goodness on top of JVM is a major win for the kinds of things that I primarily work on these days.
When I was working with OCaml, the community was going through a lot of work on figuring out what the ecosystem should look like. This involved at least two competing standard library extensions or replacements (Batteries and Jane St. Core), growing pains in packaging & deployment, etc. The language was (and still is) nice, but I could not, at the time, invest the time into dealing with the ecosystem. Things seem to have improved a lot since then, particularly with things like OPAN emerging, but Scala is still a better fit for the work I do, and Haskell has been serving me well for command-line kinds of things. But OCaml is a fine, practical language for a lot of things.
Native, stand alone binaries. High performance (not sure how the Go vs. OCaml benchmarks look right now). Good networking. More productive and less error prone than C or C++. Less verbose than Java.
Haven't written any OCaml programs, but seems to check the same boxes. Go seems to have a much better concurrency story with channels.
OCaml seems to have a much better type system and functional programming support.
Programmers are digital choreographers, carefully
balancing correctness, modularity, concurrency,
and performance. Real World OCaml teaches you how
to perform this balancing act in simple, elegant ways.
http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r...
I'd be interested to see how they compare.