4 ms·

As a passive consumer of the benchmarks/info, I've got to say a huge "Thanks" for this! I've been a watcher of the Debian benchmarks game for a long time (sinc

As a passive consumer of the benchmarks/info, I've got to say a huge "Thanks" for this! I've been a watcher of the Debian benchmarks game for a long time (since its inception), but, after using Python, Ruby, Haskell, etc, had written off JVM languages as either slow (e.g. Groovy) or non-expressive (e.g. Java)... This benchmark has got me seriously interested in JVM languages again. (Note: I don't want to use Scala^H^H^H^H^HFrankenstein) Given the computational ability of browsers, the "front end" is rich and the "back end" is shrinking down to just the API. I'm not sure that the extra verbosity of Java is too large a cost for the performance it offers. I currently have an application doing 1500 requests a second on Django and it's using 3 servers. I could have used only one server if I'd used Java or Clojure? Hmmm...

coolsunglasses 14y ago
> I could have used only one server if I'd used Java or Clojure? Hmmm... Use Clojure, but keep in mind that if you're not caching aggressively you can saturate persistence-side quickly - making your choice of application language irrelevant.
- spullara 14y ago
  Sadly that isn't very true anymore. Databases (and I/O — think SSD) really are faster than most of the dynamic languages these days.
  - coolsunglasses 14y ago
    That's a pretty nonsense sentiment. How can a database be "faster" than a language?
    - spullara 14y ago
      For example, going to the database and retrieving the data uses less CPU and time than deserializing the data into an object into Ruby. That is the sense I am talking about. The bottleneck becomes the code talking to the database rather than the database itself.
      - coolsunglasses 14y ago
        That's...that's not how it works. I was talking about the scalability of the database as that's a brick wall you hit long before anything else. You can always fire up more rails workers, scaling persistence is a PITA. Are you intentionally misunderstanding me in order to make a strange and irrelevant point?
        spullara 14y ago
        I'm not making a pure scalability argument. Your solution of scaling the rails tier still suffers from far higher latency thus making choice of language/VM relevant. Rails is very, very slow — even if you cache everything behind it. So yes, you can scale it up, but it is at least 10x more expensive to do so.
bhauer 14y ago
We've got more Haskell, some Erlang, Lua, more Scala, a bunch of PHP, and myriad other goodies in Round 3 thanks to a bunch of pull requests. I think Round 3 is going to show a lot more competition at the top tiers.
meddlepal 14y ago
The Groovy is slow argument has sort of run out of steam in my opinion. Support for invok-dynamic and the static compilation annotation provide a lot of speed. I use Groovy daily and my experience is anecdotal but maybe it is time to do some benchmarks of my own.
- vorg 14y ago
  Dynamic-mode Groovy is as slow as other dynamic languages. The recently added static-compilation mode for Groovy still regularly spews up bugs, perhaps because it was written by a single programmer with little beta testing whereas Scala and Java have many high-pedigree developers behind them, and heaps of documentation and testing.

coolsunglasses 14y ago

> I could have used only one server if I'd used Java or Clojure? Hmmm... Use Clojure, but keep in mind that if you're not caching aggressively you can saturate persistence-side quickly - making your choice of application language irrelevant.

spullara 14y ago
Sadly that isn't very true anymore. Databases (and I/O — think SSD) really are faster than most of the dynamic languages these days.
- coolsunglasses 14y ago
  That's a pretty nonsense sentiment. How can a database be "faster" than a language?
  - spullara 14y ago
    For example, going to the database and retrieving the data uses less CPU and time than deserializing the data into an object into Ruby. That is the sense I am talking about. The bottleneck becomes the code talking to the database rather than the database itself.
    - coolsunglasses 14y ago
      That's...that's not how it works. I was talking about the scalability of the database as that's a brick wall you hit long before anything else. You can always fire up more rails workers, scaling persistence is a PITA. Are you intentionally misunderstanding me in order to make a strange and irrelevant point?
      - spullara 14y ago
        I'm not making a pure scalability argument. Your solution of scaling the rails tier still suffers from far higher latency thus making choice of language/VM relevant. Rails is very, very slow — even if you cache everything behind it. So yes, you can scale it up, but it is at least 10x more expensive to do so.

bhauer 14y ago

We've got more Haskell, some Erlang, Lua, more Scala, a bunch of PHP, and myriad other goodies in Round 3 thanks to a bunch of pull requests. I think Round 3 is going to show a lot more competition at the top tiers.

meddlepal 14y ago

The Groovy is slow argument has sort of run out of steam in my opinion. Support for invok-dynamic and the static compilation annotation provide a lot of speed. I use Groovy daily and my experience is anecdotal but maybe it is time to do some benchmarks of my own.

vorg 14y ago
Dynamic-mode Groovy is as slow as other dynamic languages. The recently added static-compilation mode for Groovy still regularly spews up bugs, perhaps because it was written by a single programmer with little beta testing whereas Scala and Java have many high-pedigree developers behind them, and heaps of documentation and testing.