Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Neat technology, but, even as a rather serious O'Caml fan, even going so far as to use it in production ;), I tend to avoid the FF consultancy because of things like this:

> If you would like to keep up to date with respect to HLVM development, please subscribe to The OCaml Journal.

And when I go to read the online documentation?

> The design and implementation of this high-performance garbage collected virtual machine is described in detail in the OCaml Journal articles "Building a Virtual Machine with LLVM" from January to March 2009.

If you have to subscribe to a pay journal to learn all about it, chances are very good it isn't going anywhere at all.

Also, as something of a counterpoint to the whole "CLR missing on Linux or Mac OSX"... I've not run into many CLR compatibility issues with Mono at all. Also, they're not just doing the CLR; for example they've added first-class continuations (yes, that's right: call/cc!) to the mono VM; for language implementers that's rather attractive:

http://tirania.org/blog/archive/2009/Apr-09.html



The HLVM implementation is for everyone to see at http://hlvm.forge.ocamlcore.org/ . There is a public mailing list at https://lists.forge.ocamlcore.org/pipermail/hlvm-list/ and I am sure Jon Harrop would be more than happy to discuss all technical details there.

Mono OTOH might be okayish for C#, but for instance F# so far has no open source implementation. Also Mono is lacking w.r.t. TCO and GC, so its not even close to a decent VM for functional languages.


Yes, it's 'open' -- not arguing that, nor would I dispute that Mono is far from perfect. [1]

But, like so many FF projects: is this the cart, or the horse?

In other words, this feels more like a promotional project for the consulting firm and its pay products than it does a 'real' project. I freely admit this judgement has some external bias; Jon H. has a reputation.

[1] footnote: (Of course, neither is the linked project... 128 bits for each and every pointer on a 32-bit architecture? Does that mean 256 bits per pointer on 64-bit? Yikes!)


I'm Jon Harrop. HLVM is a hobby project that I work on when I can find the time. If I could commercialize it then I would but there is no short-term way to make decent money from a VM/language that I can see.

I suggest you think carefully about when HLVM's fat references are a disadvantage compared to the alternatives and why. The real reasons are not at all what you're thinking (or what I thought for a long time).




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: