Real World OCaml(realworldocaml.org) |
Real World OCaml(realworldocaml.org) |
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.
"Unix system programming in OCaml", http://ocamlunix.forge.ocamlcore.org/
For future reference, all books should be listed here: http://ocaml.org/books.html
http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r...
I'd be interested to see how they compare.
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.
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.
> Felix has a better type system
What do you mean by this? From what I can see, the only way Felix encodes any form of memory safety (e.g. dangling pointers) in the type system is by garbage collection.
[1]: http://static.rust-lang.org/doc/master/extra/arc/struct.Arc....
[2]: http://static.rust-lang.org/doc/master/extra/arc/struct.RWAr...
[3]: http://static.rust-lang.org/doc/master/extra/arc/struct.Mute...
It's just annoying when people will do anything to get on the "faster than C++" wagon.
"OCaml from the very beginning" seems to focus more on teaching the language itself. If you've never used OCaml before then this might be the place to start.
"Real World OCaml" in addition to teaching the basics of the language has some intermediate-level chapters (dealing with json, S-expressions, asynchronous events, parsing), and some advanced-level chapters (GC, compiler frontend/backend). I definitely recommend reading it at some point.
That's interesting that they were booted from the shootout. I wonder what happened there. Anyway, I haven't really looked at this enough to see how its features really play out, but on the surface it looks great. Certainly as an alternative to C++ it sounds miles ahead, and indeed many of the languages being developed today are intended precisely as alternatived to C++. A guarantee of C/C++ performance or better is very enticing. :)
Why did I stick with OCaml after that? Mostly for two reasons: there are some libraries that I like (OCamlnet, Lwt, just to mention a few), and the community appears to be more active in recent years (lots of work on build systems, packaging, new libraries coming out, user meetings, etc.).
TBH I never followed the Standard ML community, so I don't know if its similar.
For the work I do (data analysis and scientific research, particularly on recommender systems, with system-building to support that), if I need concurrency, it's suitable to run the program on the JVM. So I would use Scala in that case, and OCaml would be fine for the other systems-y stuff.
I personally have taken to writing such code in Haskell these days, but that's largely to practice my FP skills in a manner that's easier to transfer back to Scala.
- you can use system threads. Yes you'll only be able to run one OCaml thread at once, but when one OCaml thread gets blocked on I/O it switches to another.
- you can do co-operative threading if you write your code in a monadic style (there are a few libraries providing this: Lwt, Async, and in some sense Equeue). Then you don't need to worry about the thread/context-switching overhead, and the event-driven architecture should allow you to scale to thousands of concurrent events. While this may sound scary at first, the syntax is quite easy to understand, and it really is a lot easier than trying to write non-blocking code in C with lots of callbacks.
In particular have a look at Ocsigen, and Eliom that provide a web-server and framework: http://ocsigen.org/tutorial/
Regarding the book have a look at the 'Concurrent Programming with Async' chapter that shows how you can write a TCP server/client that doesn't block.
Edit: Intentionally only supporting single-threaded processes is a perfectly fine design decision, however I haven't seen this argument made for OCaml, rather I've seen "multi-threading our GC would be hard" as the justification for the single-thread limitation. Admittedly it was 3-4 years ago when I last had to deal with this.