9 ms·

Python to OCaml: Retrospective

235 points by Envec83 12y ago

ColinWright 12y ago
This was a fascinating read. What I'd like to see more of is how the migration was managed, concentrating on how the mix of the two languages was managed. It talks about replacing functions and using JSON to glue them together and/or allow them to communicate. I'd like to know more about that. Have I missed something? Regardless, excellent write-up. Thank you.
- talex5 12y ago
  Running both in a single process looked tricky because we need to work with the already-installed Python version, which could be 2.6, 2.7, 3.3, etc... so we'd have to provide a separate Python module for each one to do that. Instead, the OCaml created a pair of pipes and spawned a Python subprocess (you need to use two pipes, not a single socket, because Windows doesn't support Unix sockets). The protocol was asynchronous (replies can arrive out of order). Although the original JSON bridge is now gone, the new "0install slave" command (which allows other programs to control a 0install subprocess) uses a very similar system. It's documented here: http://0install.net/json-api.html http://0install.net/json-api.html
spenrose 12y ago
A year. A year of an apparently excellent programmer's output -- perhaps 2% of everything he will ever accomplish. To port a stable project to an 18 year old language.
- lucian1900 12y ago
  Considering most languages (even most new ones) ignore many more decades of programming language research, 18 years is pretty good: it was cutting edge PL research at the time.
  - trurl 12y ago
    OCaml hasn't stood still either. The latest releases take advantage of some "fairly recent" research. Python on the other hand didn't even take advantage of cutting edge research at the time it was created, and as far as I can tell hasn't since.
- Igglyboo 12y ago
  Python itself is 23 years old and older than OCaml. Java, C, C++ are also older than OCaml and all 4 are highly used today. I don't think language age has any bearing on quality or usefulness.
  - toolslive 12y ago
    Actually, the core of the language is way older. see http://en.wikipedia.org/wiki/Caml_Light http://en.wikipedia.org/wiki/Caml_Light and it can be considered a dialect of ML, which is even older (from 1973).
- hvs 12y ago
  Youth, for a programming language (and many other things), is not a positive benefit.
