Hacker News Reader

Comment by kjksf | Hacker News Reader

I would expect this kind of article to start with numbers showing that Erlang's GC has shorter GC pauses than, say, Java or Go and then explain why this is so.

Instead it merely states that Erlang GC has better latency than other system and we're supposed to just believe it.

It's fine as a description of how Erlang GC works but totally useless as an argument that Erlang has short GC pauses.

View on HN

Here is a semi-recent benchmark for Phoenix, which is written in Elixir (runs on the Erlang VM, BEAM). I think it will give you a decent idea of the differences: https://gist.github.com/omnibs/e5e72b31e6bd25caf39a

I would like to see this run with the latest versions of the various platforms, as a lot has changed since Phoenix 0.13, and I'm sure it has for the other platforms that were benchmarked as well. Initially, it seems like there is not a lot of difference between most of the platforms, but when you're working with variances of 1-2 ms on 180k rps is pretty substantial.

Would it be possible to update node.js to v4.0.0 and rerun the Express Cluster benchmark? node.js v0.12.x was slower than v.0.10.x, while v4.0.0 is supposed to be faster than both. Sorry for making this request if it's out of your field of interest, but couldn't resist asking :)

EDIT: My mistake, I thought you were the author of the benchmark

I think there is a bit of information left out here (presumably because it is assumed to be understood by the reader), but it is not uncommon for erlang applications to have millions of different processes active at the same time. As such, since memory management is (mostly) isolated within a single process, you have a de-facto sharded garbage collector. This, as the article explains, is a core trait that helps with the soft realtime guarantees erlang brings.

Reply on news.ycombinator.com