Also premature optimisation. I did image manipulation and statistical analysis of images using predominantly Ruby for my MSc thesis work 15 years ago, and it took rewriting a couple of dozen lines of code with RubyInline (to use C) to remove the bottlenecks. Using pure Ruby to prototype and rewriting just the maths heavy code to C when I knew it worked and knew where the bottlenecks were saved me massive amounts of time. I've done map rendering in Ruby for similar reasons - outside of specific niches, it's rare for the speed of Ruby to be an issue.

One funny anecdote (and unfair one) is that what Twitter wasn't able to do (rails scale), Mastodon did.

I recall several discussions of it at the time, and I don't think it's so much that they weren't able to, as that they'd made lots of disastrous architecture decisions (building it around a monolithic database etc.) that required a rewrite, and whomever doing it used it as an opportunity to blame it on Rails as an excuse to switch to their preferred stack.

After all, sharding message distribution via federation (even if you hide the federation behind a veneer of a global userid -> shard mapping) was a well understood long before Twitter even launched (e-mail... reflectors...), so it was a rather embarrassing architectural decision to not even try to account for it. Heck, I co-founded a webmail provider in '99, and one of the first things we did was implement ways to map user ids to a distributed set of backends and support for migrating accounts between backends, because we knew it'd be necessary to be able to shard smtp servers, frontends, and storage separately. That wasn't in Ruby, but the architectural pattern is so obvious.

The language change may or may not have made sense for them at the time (after all Ruby was much slower then, and they by then had the size where a rewrite of core parts to cut hosting costs might have been worth it), but that they blamed their architectural failures on Rails was a cheap shot.

Normally such decisions come from "Senior developers", which are experts in other domains than ruby on rails. How often you see them wanting to write raw sql in rails, "because its faster" and/or "much easier".. this summarizes a lot that problem https://daedtech.com/how-developers-stop-learning-rise-of-th...

> did you benchmark Jruby or TruffleRuby? Did you compile c-ruby with jemalloc?

Jruby a little faster than CRuby (it used to be more significantly faster, but CRuby has seen more recent performance increase); TruffleRuby is, OTOH, not slow like other implementations.

> Normally the "ruby is slow" argument, is based on not being involved with ruby and solving real problems with it.

Ruby is abstractly my preferred language, and I’ve done a fair amount in it, though I don't get to use it as much in anger because of issues other than its speed (ending up using another slow language as my main day to day.)

> Some people will just LOL this argument even harder if you add development time and code maintenance costs on that equation.

That’s just equivocation; time and cost to market is an orthogonal concern to execution speed, not a component of it; yes, Ruby has a decent code-writing experience, especially for small systems.

> That’s just equivocation; time and cost to market is an orthogonal concern to execution speed, not a component of it; yes, Ruby has a decent code-writing experience, especially for small systems.

Probably you meant rails here. I don't see why ruby should be a problem for something not small, moreover, you should first define what a small system is, specially if you count the LOC of all the gems that you use..