Hacker News Reader

Comment by Ono-Sendai | Hacker News Reader

Looks somewhat ugly and also slow. (each element is processed in a separate process)

Right, but in the erlang VM (and thus Elixir), processes are not OS processes, they are very very small processes internal to the VM. It's not uncommon to have multiple processes get spawned for each request that comes into a server and to end up having tens or hundreds of thousands of processes on a single VM at any given point.

Edit: Geez, I even did a refresh check before clicking submit. I'm having the worst luck with that lately.

It was there to illustrate a point. And of course if you read the blog post you'd realize what an Erlang process is. It is like an OS process in that memory is not shared but it is only a few KB of memory overhead because it is also a lightweight thread. Yes, it sounds like it is magic, that it is not possible, but it is.

These are Erlang VM processes which are actually quite fast.

Re ugly: well, eye of the beholder I suppose.

Here's a map in my functional language (winter). It's not parallel yet, that shouldn't affect the syntax though. (map is already manifestly parallel)

def square(float x) float : x*x def main(array<float, 256> a) array<float, 256> : map(square, a)

Now make it efficiently parallel and show us the implementation. Then we could compare it with the Elixir snippet, which does just that.

Not just efficiently parallel, but easily distributable to multiple nodes.

Exactly. With a tiny change you can be spawning those processes to any number of other nodes.

Well, if we are putting forth other languages, here's Perl 6:

  sub pmap(Code $func, @items) {
    return await @items.map: {
      start { $func($_) }
    }
  }

Indeed. There are better strategies for splitting up the work among several processes than to spawn a new one per element. While processes in BEAM are fairly cheap, they are not free. So I think your point is valid.

Reply on news.ycombinator.com