"Sinatra + Sequel is already very competitive in web performance with Go"

A lot of the time, that "competitive with X" in web frameworks is because the scripting language has a web server coded in something other than the scripting language. I don't know about that exact stack, but I know that's the case for Node, for instance. The web server is written in C. So when you benchmark a "tight loop" in those languages, you are running 99% C and 1% your scripting language.

Now, that is not a bad thing. It is a valid result, in the sense that it is a good thing for environments to have fast web servers, and nobody cares what the implementation language is... with perhaps the sole exception of this case, where we're trying to compare the performance of scripting languages by their web server implementation. You can't claim "Scripting Language X is fast because it has a fast webserver!" when the webserver isn't written in Scripting Language X.

(A moment's perusal didn't show me what this particular web server is implemented in. If someone can link me to that web server and show it's implemented in Ruby, I'll be happy to eat my words here. But if the performance is comparable to Go, that's enough evidence it isn't written in Ruby to satisfy me until more evidence comes in. If Ruby isn't a slow language, you've defined "slow language" to the point that no language is slow. There isn't much competition in the "slower than Ruby" field; Perl 6 is pretty much the only entrant I know of. There's a number of languages as slow as Ruby, it is not uniquely slow, but there's almost nothing slower.)

Ed: regarding the benchmark, as best I can tell, the top listing for ruby runs under puma:

https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

PostgreSQL is obviously not written in ruby, but the other components are very much "ruby code". There appears to be c/Java extension for ssl and parsing http, though - but AFAIK the main server is ruby.

https://github.com/puma/puma/tree/master/ext/puma_http11

Tangential, but you might enjoy:

https://deno.land/v1#http-server-performance

> A hello-world Deno HTTP server does about 25k requests per second with a max latency of 1.3 milliseconds. A comparable Node program does 34k requests per second with a rather erratic max latency between 2 and 300 milliseconds.

> Deno's HTTP server is implemented in TypeScript on top of native TCP sockets. Node's HTTP server is written in C and exposed as high-level bindings to JavaScript. We have resisted the urge to add native HTTP server bindings to Deno, because we want to optimize the TCP socket layer, and more generally the op interface.

Please note that Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media). Also: not sure how long ago you tried using Perl 6 and found it slow. If your data is from the Parrot days, it is definitely out of date: the MoarVM backend is at least two orders of magnitude faster.

While Raku is generally slower than other languages, there are times when it is is faster than those same languages.

There was even one report of it being faster than C/C++.

(My guess is that the C/C++ code was doing a lot of string copies and/or scanning for a null terminator. The MoarVM backend doesn't generally do either of those things.)

Not sure how "overblown" the performance issue is. I rewrote two commercial Rails apps to Phoenix and had both versions of both apps run side by side for two months. The Phoenix apps consumed 7x-11x less RAM, accomodated 9x-10x more users on identical hosting instance, and had almost 10x quicker response time.

Phoenix is written in Elixir -- another dynamic language.

I am willing to argue with facts but you just added another non-factual opinion to the pile.

...Oh, and a Mario game implementation says nothing about the typical production uses of a language and its stack.

That, plus the fact that most Ruby users don't go for Sinatra and Sequel.

> I am willing to argue with facts but you just added another non-factual opinion to the pile.

I'm not interested in arguing with someone who doesn't respect others opinions, nor did I make baseless claims: I cited resources.

> ...Oh, and a Mario game implementation says nothing about the typical production uses of a language and its stack.

It's true, the mario runthrough was in pure ruby and not rails, and that rails has a slower performance vs. Ruby + Sinatra.

> I'm not interested in arguing with someone who doesn't respect others opinions, nor did I make baseless claims: I cited resources.

Performance metrics are not opinions.

Ruby is slower than php.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I've seen conflicting benchmarks on this showing different results - possibly has changed over time, or run different comparisons. What you linked seems current at least.

Also keep in mind that as far as performance of dynamic languages goes, all of the P* languages (Perl, Python, PHP, and... Ruby ;)) have been left in the dust by the front-runners (eg Node.js or LuaJIT). Perl used to be king a long time ago, eventually, PHP took pole position, and maybe now it's Ruby's time to shine. But being leader of that particular pack could mean you're nevertheless still 'slow' depending on context.

I wouldn't put node in with luajit. Luajit is about 4x faster than v8 JavaScript. So it's still in the slow category

Depends on the benchmark. Eg at the bottom of this page [1] can be found a simple fib(40) comparison of a few runtimes.

The Node time is at 2.6x the LuaJIT time, which I'd still consider in the same ballpark compared to eg the factor of 31x achieved by Python3.

[1] https://github.com/wasm3/wasm3/blob/master/docs/Performance....

No, both your post and this reply are dogmatic. As I said, Ruby is the slowest modern dynamic programming language (and it's much slower than Perl). I really wish the Ruby community would listen to valid criticism. All dynamic languages are deeply flawed in some way, especially Ruby, and most ecosystems are open to learning from others.

> All dynamic languages are deeply flawed in some way, especially Ruby

That sounds pretty dogmatic itself. You don't have to like dynamic languages - but that doesn't mean they are deeply flawed. The same could be said for statically typed languages with a different set of values.

> …much slower than Perl

To do some things but not others?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...