- zem 12y ago
  and in which he gained a massive speedup in the project, made it a lot easier to maintain and extend, learnt a lot about ocaml, and finally managed to get a really exciting job due to the exposure his blog gave him.
  - spenrose 12y ago
    Wow, hate-haters gonna hate my hate. The slowest metric for the old code is about 1/3 of a second -- how much benefit does slicing that deliver in real world 0install invocations? "Easier to maintain and extend" -- well, he just cut the population of potential contributors to the project by a factor of 1000. The exciting job he got because it required knowing OCaml, and he spent a year advertising himself as a competent OCaml hacker. I find it very strange to care more about what language a project is written in than what the project actually does.
    - toolslive 12y ago
      I'm going to feed the troll here, but "cut the population of potential contributors to the project by a factor 1000" is a flawed argument : The value of potential contributors is very low. You're better of trying to increase the comfort and power of the _current_ contributors.
    - orthecreedence 12y ago
      > hate-haters gonna hate my hate Yeah, and fanbois gonna fanboi. He found something that works better for his use case. Sure, Python has has more programmers available, but that's because it's the flavor of the week (thanks to Google, let's be honest). In 3 years it may be the language time forgot. It makes a lot more sense to pick something you enjoy programming in and makes your life easier than something that everyone else thinks is the shit. Python has its place, and that place is not everywhere.
  - gbog 12y ago
    Easier to maintain? Well at least you should add that this move from python to ocaml made it much harder to find someone able to maintain this project.
- SloopJon 12y ago
  During which time he became proficient in the language and landed what sounds like a pretty cool job.
- _random_ 12y ago
  The thing is that strong static inference beats dynamicity.
  - klibertp 12y ago
    It's just an opinion, not "the thing", whatever that would be.
    - _random_ 12y ago
      OK, my opinion is that there is no need to throw away type safety to gain succinctness, especially if your language gives you REPL.
      - thinkpad20 12y ago
        The advantage of dynamic languages is not in succinctness; the advantage is being able to defer the concrete definitions of the objects you're dealing with, or to ignore them entirely: it's what lets you pass arbitrary objects around in your middleware stack, or do things like ActiveRecord, click.py or sh.py which do crazy things with the object and module system, etc. There are things that are really hard in a statically typed language, or that you simply can't do, that dynamic languages let you do effortlessly. Of course, all of this freedom comes with cost. But gaining succinctness is hardly the major win of dynamic languages.
        mercurial 12y ago
        Well, succinctness is an advantage, and I'll claim with no data to support me that it is the reason, combined with the lack of compilation, that most developers choose dynamic languages, without necessarily realizing what they are giving up.
        thinkpad20 12y ago
        As someone who works for a company that uses python, but mostly uses Haskell in his spare time, my python code is often far more verbose than my Haskell (for a similar degree of complexity). I suppose if your yardstick is Java or something than you'll probably be more concise in a dynamic language, but that's really besides the point. The amount of characters you type in a language is one of the least important factors in choosing whether to use it or not. It's certainly not the reason that we use it.
dingdingdang 12y ago
It takes a full minute to build the finished project - is this normal or..?
- avsm 12y ago
  That's without parallelisation. There is a slowdown when building OCaml projects with a lot of packages, but this is being fixed with some build system improvements (removing the need for ocamlfind on every compiler invocation, switching from camlp4 to ppx extensions, and using the native code compiler instead of a bytecode one). It only affects large projects though, as most of the time you just modify a few files and do an incremental build.
  - edwintorok 12y ago
    That made me curious and did a quick profile: 25.52% camlp4 ocamlrun [.] caml_interprete 14.60% ocamlopt.opt ocamlopt.opt [.] 0x000000000016ec61 10.51% ocamlfind ocamlfind [.] caml_interprete Looks like ocamlfind is the bytecode version too ... I opened a bug.
pnathan 12y ago
This is possibly the best language writeup I have seen in years, if ever. Congratulations, sir!
xvilka 12y ago
Wonder what he mean by "lack of support for shared libraries".
- aaronblohowiak 12y ago
  Does Ocaml support dylibs/so/dll's?
  - xvilka 12y ago
    http://www.camlcity.org/knowledge/kb_002_shared_library.html http://www.camlcity.org/knowledge/kb_002_shared_library.html
pjmlp 12y ago
And this is the reason while I like Python a lot, nowadays only use it for scripting under UNIX.
- AlexanderDhoore 12y ago
  Well, I would say this is a pretty positive post for Python as well. Only 8x slower than OCaml... Not bad for an interpreted dynamically typed language. This makes a good case for prototyping in Python and only moving to something else when performance becomes an issue.
  - pjmlp 12y ago
    Hindley Milner type system makes strong typed languages also quite pleasant to use for prototyping. I mentioned UNIX, because on Windows my to go language for private scripts is F#.
    - herokusaki 12y ago
      Interesting. Do you find it more or less terse than PowerShell?
      - balakk 12y ago
        It can be as terse as you want it to be. The bigger virtues are its speed, language features, and the environment. F# interactive is what powershell/ISE wants to be, when it grows up and drinks the magic potion of awesomeness.
      - pjmlp 12y ago
        I use both actually. F# scripts for my own stuff, Powershell when those scripts need to be shared across the team or I need to interoperate with third party cmdlets. It is quite terse, specially because Powershell has a bit of VB flavour to its syntax, mixed with attributes everywhere. I rather use the cleanliness of the ML syntax, if possible.
frik 12y ago
Very informative post, thanks a lot! Epilogue Mirage unikernel - an operating system written in OCaml (the Mirage web-site is all implemented in OCaml, down to and including the TCP/IP stack!). That will have to be the subject for another blog post though... I am looking forward to such posts. Keep up your good work!
- platz 12y ago
  Mirage was also featured on the latest Software Engineering Radio podcast: http://www.se-radio.net/2014/05/episode-204-anil-madhavapeddy-on-the-mirage-cloud-operating-system-and-the-ocaml-language/ http://www.se-radio.net/2014/05/episode-204-anil-madhavapedd...
- shoo 12y ago
  here's a little more discussion about mirage, and the related arrakis : https://news.ycombinator.com/item?id=7726748 https://news.ycombinator.com/item?id=7726748 https://news.ycombinator.com/item?id=7780419 https://news.ycombinator.com/item?id=7780419
- amirmc 12y ago
  You can read about the Mirage work at http://openmirage.org http://openmirage.org It's also a core piece of a toolstack we're putting together for building distributed systems/applications (http://nymote.org http://nymote.org).
gnuvince 12y ago
As a language, OCaml gets most things right: being functional by default appeals to me very much, as does the easy path into imperative programming when you need it. Its type system is awesome not only at catching bugs at compile-time, but also at guiding you in your design. There are a couple of nice-to-have that would be cool though: Haskell-like type classes come to mind, and some minor syntax warts could be improved. Its implementation is also extremely solid: I always expect the code generated by OCaml to perform well. With tools like OPAM, getting the latest compiler and libraries is very easy. Definitely one of my favorite language toolset.
- _random_ 12y ago
  And there is always an option of using F# when needed.
- deleted 12y ago
  [deleted]
- truncate 12y ago
  I wonder how good are error messages in OCaml? I tried SML some time ago, and found error messages very hard to follow.
fuzzythinker 12y ago
His earlier post "OCaml: What you gain"[1] is also an interesting read. [1] http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain...
kbenson 12y ago
Is it me, or are the "Big and Slow" and "Small and Fast" labels in the Speed vs Size chart placed in the wrong corners?
- platz 12y ago
  it's startup time, not general speed
  - kbenson 12y ago
    I was just misreading the graph, assuming farther out on each axis was better (faster/smaller)
hoodoof 12y ago
The thing not described by the author is what oCaml is like to program. Python is easy to write and understand and makes sense and is a joy and not cryptic. What about OCaml?
- the_af 12y ago
  Maybe not in the main article, but he gives an overall view of OCaml in the sublinks. For example, in the summary for "OCaml: what you gain": http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain... The summary: ---- "OCaml’s main strengths are correctness and speed. Its type checking is very good at catching errors, and its “polymorphic variants” are a particularly useful feature, which I haven’t seen in other languages. Separate module interface files, abstract types, cycle-free dependencies, and data structures that are immutable by default help to make clean APIs. Surprisingly, writing GTK GUI code in OCaml was easier than in Python. The resulting code was significantly shorter and, I suspect, will prove far more reliable. OCaml’s type checking is particularly welcome here, as GUI code is often difficult to unit-test. The OCaml community is very good at maintaining API stability, allowing the same code to compile on old and new systems and (hopefully) minimising time spent updating it later." ---- This gives me the impression that OCaml is also a joy to program with, and additionally is more reliable and better at catching errors earlier than Python.
- talex5 12y ago
  It is a joy when you get used to it, but it's not as immediately accessible as Python. As I recall, my first hour or so with OCaml was full of frustrating syntax errors. Keep going though, it's worth it! One thing I don't think the tutorial mentions, but which helps a lot, is turning on all warnings ("-w A"). The tutorial also fails to mention ocamlbuild, so you start by compiling things manually, which makes everything harder than it should be.
deleted 12y ago
[deleted]
jordwalke 12y ago
Here's a copy of a previous post I've made on HN about why you might want to choose OCaml instead of another language. Nothing has changed about my opinion since the time I wrote it: Original link: https://news.ycombinator.com/item?id=7766315 https://news.ycombinator.com/item?id=7766315 ------ A couple of people have asked why you might choose OCaml over other languages. I've not done as much OCaml work as others on this thread (I work primarily on ReactJS (Facebook/Instagram's) functional UI framework), but I can offer a different perspective as someone who is outside of the OCaml community, but asking the same questions. Here are some of my personal findings. I'll narrow any comparison down to the ML family of languages. Java/C++/ and many other languages are just now beginning their slow, but inevitable evolution into becoming a dialect of ML (which IMHO is a sort of admission of the ML/functional family superiority). Once you embrace the power of pattern matching, it's hard to use anything but an ML family language (StandardML/Haskell/F#/OCaml). I would program in any one of those languages over Java/C++/Objective-C/JS. Practical reasons why you might choose OCaml: - OCaml's records aren't as elegant as SML's but OCaml has labeled arguments with optional default values which can satisfy many of the reasons why you'd use records as arguments in the first place (and may be even more powerful in some cases). - Two modes of compilation (fast native executable XOR fast compilation). Who doesn't like options. - All the benchmarks I can find show that OCaml is very fast (around as fast as C++). - Excellent JS target and and apparent commitment to maintaining it (as someone building a JS library, this is very important to me) (and as someone who wants to build apps and be able to instantly share them with everyone in the world.) - Someone has built an autocomplete plugin for Vim/Emacs (merlin). ("VimBox" (https://github.com/jordwalke/VimBox/ https://github.com/jordwalke/VimBox/) has configured it to complete as you type - like in Visual Studio etc.) - On very rare occasion, you'll run into a problem that is inherently better suited to OO (dynamic dispatch). I can usually find a way to solve it with functors/modules, but it's nice to know that you have OO in your back pocket in case you ever need it. It's also nice to know you probably won't have to. - Finally, a common package manager (OPAM) is becoming standard. I look forward to seeing how OPAM helps make the new dev experience and the code-sharing/development experience seamless. - The module system is very powerful (SML's). Haskell does not have this, and strangely F# dropped it. (I hear, Haskell's type classes fulfill similar roles (but with more sugar)). - There's usually ocamlyacc grammars for most languages. Most examples of languages, type systems, parsers are already in OCaml (or ML). It's a nice (but small) perk. - Predictability. OCaml is not lazy by default. Lazy computations could become problematic for low-latency applications (such as UIs) if a lot of computation becomes is deferred until the moment a final dependency has been satisfied, but by that time you may be close to your screen refresh deadline and it may lead to a dropped frame. It would have been better to have been computing while waiting for a final dependency. I'm not sure if Haskell (a lazy language) has had this problem. You can opt into laziness in OCaml if you would like to. - Mutability. I feel strange saying this, as such a huge proponent of immutability, but sometimes you just need to hack something in place, mutate some state and come back to clean it up later. (You can still use monads in OCaml). - Tagged Variants (no need to predeclare variants, just pattern match on them and OCaml ensures that only properly matched values ever make their way into that expression). - Industry use is growing. OCaml is used here at Facebook and many other places as mentioned. - There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...). OCaml Cons: - There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...). (Edited for formatting)
stewbrew 12y ago
Is my impression correct that the general interest in OCaml has waned & its development has somewhat stalled? I played with OCaml when it was at version 3. I remember the mailing list to be rather vibrant. Now there seem to be fewer posts. I think this is a pity because I really would like to see OCaml to take off. Projects like ocamljava and js_of_ocaml also sound quite promising.
- jon_smark 12y ago
  That impression is incorrect. I don't think the core devs and the overall community have ever been as vibrant as they are now. Take for instance compiler development: half a decade ago, updates were rare and marginal. Nowadays you can expect a new compiler version every single year with lots of exciting features.
- amirmc 12y ago
  I don't think you've looked very closely (if at all?). There is tons of stuff happening in the OCaml ecosystem. Compiler improvements, large scale projects, more industrial uses and also new books. Try looking at http://OCaml.org http://OCaml.org for some links (and the planet newsfeed), as well as the websites of OCaml Labs (see the article) or OCamlPro.
  - raphinou 12y ago
    He s right for the mailing list though. I regret there is not more discussion happening there
    - amirmc 12y ago
      Why? Frankly, I'm glad that there is more stuff happening out on the net at large rather than trapped on one list. I consider it a sign of success (there are probably many more users out there than who are on the mailing list anyway). I've used Python, Ruby, etc but I haven't ever joined their main lists and I don't feel I'm missing out (anything important will spread in other ways).
thinkpad20 12y ago
Ocaml is very enticing in many ways, with a lot of the features I love about Haskell; a few that are missing but also several that are not present in Haskell. Certainly, the strictness is a big plus for me, and being able to do mutability and IO without a monad (purity isn't as important to me). I've been averse to picking it up because I've invested so much time and effort in Haskell, because I'm used to the Haskell way of FP, and because I much prefer haskell's syntax. But maybe if I just dived in, then I'd find I even preferred it to Haskell.
- codygman 12y ago
  I've actually thought about ocaml myself, but one silly thing keeps putting me off. It feels like typing "let" over and over again would drive me crazy! I guess it's not that bad after looking at this for example: https://github.com/0install/0install/blob/master/ocaml/zeroinstall/driver.ml https://github.com/0install/0install/blob/master/ocaml/zeroi...

235 points by Envec83 12y ago

This was a fascinating read. What I'd like to see more of is how the migration was managed, concentrating on how the mix of the two languages was managed. It talks about replacing functions and using JSON to glue them together and/or allow them to communicate. I'd like to know more about that. Have I missed something? Regardless, excellent write-up. Thank you.

talex5 12y ago
Running both in a single process looked tricky because we need to work with the already-installed Python version, which could be 2.6, 2.7, 3.3, etc... so we'd have to provide a separate Python module for each one to do that. Instead, the OCaml created a pair of pipes and spawned a Python subprocess (you need to use two pipes, not a single socket, because Windows doesn't support Unix sockets). The protocol was asynchronous (replies can arrive out of order). Although the original JSON bridge is now gone, the new "0install slave" command (which allows other programs to control a 0install subprocess) uses a very similar system. It's documented here: http://0install.net/json-api.html http://0install.net/json-api.html

spenrose 12y ago

A year. A year of an apparently excellent programmer's output -- perhaps 2% of everything he will ever accomplish. To port a stable project to an 18 year old language.

lucian1900 12y ago
Considering most languages (even most new ones) ignore many more decades of programming language research, 18 years is pretty good: it was cutting edge PL research at the time.
- trurl 12y ago
  OCaml hasn't stood still either. The latest releases take advantage of some "fairly recent" research. Python on the other hand didn't even take advantage of cutting edge research at the time it was created, and as far as I can tell hasn't since.
Igglyboo 12y ago
Python itself is 23 years old and older than OCaml. Java, C, C++ are also older than OCaml and all 4 are highly used today. I don't think language age has any bearing on quality or usefulness.
- toolslive 12y ago
  Actually, the core of the language is way older. see http://en.wikipedia.org/wiki/Caml_Light http://en.wikipedia.org/wiki/Caml_Light and it can be considered a dialect of ML, which is even older (from 1973).
hvs 12y ago
Youth, for a programming language (and many other things), is not a positive benefit.
zem 12y ago
and in which he gained a massive speedup in the project, made it a lot easier to maintain and extend, learnt a lot about ocaml, and finally managed to get a really exciting job due to the exposure his blog gave him.
- spenrose 12y ago
  Wow, hate-haters gonna hate my hate. The slowest metric for the old code is about 1/3 of a second -- how much benefit does slicing that deliver in real world 0install invocations? "Easier to maintain and extend" -- well, he just cut the population of potential contributors to the project by a factor of 1000. The exciting job he got because it required knowing OCaml, and he spent a year advertising himself as a competent OCaml hacker. I find it very strange to care more about what language a project is written in than what the project actually does.
  - toolslive 12y ago
    I'm going to feed the troll here, but "cut the population of potential contributors to the project by a factor 1000" is a flawed argument : The value of potential contributors is very low. You're better of trying to increase the comfort and power of the _current_ contributors.
  - orthecreedence 12y ago
    > hate-haters gonna hate my hate Yeah, and fanbois gonna fanboi. He found something that works better for his use case. Sure, Python has has more programmers available, but that's because it's the flavor of the week (thanks to Google, let's be honest). In 3 years it may be the language time forgot. It makes a lot more sense to pick something you enjoy programming in and makes your life easier than something that everyone else thinks is the shit. Python has its place, and that place is not everywhere.
- gbog 12y ago
  Easier to maintain? Well at least you should add that this move from python to ocaml made it much harder to find someone able to maintain this project.
SloopJon 12y ago
During which time he became proficient in the language and landed what sounds like a pretty cool job.
_random_ 12y ago
The thing is that strong static inference beats dynamicity.
- klibertp 12y ago
  It's just an opinion, not "the thing", whatever that would be.
  - _random_ 12y ago
    OK, my opinion is that there is no need to throw away type safety to gain succinctness, especially if your language gives you REPL.
    - thinkpad20 12y ago
      The advantage of dynamic languages is not in succinctness; the advantage is being able to defer the concrete definitions of the objects you're dealing with, or to ignore them entirely: it's what lets you pass arbitrary objects around in your middleware stack, or do things like ActiveRecord, click.py or sh.py which do crazy things with the object and module system, etc. There are things that are really hard in a statically typed language, or that you simply can't do, that dynamic languages let you do effortlessly. Of course, all of this freedom comes with cost. But gaining succinctness is hardly the major win of dynamic languages.
      - mercurial 12y ago
        Well, succinctness is an advantage, and I'll claim with no data to support me that it is the reason, combined with the lack of compilation, that most developers choose dynamic languages, without necessarily realizing what they are giving up.
        thinkpad20 12y ago
        As someone who works for a company that uses python, but mostly uses Haskell in his spare time, my python code is often far more verbose than my Haskell (for a similar degree of complexity). I suppose if your yardstick is Java or something than you'll probably be more concise in a dynamic language, but that's really besides the point. The amount of characters you type in a language is one of the least important factors in choosing whether to use it or not. It's certainly not the reason that we use it.

dingdingdang 12y ago

It takes a full minute to build the finished project - is this normal or..?

avsm 12y ago
That's without parallelisation. There is a slowdown when building OCaml projects with a lot of packages, but this is being fixed with some build system improvements (removing the need for ocamlfind on every compiler invocation, switching from camlp4 to ppx extensions, and using the native code compiler instead of a bytecode one). It only affects large projects though, as most of the time you just modify a few files and do an incremental build.
- edwintorok 12y ago
  That made me curious and did a quick profile: 25.52% camlp4 ocamlrun [.] caml_interprete 14.60% ocamlopt.opt ocamlopt.opt [.] 0x000000000016ec61 10.51% ocamlfind ocamlfind [.] caml_interprete Looks like ocamlfind is the bytecode version too ... I opened a bug.

pnathan 12y ago

This is possibly the best language writeup I have seen in years, if ever. Congratulations, sir!

xvilka 12y ago

Wonder what he mean by "lack of support for shared libraries".

aaronblohowiak 12y ago
Does Ocaml support dylibs/so/dll's?
- xvilka 12y ago
  http://www.camlcity.org/knowledge/kb_002_shared_library.html http://www.camlcity.org/knowledge/kb_002_shared_library.html

pjmlp 12y ago

And this is the reason while I like Python a lot, nowadays only use it for scripting under UNIX.

AlexanderDhoore 12y ago
Well, I would say this is a pretty positive post for Python as well. Only 8x slower than OCaml... Not bad for an interpreted dynamically typed language. This makes a good case for prototyping in Python and only moving to something else when performance becomes an issue.
- pjmlp 12y ago
  Hindley Milner type system makes strong typed languages also quite pleasant to use for prototyping. I mentioned UNIX, because on Windows my to go language for private scripts is F#.
  - herokusaki 12y ago
    Interesting. Do you find it more or less terse than PowerShell?
    - balakk 12y ago
      It can be as terse as you want it to be. The bigger virtues are its speed, language features, and the environment. F# interactive is what powershell/ISE wants to be, when it grows up and drinks the magic potion of awesomeness.
    - pjmlp 12y ago
      I use both actually. F# scripts for my own stuff, Powershell when those scripts need to be shared across the team or I need to interoperate with third party cmdlets. It is quite terse, specially because Powershell has a bit of VB flavour to its syntax, mixed with attributes everywhere. I rather use the cleanliness of the ML syntax, if possible.

frik 12y ago

Very informative post, thanks a lot! Epilogue Mirage unikernel - an operating system written in OCaml (the Mirage web-site is all implemented in OCaml, down to and including the TCP/IP stack!). That will have to be the subject for another blog post though... I am looking forward to such posts. Keep up your good work!

platz 12y ago
Mirage was also featured on the latest Software Engineering Radio podcast: http://www.se-radio.net/2014/05/episode-204-anil-madhavapeddy-on-the-mirage-cloud-operating-system-and-the-ocaml-language/ http://www.se-radio.net/2014/05/episode-204-anil-madhavapedd...
shoo 12y ago
here's a little more discussion about mirage, and the related arrakis : https://news.ycombinator.com/item?id=7726748 https://news.ycombinator.com/item?id=7726748 https://news.ycombinator.com/item?id=7780419 https://news.ycombinator.com/item?id=7780419
amirmc 12y ago
You can read about the Mirage work at http://openmirage.org http://openmirage.org It's also a core piece of a toolstack we're putting together for building distributed systems/applications (http://nymote.org http://nymote.org).

gnuvince 12y ago

As a language, OCaml gets most things right: being functional by default appeals to me very much, as does the easy path into imperative programming when you need it. Its type system is awesome not only at catching bugs at compile-time, but also at guiding you in your design. There are a couple of nice-to-have that would be cool though: Haskell-like type classes come to mind, and some minor syntax warts could be improved. Its implementation is also extremely solid: I always expect the code generated by OCaml to perform well. With tools like OPAM, getting the latest compiler and libraries is very easy. Definitely one of my favorite language toolset.

_random_ 12y ago
And there is always an option of using F# when needed.
deleted 12y ago
[deleted]
truncate 12y ago
I wonder how good are error messages in OCaml? I tried SML some time ago, and found error messages very hard to follow.

fuzzythinker 12y ago

His earlier post "OCaml: What you gain"[1] is also an interesting read. [1] http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain...

kbenson 12y ago

Is it me, or are the "Big and Slow" and "Small and Fast" labels in the Speed vs Size chart placed in the wrong corners?

platz 12y ago
it's startup time, not general speed
- kbenson 12y ago
  I was just misreading the graph, assuming farther out on each axis was better (faster/smaller)

hoodoof 12y ago

The thing not described by the author is what oCaml is like to program. Python is easy to write and understand and makes sense and is a joy and not cryptic. What about OCaml?

the_af 12y ago
Maybe not in the main article, but he gives an overall view of OCaml in the sublinks. For example, in the summary for "OCaml: what you gain": http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain... The summary: ---- "OCaml’s main strengths are correctness and speed. Its type checking is very good at catching errors, and its “polymorphic variants” are a particularly useful feature, which I haven’t seen in other languages. Separate module interface files, abstract types, cycle-free dependencies, and data structures that are immutable by default help to make clean APIs. Surprisingly, writing GTK GUI code in OCaml was easier than in Python. The resulting code was significantly shorter and, I suspect, will prove far more reliable. OCaml’s type checking is particularly welcome here, as GUI code is often difficult to unit-test. The OCaml community is very good at maintaining API stability, allowing the same code to compile on old and new systems and (hopefully) minimising time spent updating it later." ---- This gives me the impression that OCaml is also a joy to program with, and additionally is more reliable and better at catching errors earlier than Python.
talex5 12y ago
It is a joy when you get used to it, but it's not as immediately accessible as Python. As I recall, my first hour or so with OCaml was full of frustrating syntax errors. Keep going though, it's worth it! One thing I don't think the tutorial mentions, but which helps a lot, is turning on all warnings ("-w A"). The tutorial also fails to mention ocamlbuild, so you start by compiling things manually, which makes everything harder than it should be.

deleted 12y ago

[deleted]

jordwalke 12y ago

Here's a copy of a previous post I've made on HN about why you might want to choose OCaml instead of another language. Nothing has changed about my opinion since the time I wrote it: Original link: https://news.ycombinator.com/item?id=7766315 https://news.ycombinator.com/item?id=7766315 ------ A couple of people have asked why you might choose OCaml over other languages. I've not done as much OCaml work as others on this thread (I work primarily on ReactJS (Facebook/Instagram's) functional UI framework), but I can offer a different perspective as someone who is outside of the OCaml community, but asking the same questions. Here are some of my personal findings. I'll narrow any comparison down to the ML family of languages. Java/C++/ and many other languages are just now beginning their slow, but inevitable evolution into becoming a dialect of ML (which IMHO is a sort of admission of the ML/functional family superiority). Once you embrace the power of pattern matching, it's hard to use anything but an ML family language (StandardML/Haskell/F#/OCaml). I would program in any one of those languages over Java/C++/Objective-C/JS. Practical reasons why you might choose OCaml: - OCaml's records aren't as elegant as SML's but OCaml has labeled arguments with optional default values which can satisfy many of the reasons why you'd use records as arguments in the first place (and may be even more powerful in some cases). - Two modes of compilation (fast native executable XOR fast compilation). Who doesn't like options. - All the benchmarks I can find show that OCaml is very fast (around as fast as C++). - Excellent JS target and and apparent commitment to maintaining it (as someone building a JS library, this is very important to me) (and as someone who wants to build apps and be able to instantly share them with everyone in the world.) - Someone has built an autocomplete plugin for Vim/Emacs (merlin). ("VimBox" (https://github.com/jordwalke/VimBox/ https://github.com/jordwalke/VimBox/) has configured it to complete as you type - like in Visual Studio etc.) - On very rare occasion, you'll run into a problem that is inherently better suited to OO (dynamic dispatch). I can usually find a way to solve it with functors/modules, but it's nice to know that you have OO in your back pocket in case you ever need it. It's also nice to know you probably won't have to. - Finally, a common package manager (OPAM) is becoming standard. I look forward to seeing how OPAM helps make the new dev experience and the code-sharing/development experience seamless. - The module system is very powerful (SML's). Haskell does not have this, and strangely F# dropped it. (I hear, Haskell's type classes fulfill similar roles (but with more sugar)). - There's usually ocamlyacc grammars for most languages. Most examples of languages, type systems, parsers are already in OCaml (or ML). It's a nice (but small) perk. - Predictability. OCaml is not lazy by default. Lazy computations could become problematic for low-latency applications (such as UIs) if a lot of computation becomes is deferred until the moment a final dependency has been satisfied, but by that time you may be close to your screen refresh deadline and it may lead to a dropped frame. It would have been better to have been computing while waiting for a final dependency. I'm not sure if Haskell (a lazy language) has had this problem. You can opt into laziness in OCaml if you would like to. - Mutability. I feel strange saying this, as such a huge proponent of immutability, but sometimes you just need to hack something in place, mutate some state and come back to clean it up later. (You can still use monads in OCaml). - Tagged Variants (no need to predeclare variants, just pattern match on them and OCaml ensures that only properly matched values ever make their way into that expression). - Industry use is growing. OCaml is used here at Facebook and many other places as mentioned. - There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...). OCaml Cons: - There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...). (Edited for formatting)

stewbrew 12y ago

Is my impression correct that the general interest in OCaml has waned & its development has somewhat stalled? I played with OCaml when it was at version 3. I remember the mailing list to be rather vibrant. Now there seem to be fewer posts. I think this is a pity because I really would like to see OCaml to take off. Projects like ocamljava and js_of_ocaml also sound quite promising.

jon_smark 12y ago
That impression is incorrect. I don't think the core devs and the overall community have ever been as vibrant as they are now. Take for instance compiler development: half a decade ago, updates were rare and marginal. Nowadays you can expect a new compiler version every single year with lots of exciting features.
amirmc 12y ago
I don't think you've looked very closely (if at all?). There is tons of stuff happening in the OCaml ecosystem. Compiler improvements, large scale projects, more industrial uses and also new books. Try looking at http://OCaml.org http://OCaml.org for some links (and the planet newsfeed), as well as the websites of OCaml Labs (see the article) or OCamlPro.
- raphinou 12y ago
  He s right for the mailing list though. I regret there is not more discussion happening there
  - amirmc 12y ago
    Why? Frankly, I'm glad that there is more stuff happening out on the net at large rather than trapped on one list. I consider it a sign of success (there are probably many more users out there than who are on the mailing list anyway). I've used Python, Ruby, etc but I haven't ever joined their main lists and I don't feel I'm missing out (anything important will spread in other ways).

thinkpad20 12y ago

Ocaml is very enticing in many ways, with a lot of the features I love about Haskell; a few that are missing but also several that are not present in Haskell. Certainly, the strictness is a big plus for me, and being able to do mutability and IO without a monad (purity isn't as important to me). I've been averse to picking it up because I've invested so much time and effort in Haskell, because I'm used to the Haskell way of FP, and because I much prefer haskell's syntax. But maybe if I just dived in, then I'd find I even preferred it to Haskell.

codygman 12y ago
I've actually thought about ocaml myself, but one silly thing keeps putting me off. It feels like typing "let" over and over again would drive me crazy! I guess it's not that bad after looking at this for example: https://github.com/0install/0install/blob/master/ocaml/zeroinstall/driver.ml https://github.com/0install/0install/blob/master/ocaml/zeroi...