Why is virt-builder written in OCaml? | Hacker News Reader

Why is virt-builder written in OCaml?

rwmj.wordpress.com

60 pointsrwmj35 comments

I love OCaml as well, but haven't seen this before. It's interesting that libguestfs provides both object and module style interface and virt-builder seems to be using the object style:

http://libguestfs.org/guestfs-ocaml.3.html

Overall, great article and great code. Let's keep in mind that SML is typically taught to entry-level CS students (some of them with no programming experience) at universities like CMU, where often a term project might actually be an ML compiler in ML. It's not a terribly complex language and some limitations (which I am not going to state here) aside it has a great use to play.

It should be noted that XenServer also uses OCaml. While it's not really fair to compare Go with OCaml (the language roots are vastly different as are the philosophies -- aside from the idea that "static typing shouldn't mean typing so much you generate static electricity") both seem to do best in the "userland systems programming" niche -- that awkward place where C++ is needlessly painful, Java is ill-fitted, and python/etc... simply inappropriate.

The guestfs API and bindings in all the languages are generated -- by a large OCaml program.

https://github.com/libguestfs/libguestfs/tree/master/generat...

For an API that has 400 or so calls accessible through a dozen different programming languages, this makes sense. The bindings in each language are never out of date or wrong (except of course they can have a systematic bug, but those are much easier to fix).

This also makes it very easy to generate alternate "views" of the same API, like OCaml module vs OO views.

It is weird to hear someone say that ML is a language only you can program in. In my opinion, ML is the most readable code out there. I used to teach ML and it was much easier to grade by reading code than to run automated tests.

I believe the intended meaning was "a language that nobody else knows" rather than "a language where code is impenetrable to everyone but the author." OCaml is pretty easy, but not if you don't know it.

Programmers really ought to be fluent in half a dozen programming languages (that's using a wide definition which includes things like Makefiles and shell). OCaml is not exactly the most difficult one. Compared to things like J or FORTH, OCaml is pretty simple.

Also virt-builder is very procedural: https://github.com/libguestfs/libguestfs/blob/master/builder... It's "do this, then run this, and if this condition is true do something else". OCaml's strengths here are its brevity, speed and safety. No complicated features are used, eg. no functors, no difficult use of functions as first-class objects ...

(I'm not actually a fan of functors; I think they obscure the flow of the code, in the same way as using inheritance in OO).

> I'm not actually a fan of functors; I think they obscure the flow of the code, in the same way as using inheritance in OO

While functors aren't something to us every day, aren't they more of an equivalent to the Decorator pattern in OO (which is more about composition and inheritance of interfaces as opposed to inheritance of concrete implementations which I agree is something to avoid)?

That said, I think I see what you mean -- I've found myself using functors needlessly because I've previously used adapters in their place in Java; instead, it may have been for it for me to ask myself what the real problem I'm trying to solve is.

The code looks like a shell script turned into OCaml. I'm curious whether you tried some libraries that attempt to provide a shell-like interface (cash, shcaml) before deciding to just write it using the stdlib.

That could be because it was a shell script originally :-)

We're somewhat limited in terms of dependencies. We can add a dependency, but it needs to be available on all platforms we support (Fedora, Debian, Arch, SuSE, Gentoo, OS X would be the main ones). Of course this is an argument against OCaml, but so far we've been fine needing only a handful of libraries and liberally calling out to C.

>Compared to things like J or FORTH, OCaml is pretty simple.

Huh? FORTH is one of the most simple programming languages around.

I wrote JONESFORTH - a literate FORTH interpreter - and I really don't think it's easy. It's easy for me now .. having written a FORTH .. but I don't think that counts as easy for beginners.

It think it would be more accurate to say that Forth itself is simple in design, but it requires more learning to be effective than many languages.

An obvious note here might be that your use of OCaml here predates (for example) Go by quite a few years. Continuity is an important consideration, instead of having to rewrite your code every few years in the latest language of choice.

Right, although even if it was a straight choice of Go and OCaml, OCaml would certainly win since Go has very poor types, no type inference, requires you to put error handling everywhere. It's like they didn't understand functional languages at all. In fact, I'd just use C instead of Go because at least C is widely available and well understood.

Hey, there are valid reasons not to use Go, but don't you think you're laying it on a bit thick? A lot of those are pretty subjective, too.

My anecdata tells me that Go's types are sufficient (and sometimes even handy), error handling everywhere helps more than it hurts (and is easily ignored if you want to), and is very much not a functional language. And I would disagree with the notion that C is, on average, well-understood given how widely available it is (a nicer way of saying that C is an easy language for anyone to misunderstand). Go is comparatively simpler to 'get right' -- in my experience

Again, this is all very subjective. Still, I don't see how flaming Go alone helps highlight OCaml's advantages and contrast their tradeoffs.

Yes probably I am. I think this stems from my feeling that Go is a lost opportunity. There's room for a sane C++ replacement. OCaml hasn't made it yet, although it fits in that space [arguably]. Go tries to do that but ignores great languages that have gone before it.

I understand the confusion about the language though I don't think the goal was ever to replace C++. Go still has a managed runtime, so I can't imagine it would ever appeal to people who want to go purely native.

OCaml's type system is not particularly sophisticated for a functional language, but it's still way ahead of Go. I can't see how Go's type are comparably sufficient.

If it is a thin layer around libguestfs, why would Python be slow?

It likely wouldn't make a measurable difference in the run time. The main arguments against using Python are lack of compile-time safety and difficulty in packaging up something that calls out to C liberally as virt-builder does.

All those reasons boil down to the first one. You know and like OCaml (better than any other language, apparently), so screw everyone else.

Screw? I think you're the one who should "hand in your programmer’s card at the door" - learning enough OCaml to get started takes half a day and getting comfortable with it is a matter of weeks at most. Of course only if you are a programmer, otherwise you might be screwed.

It was exactly that level of arrogance (the last sentence in the original article) that prompted my first comment. Really, can't you promote your language without personal attacks?

Really, can't you comment on someone promoting their favorite language without accusing them of screwing everyone?

Deleted comment

> (...) I think it's clearly dying out at this point.

You seem pretty adamant -- what makes you think that? I think it's quite the opposite: the language and the community never felt as alive and thriving as they are right now.

OCaml's been around in various forms for 30 years. 20 years of continuous development on the current code base. Regular releases through all that time. In the form of ML for 40 years. What makes you think it's going to die out in the next 5 years?

Can OCaml use more than one cpu yet? (genuinely curious, not sarcastic)

Last time I looked into it, the answer was no. I vaguely recall it having to do with stdlib not being thread safe, concurrency issues with the GC, and some other stuff...

Same discussion here: https://news.ycombinator.com/item?id=6712257

OCaml still has a global lock, but there are plenty of ways to do multiprocess concurrency (like Python).

OCaml is a good language, but I agree that it's dying out. Its primary market has generally been academics, and that group has almost completely standardized on Haskell, which is a better language in almost every respect.

Haskell is nice and all, but it's hardly better in every respect. To name a few problems with Haskell relative to OCaml:

- pervasive use of laziness makes space utilization hard to reason about

- Highly complex runtime (mostly due to the need to work around laziness), which makes it harder to trust the correctness of the overall system and to and understand performance

- Significantly more complicated type system, which has its ups and downs. It surely makes the language more complicated to learn in and use in many cases. Benjamin Pierce, no slouch himself, has pointed out that he sometimes has to go read a research paper or two to understand some new library.

- Enforced type-level separation between pure and unpure code, which again, has its ups and downs.

Haskell is a great language. But it surely doesn't dominate OCaml.

And the OCaml community is doing quite well of late, as far as I can tell. There's a lot of new energy in the last few years, with great progress in both the core language and in the surrounding infrastructure.

It's worth pointing out that we've written vast amounts of OCaml in Xen/XenServer from about 2005 (now used in lots of public cloud installations like Rackspace), and much of this choice was inspired by Richard's blogging/code to show how it could be done.

OCaml is almost 20 years old now, which is about the right amount of time to start trusting a language for mission critical code :)

Some of our experiences in Xen that we wrote up for ICFP 2010: http://anil.recoil.org/papers/2010-icfp-xen.pdf

And lots of source code: https://github.com/xapi-project https://github.com/mirage

He could, you know, not have released it as open source if he really wanted to screw everyone else.

execution speed is objective

Screw everyone else?

Reply on news.ycombinator.com