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

Is OCaml, then, a good fit for the kinds of programs many people have started writing in Go?

Native, stand alone binaries. High performance (not sure how the Go vs. OCaml benchmarks look right now). Good networking. More productive and less error prone than C or C++. Less verbose than Java.

Haven't written any OCaml programs, but seems to check the same boxes. Go seems to have a much better concurrency story with channels.

OCaml seems to have a much better type system and functional programming support.



Go does have a much better concurrency story, OCaml's is rather weak (as others have observed).

For the work I do (data analysis and scientific research, particularly on recommender systems, with system-building to support that), if I need concurrency, it's suitable to run the program on the JVM. So I would use Scala in that case, and OCaml would be fine for the other systems-y stuff.

I personally have taken to writing such code in Haskell these days, but that's largely to practice my FP skills in a manner that's easier to transfer back to Scala.


My understanding is that Go has a focus on concurrency which OCaml presently lacks, and so it probably has an edge there (possibly a big one). Otherwise, yes, OCaml is a good fit for the kinds of problems I understand Go to be used for.


If you only need concurrency for I/O, and in particular networking then OCaml is pretty good here:

- you can use system threads. Yes you'll only be able to run one OCaml thread at once, but when one OCaml thread gets blocked on I/O it switches to another.

- you can do co-operative threading if you write your code in a monadic style (there are a few libraries providing this: Lwt, Async, and in some sense Equeue). Then you don't need to worry about the thread/context-switching overhead, and the event-driven architecture should allow you to scale to thousands of concurrent events. While this may sound scary at first, the syntax is quite easy to understand, and it really is a lot easier than trying to write non-blocking code in C with lots of callbacks.

In particular have a look at Ocsigen, and Eliom that provide a web-server and framework: http://ocsigen.org/tutorial/

Regarding the book have a look at the 'Concurrent Programming with Async' chapter that shows how you can write a TCP server/client that doesn't block.


Good points.




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

Search: