XenSource (since acquired by Citrix) and their experience of using Ocaml for a major project.
cl.cam.ac.uk/~avsm2/icfp2010-xen-draft.pdfPosted Jul 2, 2010, 5:34 AM UTC
7063
cl.cam.ac.uk
This is awesome.
6
Incidentally, in case anyone is interested, the code in question is all open source, downloadable at:
The paper is mostly about the respositories xen-api.hg and xen-api-libs.hg
6
That's interesting. The ocaml stuff used to be closed source, and the open source version had XAPI written in Python. I didn't know it was all open source now.
Those XenSource guys are very smart, and their code seems to be of a much higher standard than the rest of Citrix.
1
What would jdh30 say to that? Does it mean that his problems were strictly with lablgl?
However, it transpired that the OCaml runtime was remarkably stable.
...
Despite all this testing, we have never had a single XenServer defect reported from internal testing or from the field that can be traced back to a bug in the OCaml runtime or compiler.
5
What would jdh30 say to that? Does it mean that his problems were strictly with lablgl?
Are you referring to our old Presenta product that was written in OCaml and canned due to unreliability? If so, the problem was not the OCaml runtime but LablGL and OpenGL drivers on Linux.
5
Yes, thx.
1
I should point out that the XenSource/Citrix product is precisely the opposite: an OCaml program running in an entirely custom environment right down to the custom OS.
So the probability of that working when deployed on a customer's machine is far higher than it was for our Presenta software, which suffered from design flaws in LablGL and bugs in OpenGL drivers for Linux like those from from ATi and Intel (particularly wrt OpenGL display lists) to the extent that 80% of our users experienced random segfaults.
Our best shot at fixing the problem without dropping OpenGL would have been to acquire a variety of graphics cards and do extensive testing to find out which (if any) OpenGL features were reliable across them and then write our own OpenGL bindings for OCaml (several people have done this since but I'm not sure any are maintained and OpenGL barely works on our Linux server).
In contrast, this is trivial with F# on Windows: .NET provides Windows Presentation Foundation which uses the hardware to accelerate anything when it works reliably (which it does because it is a core part of Windows Vista and Windows 7) and there are no bindings because F# can call everything directly with no risk of error.
1
Jdh30 wrote quite a bit of the code for xenserver :-)
http://xenbits.xen.org/XCP/xen-api.hg?file/8f208a2f2547/CREDITS
4
I love Ocaml and its bastard child F#.
4
Pretty interesting paper and I think a lot of the analysis would map well to less popular or emerging programming languages.
I like the insight that their choice of language actually helped them hire good people. An obvious problem with more popular languages is that although you have a wider hiring pool it is more difficult to sort the wheat from the chaff.
3
It's nice to see more real world studies come out regarding FP use, which support what many people here have been saying for a long time already.
1
0
Do you actually prefer scribd to having the PDF?
8
When I'm on a machine with no PDF reader installed, yes.
8
Funny cuz I'm on a machine with no Flash player installed.
16
This doesn't require Flash. Scribd converts many PDFs to HTML now...so for many people allergic to PDF and allergic to Flash it's actually a much better platform now.
2
To everybody: conversion is really hard, so if you spot incompatibilities, things that are crashing or come up with gibberish, please find someone to convert to another format. I'm not sure where I should point you to find a repository of those conversions, but bittorrents sound good... (with apologies to Camarade_Tux :-)
Okay, I read this thread and this was the comment that came to mind...it was amusing to me. Maybe just me.
0
Scribd used to suck ass. It was a pointless exercise. I tend to avoid it in all cases.
1
[deleted]
-2
And they wonder why Xen lost in the virtualization business marketplace, when they make these kinds of business decisions and piss away money just for the hell of it.
-7
[deleted]
-8
I really wish Ocaml was more popular. It takes a more pragmatic approach to functional programming than Haskell, making it potentially a very good compromise for the real world. Unfortunately most of the attention is directed to Haskell nowadays, making it hard to find support and libraries for common tasks in Ocaml.
Haskell people are too lazy to use a strict language.
[deleted]
Could you mention a few of those features?
Lack of support for shared-memory parallelism (or anything beyond fork really) would be the main issue.
I though for highly parallel apps, share-nothing copy-on-write was the functional way.
Because the developers and users are convinced shared memory parallelism is a bad way to write reliable programs, and it won't scale when we get dozens of cores on a chip in 2-3 years time. This precise issue was discussed in depth with the users at the OCaml Users Conference this April, including a full multicore implementation of OCaml (already written and working) as an example of what could be added.
It's simply not been added because no one wants it (outside jdh30 who doesn't use OCaml anyway - he just trolls about it).
Edit: oc4mc homepage
CPython has the same problem, so I'm not sure if this actually matters that much.
Unicode
OCaml supports Unicode just fine. Use Camomile. I wrote an entire Japanese web site in OCaml using UTF-8 with no problems.
I agree with joelthelion.
I really like Ocaml's mix of FP and OO, but I really don't care for the standard library. The Jane Street and extlib projects seem great, but I just don't have the energy to get them installed.
is too much? :-)
Cool, I've never heard of Godi. Thanks!
Except that GODI is badly broken under cygwin. I'm sick of trying to make it work, so I have resorted to waiting to have enough money to buy myself a Mac, again.
I tend to agree with that, but the language has some quite strange features, such as this one:
The default string type should really be immutable, especially in a functional programming language. Polymorphic ordering is another example which strikes me as odd, given Ocaml's rich type system.
It's also a bit disappointing that strings are limited to around16 million characters on 32 bit platforms. It may pay off eventually because you're forced to think a bit about long strings (which you have to do anyway if they grow even larger), but it's really a nuisance sometimes.
Wow, that's by far the weirdest thing I've seen in OCaml.
I preferr the idea of Standard ML over OCaml, but in practice I pretty much use Haskell. Still, OCaml was an important detour in my education. It could stand to be used more often in practice.
Sad but true. OCaml needs some basic things:
Shared heap for multicores.
Decent stdlib.
JIT-based REPL and FFI.
None of these are difficult but nobody is funding them. Frankly, I think Haskell is a waste of time and effort and am sorry to see so much funding being wasted on it, but what can you do. At least MS are funding F#...
[deleted]
Look at the reasons I use F#:
Core ML language.
Shared heap thanks to the CLR.
Robust libraries like WPF thanks to .NET.
None of these features are derived from Haskell.
If the money wasted on Haskell had been used to give OCaml a decent foundation for multicore programming, I wouldn't even care about F#.
Yes, exactly. The actual practical value is the nice features like first-class functions, tail calls and pattern matching over algebraic datatypes. None of which came from Haskell. Purity is not the point of FP.
Like what? What useful ideas have come out of Haskell over the past 20 years?
That's true, your use case does not include features derived from Haskell. F# is first and foremost influenced by OCaml.
One cannot deny F# has been influenced by Haskell, however. I had a look through the F# literature and it seems lazy data structures ("sequence expressions"?) and monads ("workflows"?) have been incorporated into F#.
"Finally, the third paradigm supported by F# is language oriented programming (the design of F# in this area is largely influenced by ML, Haskell and also by LINQ). We'll shortly discuss how the F# compiler uses these members to execute the computation expression, but let me first add a few short comments for those who are familiar with Haskell monads. The Bind and Return members specify the standard monadic operators (known from Haskell), meaning that Bind is used when we use the let! operator in the code and Return is called when the computation expression contains return and finally, the Delay member allows building monads that are executed lazily." -- Tomáš Petříček, author of Real World Functional Programming: With Examples in F# and C#
"F# also draws from Haskell particularly with regard to two advanced language features called sequence expressions and workflows." -- Syme, Granicz & Cisternino (2007)
"
member Bind: Async<'T> * ('T -> Async<'U>) -> Async<'U>Note: The computation expression syntax in F# allows the smooth embedding of computational structures known as monoids and monads. A monad is a way of automatically doing impedance matching between one kind of computation (e.g. lazy computations) and regular F# coding constructs. The impedance matching is known as "binding" and is inserted automatically by the computation expression machinery at points such as let!. The normal rule when implementing a monad in F# is that you really only need to implement Bind, Return and (optionally) a "try/with" primitive. 1" -- The F# 2.0 Language Specification (April 2010)STM, of course.
[deleted]
If you include F#, OCaml is popular and will grow substantially.
Isn't F# limited to the Microsoft platform?
F# runs to some extent on Mono which is, of course, cross platform. Moreover, Microsoft (of all people!) are actually throwing resources at fixing Mono's F# compatibility issues and testing it.
Yes. Since F# is a dialect of OCaml, MS is enlarging the pool of potential OCaml programmers, thus solving Xen's hiring problem. Think about the language, not the platform.
F# works surprisingly well on Mono.
I tried this back in January, and it all went great until I started trying to write threaded code. Then it all went very, very strange, and I retreated back to Windows where things worked as expected. Since easier concurrency is the main reason I'm interested in F# (and FP in general), this wasn't something I could let slide.
Going back to the mono website just now, it looks like they've fixed a bunch of thread-pool related bugs, so I suppose I'll give it another try at some point. Still, it left a pretty bad impression about Mono when simply wrapping Hello World in an async{} was enough to break it.
It's not how well the elephant dances, but that the elephant dances at all.
Yes
I think Ocaml shares a problem with languages like C++ or Scala, namely that of being way too large for its own good. The other issue is that a lot of the documentation used to be (not sure if it still is, haven't looked at it in a while) only available in French or pretty bad English.
[deleted]
In xenserver/xcp we use a fairly limited subset of ocaml - virtually none of the oo features and only a couple of functors.
Even if you end up only using a small subset everyone starting out in the language without support from existing coders (e.g. by starting in a company using it) will have evaluate all the language features at least once.
The OO features of OCaml seem to be rarely used in practice.
LablGTK
IIRC, Ocamlnet relies extensively on objects.
To everybody: translation is really hard, so if you spot mistakes, things that are missing or don't make sense, please mention it. I'm not sure where I should point you at but the project's bugtracker or #ocaml on freenode sound good.