4 ms·

I'm dubious that Haskell is better for writing distributed concurrent systems, but I don't know much about haskell. Rather than bashing erlang like this, I'd h

I'm dubious that Haskell is better for writing distributed concurrent systems, but I don't know much about haskell. Rather than bashing erlang like this, I'd have gotten a lot more out of an article that described how Haskell approached the problem, possibly with contrasts to erlang. But when you start off with at best nonsense "erlang's parallelism is not parallelism" you're going to lose people who do know something about erlang. Here's the deal with erlang: The syntax throws some people off. If you will spend a couple hours learning the language (maybe a couple days) you'll start to appreciate the syntax and it will no longer be a problem. Erlang is not as fast as bare metal languages like, say, C, but Erlang is fantastic for making programs in parallel and executing them on multiple cores or nodes or clusters of nodes with multiple cores. I guess I should take the occurrence of these kinds of articles as a sign that Erlang is getting wider acceptance. That's great! But please, cheer your language, don't bash the competition.

jerf 15y ago
"I'm dubious that Haskell is better for writing distributed concurrent systems,... Rather than bashing erlang like this, I'd have gotten a lot more out of an article that described how Haskell approached the problem," I'm not sure exactly where you saw the claim that Haskell is better at writing distributed concurrent systems. The Haskell distributed concurrency story is basically that there isn't one. There's a very early stab at adapting Erlang-style concurrency as a library, but there's nothing that I know of that is shipping and standardized that is a solution to that problem, and there's certainly nothing like Erlang, where a certain type of reliability informs the design of the language from top-to-bottom. Someday I look forward to a Haskell that has stolen (ahem) Erlang's OTP but we're a ways away from that. Also, clearly explaining Erlang's origins as focused on reliability, rather than "concurrency", is doing Erlang a favor, not criticizing it. I think more people would put up with its quirks if they realized that at least some of them come from this strong focus on a use case usually ignored by mainstream languages, rather than seeing it as an attempt at a mainstream language with a strong concurrency focus. (Some of its quirks are just bad, though.)
mononcqc 15y ago
I think you got this article entirely wrong. Jlouis (the author) is an advanced Erlang user who does know the language very well. He wrote etorrent, an Erlang bitorrent client in Erlang (which was also compared with combinatorrent, his Haskell version). The article isn't about bashing Erlang, but changing the perspective under which it is observed. Namely, the language isn't about parallelism, but parallelism is a nice-to-have feature made possible by the concurrency constructs of the language, which themselves come from a need for fault-tolerance. I would certainly say he is right and I support this way of explaining things. I'm a somewhat advanced Erlang user, and I enjoyed the article. I am not sure where you got that competition with Haskell aspect, but I don't think it was ever the point.

jerf 15y ago

"I'm dubious that Haskell is better for writing distributed concurrent systems,... Rather than bashing erlang like this, I'd have gotten a lot more out of an article that described how Haskell approached the problem," I'm not sure exactly where you saw the claim that Haskell is better at writing distributed concurrent systems. The Haskell distributed concurrency story is basically that there isn't one. There's a very early stab at adapting Erlang-style concurrency as a library, but there's nothing that I know of that is shipping and standardized that is a solution to that problem, and there's certainly nothing like Erlang, where a certain type of reliability informs the design of the language from top-to-bottom. Someday I look forward to a Haskell that has stolen (ahem) Erlang's OTP but we're a ways away from that. Also, clearly explaining Erlang's origins as focused on reliability, rather than "concurrency", is doing Erlang a favor, not criticizing it. I think more people would put up with its quirks if they realized that at least some of them come from this strong focus on a use case usually ignored by mainstream languages, rather than seeing it as an attempt at a mainstream language with a strong concurrency focus. (Some of its quirks are just bad, though.)

mononcqc 15y ago

I think you got this article entirely wrong. Jlouis (the author) is an advanced Erlang user who does know the language very well. He wrote etorrent, an Erlang bitorrent client in Erlang (which was also compared with combinatorrent, his Haskell version). The article isn't about bashing Erlang, but changing the perspective under which it is observed. Namely, the language isn't about parallelism, but parallelism is a nice-to-have feature made possible by the concurrency constructs of the language, which themselves come from a need for fault-tolerance. I would certainly say he is right and I support this way of explaining things. I'm a somewhat advanced Erlang user, and I enjoyed the article. I am not sure where you got that competition with Haskell aspect, but I don't think it was ever the point.