Quoth Paul Rubin <http://[EMAIL PROTECTED]>:
| Right now I'm mainly interested in OCaml, Haskell, Erlang, and maybe
| Occam. Haskell seems to have the happiest users, which is always a
| good thing. Erlang has been used for real-world systems and has
| built-in concurrency support. OCaml seems to crush Haskell and Erlang
| (and even Java) in performance.
I'm sure you're aware that these are all arguable. In particular,
shootout figures aren't a really reliable way to find out about
performance.
| The idea is to use one of those languages for a personal project after
| my current work project wraps up pretty soon. This would be both a
| learning effort and an attempt to write something useful. I'm
| thinking of a web application like a discussion board or wiki,
| intended to outperform the existing ones, i.e. able to handle a
| Slashdot or Wikipedia sized load (millions of hits/day) on a single
| fast PC instead of a rack full. "Single fast PC" will probably soon
| come to mean a two-cpu-chip motherboard in a 1U rack box, where each
| cpu chip is a dual core P4 or Athlon, so the application should be
| able to take advantage of at least 4-way multiprocessing, thus the
| interest in concurrency.
Oh. Note that the FP world has been historically attracted to the
"green" thread model, where threads are implemented in the runtime
like (old) Stackless micro-threads, much faster and more tractable
for runtime data structures ... but runs on only one CPU at a time.
Ocaml & I believe current ghc support native OS threads, Erlang I
would guess not but wouldn't know for sure. Don't know about ghc
internals, the way I remember it ocaml's native thread system has
something like Python's global lock, instead of locks around each
memory management function etc.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
