Browse thread
Re: Why OCaml sucks
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Ulf Wiger (TN/EAB) <ulf.wiger@e...> |
| Subject: | not all functional languages lack parallelism |
Jon Harrop skrev: > > 1. Lack of Parallelism: Yes, this is already a complete show > stopper. Exploiting multicores requires a scalable concurrent > GC and message passing (like JoCaml) is not a substitute. > Unfortunately, this is now true of all functional languages > available for Linux, which is why we have now migrated > entirely to Windows and F#. Dear Jon, I will keep reminding you that Erlang is a functional language (just not a statically typed one). It has very lightweight processes, concurrent schedulers on multicore, and per-process GC. It scales very well on multicore. I can understand if you don't consider Erlang a competitive alternative for building ray tracers, but I will protest while you insist on making sweeping statements about *all* functional languages that are patently untrue for Erlang. Both in the Haskell and Erlang communities, there is occasional reference to Erlang/Haskell/OCaml as a very useful triple, having much in common, but each being especially good in some fairly well-defined area. I think this perspective is useful for all three languages. BR, Ulf W BTW, the ErlOcaml project is beginning to reach a state of usefulness, at least for experiments: http://code.google.com/p/erlocaml/ It allows an Ocaml program to act as a "hidden erlang node", talking to Erlang programs via Erlang message passing. One possible use for this could be to use Erlang as a systems programming language, keeping your application logic in OCaml. Erlang/OTP comes with practically everything you need to turn your product into a robust cluster, including a distributed database and some very useful logic for error recovery and in-service upgrade. And it's all Open Source. Many thanks to Ludovic Coquelle for all the coding he has done. The rest of us have kept to the cheerleading section for now.