News for hackers. Stuff that matters.
Re:Seeking new test ideas for Framework Benchmarks Round 4+ by spullara on Friday April 12, 2013 @01:46AM (#5536873)
Sadly that isn't very true anymore. Databases (and I/O — think SSD) really are faster than most of the dynamic languages these days.
Re:Seeking new test ideas for Framework Benchmarks Round 4+ by coolsunglasses on Friday April 12, 2013 @12:50PM (#5539619)
That's a pretty nonsense sentiment. How can a database be "faster" than a language?
Re:Seeking new test ideas for Framework Benchmarks Round 4+ by spullara on Friday April 12, 2013 @01:05PM (#5539719)
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.
Re:Seeking new test ideas for Framework Benchmarks Round 4+ by coolsunglasses on Friday April 12, 2013 @01:13PM (#5539773)
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?

Re:Seeking new test ideas for Framework Benchmarks Round 4+ by spullara on Friday April 12, 2013 @04:49PM (#5540911)
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.