5 ms·

Seeing how I'm currently in Chicago for ErlangCamp (which is excellent so far), it's relevant for me to recommend Erlang if you want to go big in the multiproce

by chops 16y ago

Seeing how I'm currently in Chicago for ErlangCamp (which is excellent so far), it's relevant for me to recommend Erlang if you want to go big in the multiprocessoring and concurrency stuff. I know that wasn't one of your 4 mentioned languages, but it's worth a mention.

fnl 16y ago
Yeah, that would be number five and I was considering adding it, actually; However, I am not really sure I like it, because the speed of Erlang isn't that great and I for that point always favor anything that can keep up with C (and, the Go guys at least promise they will; so I'd like to see how fast Clojure can go on a JVM). Now, I know Python can't, but then you can always first write your prototype in it, and then later fix performance considerably with some C.
- mzl 16y ago
  If you have some heavy computation parts that you could implement in some lower-level language like C, then you might want to check out Erlang again. Erlang is really good at making the coordination layer efficient (the message passing and threads are fast) as well as usually rather clean. The original use-case for Erlang, telecomunication switches, are written in a mix of Erlang and C. The low level stuff (handling call-data and similar things) is handled by C, and the high-level structure of the program is in Erlang.
  - fnl 16y ago
    Followed the advice I got here from you and others and am now studying the language. And, so far, I must say, Erlang rocks. Naturally it will be a few weeks before I can write something real and make more of an educated decision, but it really looks very nice so far - so many solutions to problems I have. I especially like the "selective message passing" bits and the ways you can operate on bitstreams already.
wtracy 16y ago
I'm currently teaching myself Haskell because of its concurrency support. :-) Anyone care to tell us about how the two languages stack up against each other?
- fnl 16y ago
  Second that question, too! Actually, in terms of what can be gained, Haskell might be even more interesting to learn in terms of the increasing need of MP than thinking about go or Clojure.
  - wtracy 16y ago
    I did a touch of research on my own. The Clojure slide deck that's currently featured on the front page has some useful definitions: "Concurrency is commonly mistaken for parallelism, but the two are distinct concepts. Concurrency is concerned with managing access to shared state from different threads, whereas parallelism is concerned with utilizing multiple processors/cores to improve the performance of a computation." Haskell has parallelism nailed. You can basically tell the compiler, "I want these two functions to run in parallel on two different cores." The compiler will then transparently do some fork/join type magic, and automatically enforce that the functions can't step on each other's toes. (It probably uses threads instead of processes, but since the functions are not allowed to share data, it feels like Unix-style fork/join.) (Side note: Unless it's explicitly stated in the function's signature, Haskell functions are forbidden by the compiler to have any side effects. This will drive programmers coming from a procedural background absolutely insane, but it makes the above magic possible.) I haven't coded in Erlang, but it seems to rely heavily on message passing. The compiler stops you from doing stupid things, but the concurrency is still exposed to the application. So, if your only goal is to distribute your workload to as many cores as possible (say you're building a video encoder, or in my case a ray tracer) with as little hacking as possible, Haskell will make your day. If the existence of different threads is part of your actual application architecture, Erlang is your friend. It lets you explicitly create producers and consumers, and play around with different event architectures. As mentioned before, I'm a Haskell n00b and completely unfamiliar with Erlang, so if anyone wants to chime in and correct me, please do.

by chops 16y ago

fnl 16y ago

Yeah, that would be number five and I was considering adding it, actually; However, I am not really sure I like it, because the speed of Erlang isn't that great and I for that point always favor anything that can keep up with C (and, the Go guys at least promise they will; so I'd like to see how fast Clojure can go on a JVM). Now, I know Python can't, but then you can always first write your prototype in it, and then later fix performance considerably with some C.

mzl 16y ago
If you have some heavy computation parts that you could implement in some lower-level language like C, then you might want to check out Erlang again. Erlang is really good at making the coordination layer efficient (the message passing and threads are fast) as well as usually rather clean. The original use-case for Erlang, telecomunication switches, are written in a mix of Erlang and C. The low level stuff (handling call-data and similar things) is handled by C, and the high-level structure of the program is in Erlang.
- fnl 16y ago
  Followed the advice I got here from you and others and am now studying the language. And, so far, I must say, Erlang rocks. Naturally it will be a few weeks before I can write something real and make more of an educated decision, but it really looks very nice so far - so many solutions to problems I have. I especially like the "selective message passing" bits and the ways you can operate on bitstreams already.

wtracy 16y ago

I'm currently teaching myself Haskell because of its concurrency support. :-) Anyone care to tell us about how the two languages stack up against each other?

fnl 16y ago
Second that question, too! Actually, in terms of what can be gained, Haskell might be even more interesting to learn in terms of the increasing need of MP than thinking about go or Clojure.
- wtracy 16y ago
  I did a touch of research on my own. The Clojure slide deck that's currently featured on the front page has some useful definitions: "Concurrency is commonly mistaken for parallelism, but the two are distinct concepts. Concurrency is concerned with managing access to shared state from different threads, whereas parallelism is concerned with utilizing multiple processors/cores to improve the performance of a computation." Haskell has parallelism nailed. You can basically tell the compiler, "I want these two functions to run in parallel on two different cores." The compiler will then transparently do some fork/join type magic, and automatically enforce that the functions can't step on each other's toes. (It probably uses threads instead of processes, but since the functions are not allowed to share data, it feels like Unix-style fork/join.) (Side note: Unless it's explicitly stated in the function's signature, Haskell functions are forbidden by the compiler to have any side effects. This will drive programmers coming from a procedural background absolutely insane, but it makes the above magic possible.) I haven't coded in Erlang, but it seems to rely heavily on message passing. The compiler stops you from doing stupid things, but the concurrency is still exposed to the application. So, if your only goal is to distribute your workload to as many cores as possible (say you're building a video encoder, or in my case a ray tracer) with as little hacking as possible, Haskell will make your day. If the existence of different threads is part of your actual application architecture, Erlang is your friend. It lets you explicitly create producers and consumers, and play around with different event architectures. As mentioned before, I'm a Haskell n00b and completely unfamiliar with Erlang, so if anyone wants to chime in and correct me, please do.