[Argorak]

Then say Rails. Rails doesn't care about memory. There are frameworks of similar targets like Rails that tend to use less (e.g. Padrino) and care. We did have an effort pushing down unnecessary memory use of the base profile and we gained in slabs.

Also, you can move to JRuby if you want a one-process/threaded model, which will get memory-conservative very quick. A JRuby thread will quickly get you into the ranges that you quote for go + the base cost of the JVM.

[grey-area]

The figures you quote above are better than Rails but still almost an order of magnitude worse than Go. Clearly there's something else going on. I'm not saying everyone should abandon Ruby and move to Go (and I think neither is the article), but we should be aware of the tradeoffs involved in each tool choice (Ruby, Ruby with JVM, Go etc).

[Argorak]

You are still comparing apples with oranges. Go and even Padrino (which is a full-stack in a full blown install) are not even the same category.

Point being that memory comparison even in the Ruby/Rails space are incredibly problematic, often influenced by the runtime (and heavily so). Still, the discussion is incredibly simplistic (for example by assuming that you are running unicorn/fork).

If a discussion about memory issues does not include an exact reference to the runtime and implementation of the system used, I would consider it void immediately.

Same for Go.