Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's all this fuss about Erlang? (2007)

pragprog.com

Post reply on HN
Print view View original

91–100 of 193 posts

Re: What's all this fuss about Erlang? (2007)

#91

Post by PopsiclePete »

chrisseaton wrote: post #9

> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…

"Trivial" to write parallel programs in C?

You should stop doing whatever it is that you're doing, because you are in the top 0.00000000001% of programmers, in the Universe, and I want to work on whatever multi-billion dollar startup you undoubtedly have going on.

Re: What's all this fuss about Erlang? (2007)

#92

Post by derefr »

di4na wrote: post #84
derefr wrote: post #12

Earlier quoted context omitted.

I've always thought that Erlang would be more successful if it had a better deployment story, along the lines of Go or Rust: e.g. if you had the option of baking an Erlang runtime into a static binary. As it stands, software like ejabberd and rabbitmq are pretty ugly in OS package form (because distro maintainers think such packages need to rely on a common, usually very old, Erlang runtime, instead of allowing them…

It does that. This is an erlang release, and that is something that erlang does really well. The problem lie more on the tooling that made it harder than it should have been. This is what Elixir bring to the table.

An Erlang release is not a static binary. It certainly is (or starts off as) a self-contained directory you can just unzip onto a server—but for the kind of software I'm talking about (RabbitMQ, CouchDB, Riak, etc.) you don't tend to install these things this way. You expect to install them using your distro's package manager. And, until very recently, distros did horrible things to those packages to force them into the FreeDesktop FHS mold. (And it still doesn't entirely work; the Erlang concept of priv dirs, for example, just doesn't map well onto even a reasonably-similar directory like /var/lib.)

That's what I mean by "deployability": the hell that is trying to convert your Erlang release into a distro package so that users can simply "apt-get install" it and have the distro maintain it for you; and so other software packages can declare package-level dependencies on it.

The reason that true static binaries ala Go would be better, is simply that it would stop the distro maintainers from messing with everything to quite the same degree. In such a setup, there wouldn't be a "system Erlang runtime", because Erlang would just be a baked-in part of /usr/bin/riak or /usr/bin/ejabberd. (Which wouldn't stop distros from making Erlang SDK packages for things like an Elixir package to depend on, but they wouldn't be involved at all in the dependency tree of the Erlang-release-derived packages on the system.)

Re: What's all this fuss about Erlang? (2007)

#93

Post by BeetleB »

devishard wrote: post #86
chrisseaton wrote: post #9

> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…

>> Your Erlang program should just run N times faster on an N core processor > But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. You've made two claims, one irrelevant and one false: 1. only if your program is…

>only if your program is embarrassingly parallel is irrelevant, because a almost every program is embarrassingly parallel in Erlang. The language is built around concurrency to the point that parts which wouldn't be obviously parallel in another language are in Erlang. Further, slow hashes in crypto have taught us that is actually quite difficult to make something which can't be parallelized.

OK. Not an Erlang user, but I can't let this statement go.

I've studied parallel numerical algorithms. Many/most of them will involve blocking because you're waiting for results from other nodes.

If you're saying Erlang has somehow found a way to do those numerical algorithms without having to wait, then I'd love to see all those textbooks rewritten.

Amdahl's Law reigns supreme.

Re: What's all this fuss about Erlang? (2007)

#94

Post by ww520 »

di4na wrote: post #90
chrisseaton wrote: post #9

> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…

You mistake concurrency with parallelism. If each of your "synchronous" call to a method is an asynchronous message, suddenly, all your program is embarasingly concurrent. Wait... was that what Alan Kay was saying with SmallTalk ? Would we have all lost our mind on RPC and synchronous calls for so long? Yes. Yes we did.

"Embarrassingly concurrent" is not embarrassingly parallel. Parallelism is not merely making things concurrent nor making synchronous calls into concurrent async calls.

Re: What's all this fuss about Erlang? (2007)

#95

Post by chrisseaton »

devishard wrote: post #86
chrisseaton wrote: post #9

> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…

>> Your Erlang program should just run N times faster on an N core processor > But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. You've made two claims, one irrelevant and one false: 1. only if your program is…

> almost every program is embarrassingly parallel in Erlang

I can't agree with that, and it's key to my point. There are some problems which we just don't know how to make embarrassingly parallel. Take something classic like mesh triangulation or mesh refinement. Nobody knows how to make those embarrassingly parallel. If you write it in Erlang, it's still not going to be embarrassingly parallel. And it won't scale linearly to N times faster on N cores no matter which language you write it in.

So it's just not true to say that any Erlang program should scale linearly. If nobody on earth knows how to make mesh refinement scale linearly, how will Erlang do it?

Maybe you mean you wouldn't choose to write those programs in Erlang? Well then I think it's a meaningless claim to say Erlang will linearly scale your program, but only if it is a program which is naturally linearly scalable anyway. Erlang hasn't helped you do anything there so why make a claim about it?

Re: What's all this fuss about Erlang? (2007)

#96

Post by di4na »

ww520 wrote: post #94
di4na wrote: post #90

Earlier quoted context omitted.

You mistake concurrency with parallelism. If each of your "synchronous" call to a method is an asynchronous message, suddenly, all your program is embarasingly concurrent. Wait... was that what Alan Kay was saying with SmallTalk ? Would we have all lost our mind on RPC and synchronous calls for so long? Yes. Yes we did.

"Embarrassingly concurrent" is not embarrassingly parallel. Parallelism is not merely making things concurrent nor making synchronous calls into concurrent async calls.

once you are concurrent, what stop you from being distributed to multiple cores ?

Re: What's all this fuss about Erlang? (2007)

#97

Post by di4na »

derefr wrote: post #92
di4na wrote: post #84

Earlier quoted context omitted.

It does that. This is an erlang release, and that is something that erlang does really well. The problem lie more on the tooling that made it harder than it should have been. This is what Elixir bring to the table.

An Erlang release is not a static binary. It certainly is (or starts off as) a self-contained directory you can just unzip onto a server—but for the kind of software I'm talking about (RabbitMQ, CouchDB, Riak, etc.) you don't tend to install these things this way. You expect to install them using your distro's package manager. And, until very recently, distros did horrible things to those packages to force them into…

Well there is something to do that. Exrm has some plugin to output a .deb. And it could be done for other package format. Once again, it is a tooling problem.

Re: What's all this fuss about Erlang? (2007)

#98

Post by ww520 »

di4na wrote: post #96
ww520 wrote: post #94

Earlier quoted context omitted.

"Embarrassingly concurrent" is not embarrassingly parallel. Parallelism is not merely making things concurrent nor making synchronous calls into concurrent async calls.

once you are concurrent, what stop you from being distributed to multiple cores ?

I hate to do this but I have to quote you, "You mistake concurrency with parallelism."

Re: What's all this fuss about Erlang? (2007)

#99

Post by di4na »

ww520 wrote: post #98
di4na wrote: post #96

Earlier quoted context omitted.

once you are concurrent, what stop you from being distributed to multiple cores ?

I hate to do this but I have to quote you, "You mistake concurrency with parallelism."

Not really. Once again. What stop completely concurrent code to run on different schedulers ?

Re: What's all this fuss about Erlang? (2007)

#100

Post by chrisseaton »

PopsiclePete wrote: post #91
chrisseaton wrote: post #9

> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…

"Trivial" to write parallel programs in C? You should stop doing whatever it is that you're doing, because you are in the top 0.00000000001% of programmers, in the Universe, and I want to work on whatever multi-billion dollar startup you undoubtedly have going on.

I said it is trivial to parallelise a C program that implements an embarrassingly parallel algorithm. Embarrassingly parallel means no resources need to be shared, and there needs to be no communication, so no need for locks or messages, even in C. That's why I say it'd be trivial to parallelise it. Just add a pthread_start. Of course almost no applications are embarrassingly parallel.
Post reply on HN