[stesch]

I like the benchmark and I appreciate the work that was put into, but Erlang is missing again.

If you don't even consider Erlang you won't miss it. But if you know it has some strengths for this kind of job and you don't mind the syntax, you'd like to see it compared to other solutions.

[kainsavage]

I just posted another response to this - we had some trouble with the package manager for Erlang after round 6. Additionally, I had been working on improvements for the suite specifically (better logging/reporting, etc) and did not get a chance to resolve the Erlang problems.

Rest assured, "get erlang running again" tops my 'todo' list for round 9.

[SkyMarshal]

While we're at it, any chance of you guys including some Elixir frameworks too? I'd love how to Elixir performance is starting to take shape vs native Erlang frameworks.

[brickcap]

As far as I understand exlir compiles into erlang code. So there should be no performance difference.

[SkyMarshal]

That's never been the case with other languages like Scala or Clojure that target another VM bytecode, definitely not an assumption you can just make.

[agilebyte]

I have heard that string operations (and I thus suspect JSON parsing too) is slower on Erlang. Maybe it is not included as it was not built for raw speed but rather stability, hotswapping code etc?

[rdtsc]

String equivalents in Erlang are binaries quite often. There are also iolists, those are pretty efficient.

This blog post describes this in a lot more depth:

http://jlouisramblings.blogspot.com/2009/01/common-erlang-mi...

[stesch]

Erlang was included in round 6 of the benchmark.

[agilebyte]

Ah thanks, under Cowboy and Elli.