>Secondly, Ruby on Rails and other dynamic frameworks are not popular because their performance issues can easily be discarded compared to Java. They are popular because they make a tradeoff between development speed and execution speed.

But that's the crux of his argument. If storage speed improves by leaps and bounds it becomes comparatively more expensive (from a performance standpoint) to use these other languages. The terms of the tradeoff change.

Even if all your databases are running at LUDICROUS SPEED thanks to SSDs, his argument is still irrelevant. That same LUDICROUS SPEED can be applied to technologies which can be used to mitigate the computational times of slower languages (e.g. caching)

Faster permanent storage will only help to close the ENROMOUS GAP between disk access latency, RAM access latency, and CPU cache access latency, which has continued to grow over time.

As Cliff Click said: RAM is the new disk. The real place languages like Ruby are suffering is through excessive object creation and mutation which blows the CPU cache. That would be a cogent argument. SSDs = LUDICROUS SPEED does not.

Yes, but hardware will actually become cheaper and faster, not more expensive and slower and therefore hardware resources also become less relevant. The terms of the tradeoff actually change in favour of "easy" development frameworks. It is true that Java will benefit from this more than Ruby and friends will, but that doesn't really change the reasons people choose these anyway (because it is not about performance, it is about labour).

This is the same argument made when claiming that JS will catch up with native app development.

It's a flawed argument: any solution that relies on 'hardware will get faster' will only ever be able to catch up to yesterday's state of the art.

Meanwhile, the state of the art will move forward as it takes advantage of increased resources or lower operational costs.

Yes, but what is the state of the art of most server-side web apps, really. Even the most successful web apps don't do all that exciting stuff. Most are just pushing data around and perform well enough with whatever tools you throw at it. In many cases performance is simply not that much of an issue compared to other factors such as development speed.

Javascript is a front-end technology and therefore it is really different and not really suitable for comparison in this case.

When application-server performance becomes the bottleneck, you'll see increased adoption of things like caching, JIT'ed languages and asynchronous approaches to distributing work across different threads.

I have experimented a lot with in-memory databases and, most of the time, they are still the bottleneck.

That's certainly the argument he makes. Unfortunately it's not a good one.

If anything it could mean the end of in-memory key/value stores (ie: memcached)

> but human labor will likely still be more expensive than the servers running the applications

Unless you outsource.

They're not equivalent in the same way that pigs and mud are not equivalent.