This is created by Chris Seaton, who works on TruffleRuby at Shopify

Lol. I couldn’t remember his name from his HN comments.

It's just impossible, ruby / python will always be fast'ish never really fast because the foundation was not built for it.

I don't believe it's impossible, although it's certainly a large undertaking. TruffleRuby already optimizes some "slow" features of Ruby quite well. E.g., it's able to inline blocks and JIT compile metaprogramming features. I haven't really kept up with all that Crystal is doing these days, but if you can optimize the hard parts of Ruby, you eventually just get into the traditional trade-offs between AOT and JIT compilation.

(Full disclosure: I work on TruffleRuby, in case that matters.)

JS used to be thought of as a slow language, then better VMs came along and now it's fast. I think it's much more a function of how much resources have been expended on developing a fast VM than the fundamentals of the language, though it will always be much harder to make a fast VM for Ruby than something like Lua.

What you lose in execution time you generally gain in development.

> ruby

> doubt

> "What you lose in apples you gain in oranges"

I didn't know different units could be compared as if they had an equivalence ratio...

This feels like it is said in bad faith because I suspect you know exactly what is meant.

If you really want to be pedantic, 1_000_000 user operations are to be done. If you write something that does 1_000_000 user operations/second, and it takes 6 mos to write, it'll be done in 6 mos and 1 sec.

If it only does 500 ops/sec but takes 1 day to write, it'll be done in ~3.3 days.

Which one is faster?

Whole system optimization is the key. One can't optimize in isolation. Will it run once? What are the inputs? How much memory will it take? How important is the result?

Now we are in the regime where parallelism and memory bandwidth efficiency is more important than constant factors of speed increase. 1k, 10k or 100k cores will be commonplace, even with slow interpreted code, the code the scales to more cores faster will win, even against C++. We already have more cores than we know what to do with.

You're ignoring the cost of running the code, latency, and the many overheads and potholes of horizontal scaling. There's a reason large codebases are being rewritten from python, ruby, php to java, go, rust.

Those large codebases are being rewritten in languages that support large dev teams and the tooling that static type systems can support.

Horizontal scaling isn't the reason and nor is it the bugaboo you make it out to be. Vertical scaling might get you a factor of 100 on modern hardware over dynamic languages, vertical with threading might get you to 1000x, massive parallelism afforded by the coming exponential jump in core counts is going to get folks to 10-50k increases in throughput.

> Those large codebases are being rewritten in languages that support large dev teams and the tooling that static type systems can support.

Of course that's one of the reasons, and that goes directly against the notion that python and ruby are somehow cheaper or more efficient to develop in.

> Horizontal scaling isn't the reason and nor is it the bugaboo you make it out to be.

The point is horizontal and vertical scaling don't automatically resolve the drawbacks of slow code. Using 10x the resources to make up for slow code is generally not a solution if performance actually matters.

> Vertical scaling might get you a factor of 100 on modern hardware over dynamic languages, vertical with threading might get you to 1000x, massive parallelism afforded by the coming exponential jump in core counts is going to get folks to 10-50k increases in throughput.

Not sure what you're trying to argue here. Yes 'dynamic' languages are slower, yes you can vertically and horizontally scale both. I don't see how that's relevant for a comparison of languages.

languages like python usually have shorter time to market at the cost of it running slower.

So sure they can't be directly compared but that doesn't mean that one cannot effect the other.

> languages like python usually have shorter time to market at the cost of it running slower.

Let's see the data on that. Then let's see the cost of maintenance vs Java.