Live data from Hacker News

Unix system programming in OCaml

ocamlunix.forge.ocamlcore.org

1–10 of 16 posts

Re: Unix system programming in OCaml

#3
Language-wise, it is a really nice and interesting, indeed. But two things keep me away from OCaml, both reported by the same company (Jane Street), which apparently uses OCaml in production:

1. Standard library was so weak that they had to come up with in-house replacement (which is now open sourced).

2. No true parallelism due to runtime limitations (single runtime lock) - http://queue.acm.org/detail.cfm?id=2038036

Re: Unix system programming in OCaml

#4
post #3

Language-wise, it is a really nice and interesting, indeed. But two things keep me away from OCaml, both reported by the same company (Jane Street), which apparently uses OCaml in production: 1. Standard library was so weak that they had to come up with in-house replacement (which is now open sourced). 2. No true parallelism due to runtime limitations (single runtime lock) - http://queue.acm.org/detail.cfm?id=2038036

And the community isn't as vibrant as the communities of other functional languages such as Clojure or Haskell

Re: Unix system programming in OCaml

#5
post #3

Language-wise, it is a really nice and interesting, indeed. But two things keep me away from OCaml, both reported by the same company (Jane Street), which apparently uses OCaml in production: 1. Standard library was so weak that they had to come up with in-house replacement (which is now open sourced). 2. No true parallelism due to runtime limitations (single runtime lock) - http://queue.acm.org/detail.cfm?id=2038036

This is all true. On the other hand, it's worth mentioning the major benefits that Jane Street gets from OCaml:

1. Excellent single-core performance. 2. Code is fast to write and can be quickly adapted, so you get the agility of the typical dynamic languages but the benefits of a static type system. 3. Although the community has few members, the quality of engineers in it is very high. Someone who knows OCaml well is much more likely to be a good hire. 4. Legibility of code. Partners review production code. These are very smart guys, but they're traders-- not quants or programmers by trade.

Writing libraries, if you have the resources, is a small cost. It's heavy upfront, but once you have good libraries, that's no longer an issue. That issue depends on the scope of your project. You probably wouldn't use OCaml for a web project you intended to deliver in one month.

The benefit that I think is most interesting is the 4th, because the reading of code is where most software companies seem to fall down. Of course, this involves style as much as the language itself, but OCaml is, in my experience, the language best optimized for the reader's concerns. Haskell can be similarly legible (and is much terser) but one can also go off the rails with it.

Re: Unix system programming in OCaml

#6
post #3

Language-wise, it is a really nice and interesting, indeed. But two things keep me away from OCaml, both reported by the same company (Jane Street), which apparently uses OCaml in production: 1. Standard library was so weak that they had to come up with in-house replacement (which is now open sourced). 2. No true parallelism due to runtime limitations (single runtime lock) - http://queue.acm.org/detail.cfm?id=2038036

This is all true. On the other hand, it's worth mentioning the major benefits that Jane Street gets from OCaml: 1. Excellent single-core performance. 2. Code is fast to write and can be quickly adapted, so you get the agility of the typical dynamic languages but the benefits of a static type system. 3. Although the community has few members, the quality of engineers in it is very high. Someone who knows OCaml well is…

What I like most about the Jane Street story is that they weren't afraid to rewrite their system and even went through a half-done abandoned Java rewrite. It shows that if you're working with smart enough people you can break away from the "incremental development reality" and discover the hidden powers of all sorts of technologies that others are afraid to try for fear of transition nightmare.

Re: Unix system programming in OCaml

#7
post #4
post #3

Language-wise, it is a really nice and interesting, indeed. But two things keep me away from OCaml, both reported by the same company (Jane Street), which apparently uses OCaml in production: 1. Standard library was so weak that they had to come up with in-house replacement (which is now open sourced). 2. No true parallelism due to runtime limitations (single runtime lock) - http://queue.acm.org/detail.cfm?id=2038036

And the community isn't as vibrant as the communities of other functional languages such as Clojure or Haskell

...good luck having a trader with very basic coding knowledge "review" Haskell or Clojure code (the process JS is "famous" for) - even if they understand the value of it and are willing to learn it, it will always be a huge mental effort handling monads or reading code "inside our" lisp-style. And coders will not resist doing "smart stuff" in languages like Clojure or Haskell, which will make everything worse. Otoh, smart business folks with some technical background can digest oop and functional programming in a language with infix operators quite easily if they know they have a lot to gain from doing it.

Re: Unix system programming in OCaml

#8
post #6

Earlier quoted context omitted.

This is all true. On the other hand, it's worth mentioning the major benefits that Jane Street gets from OCaml: 1. Excellent single-core performance. 2. Code is fast to write and can be quickly adapted, so you get the agility of the typical dynamic languages but the benefits of a static type system. 3. Although the community has few members, the quality of engineers in it is very high. Someone who knows OCaml well is…

What I like most about the Jane Street story is that they weren't afraid to rewrite their system and even went through a half-done abandoned Java rewrite. It shows that if you're working with smart enough people you can break away from the "incremental development reality" and discover the hidden powers of all sorts of technologies that others are afraid to try for fear of transition nightmare.

It's more a question of company priority and customer demands. Try rewriting a few hundred thousand lines of code currently in production at several customers, who all want modifications. Unless you have enough manpower to dedicate a team to maintenance, that's not going to happen. Especially if the competition keeps churning out new features.

Re: Unix system programming in OCaml

#9
post #6

Earlier quoted context omitted.

What I like most about the Jane Street story is that they weren't afraid to rewrite their system and even went through a half-done abandoned Java rewrite. It shows that if you're working with smart enough people you can break away from the "incremental development reality" and discover the hidden powers of all sorts of technologies that others are afraid to try for fear of transition nightmare.

It's more a question of company priority and customer demands. Try rewriting a few hundred thousand lines of code currently in production at several customers, who all want modifications. Unless you have enough manpower to dedicate a team to maintenance, that's not going to happen. Especially if the competition keeps churning out new features.

...if I think about it, the few companies that did rewrite their codebase and benefited from this were the ones that were their own customers of their code as JS and Twitter both fall in here. You're right, it's probably not worth it if you're selling "software as a product", but when you are basically an saas business or even better, you're doing in-house dev, and everything runs on your servers, you are free to even run simultaneously multiple version of your thing for different tasks.

Re: Unix system programming in OCaml

#10
post #3

Language-wise, it is a really nice and interesting, indeed. But two things keep me away from OCaml, both reported by the same company (Jane Street), which apparently uses OCaml in production: 1. Standard library was so weak that they had to come up with in-house replacement (which is now open sourced). 2. No true parallelism due to runtime limitations (single runtime lock) - http://queue.acm.org/detail.cfm?id=2038036

3. The compiler's error messages lack useful detail (e.g. "syntax error" and a line number!)

4. Stack traces are as likely to be wrong as right

5. Too much boilerplate exception handling (e.g Not_found)

6. Clunky type polymorphism (e.g. Set)

Post reply on HN