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

101–110 of 193 posts

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

#101

Post by ww520 »

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.

Parallel programs really are not that hard to write. The hard part is figuring out how to make a problem into embarrassing parallel. Once that's figured out, the coding is simple. In this case, the language choice won't help.

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

#102

Post by plainOldText »

slashdotdash wrote: post #4

Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1] [1] https://startlearningelixir.com/elixir-for-rubyists

There's also a very nice video explaining certain aspects of Elixir by Dave Thomas: https://youtu.be/5hDVftaPQwY

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

#103

Post by mnd »

plainOldText wrote: post #102
slashdotdash wrote: post #4

Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1] [1] https://startlearningelixir.com/elixir-for-rubyists

There's also a very nice video explaining certain aspects of Elixir by Dave Thomas: https://youtu.be/5hDVftaPQwY

There’s also “Erlang the Movie”; the designers of Erlang demo some of the qualities of the Erlang system in a delightful way: https://youtu.be/xrIjfIjssLE

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

#104

Post by molloy »

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…

> I've yet to find a language that can communicate between threads as performant-ly.

Minor nitpick: Erlang uses processes, not threads. Your comment doesn't explicitly say that Erlang uses threads though, so perhaps I'm being overly pedantic.

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

#105

Post by pertymcpert »

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…

WTF. How do you turn a problem which cannot be reduced into parallel sub-components into an Erlang program then? Are there just a huge class of computations that cannot be done with Erlang? Of course not.

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

#106

Post by ww520 »

di4na wrote: post #99
ww520 wrote: post #98

Earlier quoted context omitted.

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 ?

What you described is concurrency. What OP was talking about is parallelism.

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

#107

Post by aeturnum »

BeetleB wrote: post #93
devishard wrote: post #86

Earlier quoted context omitted.

>> 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,…

I'm not devishard, but I parsed his statement slightly differently. He's not saying that Erlang makes things parallel magically. Rather, he's saying that Erlang forces tasks that /could/ be parallel to be parallel by default. Thus, Erlang will tend to maximize the sections of your program that are run in parallel compared to other languages.

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

#108

Post by derefr »

di4na wrote: post #97
derefr wrote: post #92

Earlier quoted context omitted.

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.

The kind of .deb produced by Exrm (or by just packing up the release using FPM or the like) would never be accepted upstream by a distro maintainer. This is a political problem, in that distro vendors have strong philosophical stances on how to do packaging, and those stances make packaging Erlang programs to suit their tastes really hard (and frequently impossible for newer software, since they say things like "you must depend on the system erlang package rather than embedding ERTS; and the erlang package on LTS will be held at R16, so it doesn't support maps.")

Of course, when people install your software "manually", you can distribute it however you like—a zip of an Erlang release, like a Java JAR, is already quite a convenient format for such installations all on its own. But when people want to install something that depends on your software (like, say, OpenStack depends on RabbitMQ), they don't want to spend nearly as much time thinking about your package. They don't know you exist, and they don't want to know you exist—they want the distro to handle that detail for them. So you're stuck fighting the distro. (And things like OpenStack are stuck doing non-distro-packaged releases to avoid the problem.)

Which brings me back to my original point: "snaps" are promising not because they sandbox packages, but because they're a countervailing philosophical movement on how software should be packaged. A distro that supports snaps is a distro that has made room in its heart for packages that don't want to break things down into little FHS-arranged dep-graph-divided bits. It gives them an out, a place to put these packages rather than just denying them outright.

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

#109

Post by BeetleB »

aeturnum wrote: post #107
BeetleB wrote: post #93

Earlier quoted context omitted.

>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,…

I'm not devishard, but I parsed his statement slightly differently. He's not saying that Erlang makes things parallel magically. Rather, he's saying that Erlang forces tasks that /could/ be parallel to be parallel by default. Thus, Erlang will tend to maximize the sections of your program that are run in parallel compared to other languages.

Which would make the original commenter's point valid:

>Your Erlang program should just run N times faster on an N core processor

No, it won't. It will only be true for tasks that /could/ be (completely/embarrasingly) parallel (as you say). Which is kind of circular.

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

#110

Post by tempz »

aaron-lebo wrote: post #2

I think the "more cores == faster" benefit is overstated. Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off. I suspect other languages are going to fold t…

Erlang is made for IoT.

Tens of millions of concurrent unrelated clients, embarrassingly parallelizable, scales linearly with number of cores, as these share nothing.

Post reply on HN