Live data from Hacker News

Real World OCaml

realworldocaml.org

31–40 of 83 posts

Re: Real World OCaml

#31
post #26

Earlier quoted context omitted.

This is by choice, because single thread performance matters more, and you can use fork or MPI to scale across NUMA nodes and clusters much more scalably and safely.

Having used fork/join to parallelize an OCaml genetic algorithm, I can say from experience it is neither safe nor practical. 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…

There are now several experimental multithreaded OCaml runtimes floating around, which also have the key property of not slowing down the single-threaded case. I don't expect multicore to remain a limitation for OCaml in 2014.

Re: Real World OCaml

#32
post #7

Where is OCaml's place in the current world? 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 mos…

If you want to use a functional language on Unix, _and_ have a type system, _and_ avoid JVM/.Net then you don't have many choices. There is Haskell of course, but it is lazy by default, which makes it harder to reason about how your program will execute, and how much space it'll use. Rust is something interesting to keep an eye on, but AFAIK it is not ready yet for production use. Hence I prefer OCaml.

From the little I know of OCaml, Rust isn't really in the same category. While it has functional elements, it's really aimed at being a cleaner C++ (for instance, it doesn't have TCO).

Re: Real World OCaml

#33
For the early adopters and experimenters amongst you, you might like Felix http://felix-lang.org/share/src/web/tutorial.fdoc

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.

Re: Real World OCaml

#34
post #11

Here is a description of OCaml usage at Jane Street : https://queue.acm.org/detail.cfm?id=2038036 ocaml.org have a list of users: http://ocaml.org/companies.html Some "big" companies in the list: Facebook, Citrix, Dassault Système.

You missed Microsoft :)

http://caml.inria.fr/consortium/index.en.html

Re: Real World OCaml

#35
post #17

In my progression of Haskell-OCaml-Common Lisp-Clojure-Scala, I remember OCaml having odd edge cases, modules of functors or some such that didn't really help me in solving real world problems (this was 2007-2008 so my memory could be off). I'm currently a fan of Scala, which has all the functional and Algebraic Data Type goodness I remember from OCaml but is more "practical", more companies and projects are using it…

It depends on what you are working on. OCaml lets you interact more closely with Unix and with C libraries, if you need that. It also has a lot faster startup time and lower memory overhead, making it somewhat more suitable for writing Unix-style programs that need to run quickly with low overhead.

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.

Re: Real World OCaml

#36
post #7

Where is OCaml's place in the current world? 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 mos…

A major limiting factor is that OCaml has no support for parallelism, and due to it's use of a global interpreter lock for GC it can't run multiple threads. That said it's great to program in (like Haskell with convenient IO and semicolons) and it compiles to blazing fast executables.

Haskell has optional semicolons, though it probably isn't idiomatic to use them most of the time.

Re: Real World OCaml

#37
post #33

For the early adopters and experimenters amongst you, you might like Felix http://felix-lang.org/share/src/web/tutorial.fdoc 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++. Exec…

[deleted]

Re: Real World OCaml

#38
Ocaml: Love the language, but I don't think I've seen a worse standard library. I don't mean that it's sparse -- I don't mind that so much. I mean that it's really just badly designed. For example, global, mutable variables in a functional language? Really?

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.

Re: Real World OCaml

#39
post #38

Ocaml: Love the language, but I don't think I've seen a worse standard library. I don't mean that it's sparse -- I don't mind that so much. I mean that it's really just badly designed. For example, global, mutable variables in a functional language? Really? 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 re…

It's important to remember that the standard library is the compiler standard library. It's actually very useful to have it be so minimal when compiling OCaml to odd embedded and microkernel targets (such as our own MirageOS at https://openmirage.org).

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

Re: Real World OCaml

#40
post #38

Ocaml: Love the language, but I don't think I've seen a worse standard library. I don't mean that it's sparse -- I don't mind that so much. I mean that it's really just badly designed. For example, global, mutable variables in a functional language? Really? 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 re…

I was pretty impressed with how a single `open Core.Std` line you can basically do the whole "tear out the standard library and replace with something nice" on a per-module basis. Unfortunately it has the side-effect of making small native binaries impossible, but depending on the project it's nice to have the choice.
Post reply on HN