>>> It makes perfect sense to me

Yes. Other than some very basic scripts, I have never worked with Ruby, so I was not aware that it is so slow. Thanks for pointing that out.

As for my recommendation, it is pretty standard worker architecture:

Their system seems to be an ingesting-only system, that is, the clients are getting an empty HTTP 200 OK response. Given this, I would put openresty (nginx) in the front, with some trivial Lua code[1] to en-queue payloads to beanstalkd. Then, you can either have your workers inside openresty (using Openresty timers) or have them as separate processes and written in the language of choice. We have been using this for a couple of years now and it is working really well for our use case, also an ingesting-only system.

[1] https://github.com/smallfish/lua-resty-beanstalkd/blob/maste...

we use the same technology with KONG [1]

[1] https://github.com/mashape/kong

Scala, Java, Clojure, C#, F#, Node, LuaJIT, Erlang, Elixir, Haskell, D, Nim... There are lots of reasonably fast options out there that aren't C.

> Go is 1-2 orders of magnitude faster than Ruby

That may be true for some types of code, but for an app that's predominantly shuffling data over the network you should be spending most of the time in kernel space executing syscalls, and then language differences are largely irrelevant.

> and much easier to write concurrent code in.

How? Writing concurrent code in Ruby is trivial since 1.9.x (prior to 1.9 you had to battle the green threads in MRI for some stuff), which isn't exactly new.

> Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in.

Than MRI Ruby you mean.

The advantage wouldn't be as much if Ruby designers cared to add AOT compilation in the same vein as Dylan or Common Lisp to the canonical implementation.

That's exactly the space that Crystal [0] seems to be exploring. Statically type checked and pre-compiled via LLVM. So it isn't the Ruby designers themselves, but definitely Ruby flavored.

0: http://crystal-lang.org/

> > Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in.

> Than MRI Ruby you mean.

Given the nature of orders-of-magnitude comparisons and the lack of Ruby implementations that are even one order of magnitude faster than MRI, "...than Ruby" is reasonably accurate if "...than MRI Ruby" is at all accurate.

> The advantage wouldn't be as much if Ruby designers cared to add AOT compilation in the same vein as Dylan or Common Lisp to the canonical implementation.

Maybe, though that's unproven. AFAIK, actual Ruby implementations with AOT only seem to gain about a factor of 2 improvement, not an order of magnitude.

I was always a big fan of Erlang's concurrency model but I've really been getting into Elixir lately. It is just such a productive language to write and lends itself to extremely maintainable codebases.

There's nothing concurrent in this case, parallel sure, but concurrency wise this is all shared nothing. And languages are not faster than one another. They are faster at certain tasks but the variability for a given task is really case specific. For io heavy workloads like this underlying libraries and implementations dominate execution time.

You could have written this in any number of languages. I don't know why go is more logical than say Java JavaScript.

Lua would beat go every day of the week.

[citation needed]

As Clojure would beat Lua every second of a day.

I'm a big clojure fan and not the biggest Lua fan, but I'm afraid you are mistaken. You won't find any dynamically typed language implementation that can come close to LuaJIT for the general use case.

What if you type hint everything in Clojure properly so all reflection is avoided? (does take some time, but with something like YourKit it'll be only a few hours max on a mid-size project)

If you're talking about raw performance, I'm afraid you're mistaken. If you're perhaps referring to the 'aesthetics' of the language syntax, that's pretty subjective, in which case you're right for your tastes.

show me the clojure firewall and I'll take you seriously. Or the even something simple as an interesting clojure ML project. Java gross.