[stevebmark]

Benchmarks are subjective, but all benchmarks show Ruby as slower than compared dynamic languages. The relative speed difference is different per benchmark, but across the board Ruby is slower.

It fundamentally has to be slower. Ruby is the most dynamic of the dynamic programming languages. And the community has embraced metaprogramming, making it every more dynamic. Especially on webservers, you'll be executing hundreds, sometimes thousands, more lines of code than other servers, especially in a mature system.

Is it "slow" enough to matter? Probably not until you get to a medium scale. Everywhere I've worked, we've had to on average double the hardware specs for Ruby servers to make them as performant as other dynamic language applications we run. Not the most expensive thing in the grand scheme of things, but there are entire cottage industries of magically tuning Ruby and Rails that you don't have to worry about with other systems until much larger scales.

[mindfulmore]

The article doesn't even discuss benchmarking Ruby against other languages, so I'm not really sure what you're on about. Couldn't resist taking a performance jab at Rails?

Also, I'll take "double the hardware specs" if it means I'm actually able to focus on what I'm building and not dicking around with devops or rebuilding all of stuff Rails metaprograms for me by hand.

If there was a framework for being as productive as Rails at half the cost then it would be flourishing. There isn't and as a result Rails isn't going anywhere any time soon.

[pdimitar]

> Also, I'll take "double the hardware specs" if it means I'm actually able to focus on what I'm building and not dicking around with devops or rebuilding all of stuff Rails metaprograms for me by hand.

Try 7x to 11x. That's the amount of reduced RAM usage -- and the amount of increased accommodated users -- on identical hosting by the two apps I rewrote from Rails to Phoenix.

> If there was a framework for being as productive as Rails at half the cost then it would be flourishing.

Bold of you to assume technical merit is the only factor. Historically this has almost never been true. There are a number of web frameworks that perform much better than Rails and are quite easy to work with.

Cargo culting is a powerful force. Corporate inertia -- even more.

[mindfulmore]

And yet Phoenix hasn't stolen a significant amount of market share from Rails.

> There are a number of web frameworks that perform much better than Rails

If you're measuring hardware loads and busting out your stopwatch to measure response times, then sure.

Bottom line is, there are plenty of good reasons to choose Rails over Phoenix. If you want to label choosing a well-backed framework with an incredibly mature ecosystem "cargo culting" then by all means.

Have fun writing Ecto queries by hand, wiring up document storage on your own, trying to find a standout auth library of choice like devise, finding a library that makes managing database views less of a pain, wiring up end-to-end system testing.

I'll be over here running rails new, wiring up sidekiq to ActiveJob, and building shit with ease.

[pdimitar]

> And yet Phoenix hasn't stolen a significant amount of market share from Rails.

I thought we all learned popularity does not correlate with quality. It correlates pretty closely with corporate inertia and perceived lower risk of developer churn though. Businesses love tech stack for which there are bigger pools of programmers. Says nothing of the quality of the stacks.

> If you're measuring hardware loads and busting out your stopwatch to measure response times, then sure.

Needlessly snarky. Response times matter in a lot of businesses. Count yourself lucky that it hasn't been an important metric in your work.

> Have fun writing Ecto queries by hand

I do have fun writing those. Most times the code in my functions ends up more readable than the equivalent Rails code I wrote years ago. There are some exceptions where you have to dig deeper. Haven't seen a framework -- Rails included -- that lets you handle all complex cases with zero deeper digging needed. At one point you do have to understand SQL and query optimizations, no ways around it.

> wiring up document storage on your own

What for?

> trying to find a standout auth library of choice like devise

It's called Pow and works very well. Additionally, Elixir's maintainers themselves are authoring such a library at the moment.

> finding a library that makes managing database views less of a pain

We can argue if this is a good thing until the Sun explodes. It really depends on the business. I have consulted for businesses where it was very important and true enough, using a library that's well-tuned for classic web apps (like Ecto and ActiveRecord) isn't the best idea there.

> wiring up end-to-end system testing

For 3.5 years with Elixir this is the first time I hear that this is a problem. Any data to back this up?

> I'll be over here running rails new, wiring up sidekiq to ActiveJob, and building shit with ease.

More power to you. Rails is excellent for an MVP or a prototype and this is well-known. It's what comes after is what has burned me out of it. Its maintenance burden is much higher than many others, including PHP's Laravel.

[mindfulmore]

> For 3.5 years with Elixir this is the first time I hear that this is a problem. Any data to back this up?

My point is that it doesn't come with Phoenix out of the box (unless something has changed?), and that difference in philosophy is the core of what I'm getting at. With rails new I'm getting an end-to-end test suite and chrome driver installation for free.

Phoenix also has no plans of implementing something similar to ActiveStorage do they? How about ActiveJob now that elixir developers have rediscovered how great a queueing system is with the adoption of Oban?. Will Phoenix ever make a move to include something like ActionText?

They won't even consider adding basic things for developer productivity like undoing a generator.

https://github.com/phoenixframework/phoenix/issues/2607 https://github.com/phoenixframework/phoenix/issues/1597

The Rails team is much quicker and happier to extract something out of the companies supporting it (Basecamp, GitHub, Shopify, etc) and include it directly in the framework, whereas the Phoenix team seems much less willing to take a "batteries" included approach.

There's a balance of making something easy to use and making something "technically superior". The Rails team seems to care much more deeply about what the framework feels like to use, and the Phoenix team cares more about building something that is "dogmatically perfect" (which you're correlating with quality).

What's easier for someone to learn?

rails g model article title body user:references

mix phx.gen.html Content Article articles title body

I understand what they're going for here, but I'm not sure the tradeoff is worth it. If Phoenix wants to increase their adoption, then I think they need to accept that things like this matter.

[joelbluminator]

> If Phoenix wants to increase their adoption, then I think they need to accept that things like this matter.

It's gonna be tough for them really, even if it's a great framework (I have no idea). Elixir didn't take off like Golang or other languages from the last decade. It seems to have quite the learning curve, so for beginners any of ruby / php or even .net / java will make much more sense. For seniors...idk. Not everyone like functional programming. I do hear praise for the language I can't deny it and what seems like a tiny but vibrant community, but the numbers are just not there. I hope Elixir can maintain it's niche and not outright die just because I know some people rely on it for their pay check but honestly I'm not sure if we'll still have these discussions 5 years from now.

[pdimitar]

> My point is that it doesn't come with Phoenix out of the box (unless something has changed?)

You put a lot of weight on built-in features of frameworks in your reply. This is not an objective truth and even DHH himself admitted as much -- including in his article "Rails is Omakase" which I very much enjoyed (because he says that the Rails team picks what they deem the best ingredients and if you disagree then you are not the target audience).

You find value in "officially vetted" libraries, I find value in being assemble to assemble my chair the way I want it to, with parts I built or bought myself.

Neither practice is superior per se. Let's both admit that.

> They won't even consider adding basic things for developer productivity like undoing a generator.

Honest question: how many tech stacks even allow for that? Does Ruby have bytecode instrumentation on the level of, say, the JVM? (Java's instrumentation has unlocked it some quite impressive code generation and runtime code analysis abilities.)

Generating boilerplate is pretty easy. But how many tools out there can scan your code and tell you "this looks like Devise's boilerplate with exceptions in files A and B on lines 123 to 150 and 201 to 217"?

If Rails can do that I'd be very impressed. It couldn't, as far as I was aware, about 4 years ago.

> There's a balance of making something easy to use and making something "technically superior".

I never said this was important to me. I value Elixir's hassle-free parallelism and concurrency (which is more than what can be said about 99% of the tech out there where those things are always an afterthought). And Elixir is still pretty easy to use. I don't see why both things have to be presented as opponents? Seems like a false dichotomy.

> The Rails team seems to care much more deeply about what the framework feels like to use

You have spoken to the authors and they have told you this, in these exact words?

> ...and the Phoenix team cares more about building something that is "dogmatically perfect" (which you're correlating with quality)

And you have spoken with the Phoenix team. And they told you this. Exactly this?

No. They don't do that. They don't want to steer developers in the direction they might deem the best (they said as much on ElixirForum). They give you freedom to choose. And the community has provided alternative approaches for a number of the classic building blocks of a web app. That's all there is to it and I am not sure how you managed to so grossly misrepesent it. :(

I also never said anything about dogmatically perfect being important (much less correlated to quality!). You are projecting and we are talking past each other which doesn't help the discussion at all. If I cared about purity or similar concepts in the "dogmatically perfect" lane I'd go for Haskell or even Idris. Elixir -- and thus Phoenix -- are very far from "pure", "dogmatically perfect" or any such other academic ideals.

Really not sure where you got that from?

> What's easier for someone to learn?

This is extremely subjective and varies from person to person. Are you claiming that Rails' way is factually superior to learn? To me both are quite straightforward and both require you to have learned some concepts beforehand. And both aren't exactly English with which you command the machine, no?

> If Phoenix wants to increase their adoption, then I think they need to accept that things like this matter.

Ever since I dropped off the mainstream tech train and started working on the sidelines I've noticed something extremely curious which is happening very consistently: the people who work with mainstream tech always assume that the smaller community wants more adoption.

There have been a number of discussions on ElixirForum about this and various important figures of the maintainers' teams have openly said that they aren't aiming to make the language and its stack more popular; they want to make useful tech. One example is the recent Phoenix 1.5.0 release which now comes integrated with LiveView. A lot of people apparently don't want to deal with JS because at least 50% of the new posts on the forum since the announcement have asked exclusively about LiveView.

So again, the maintainers aim to make useful tech, not to trend on Twitter, dev.to, StackOverflow, or anywhere else really.

---

This became rather long. I apologise for that but still wanted to address several misconceptions that seem to have arisen in this discussion.

[cutler]

Can you elaborate how Rails maitenance is "much higher" than with Laravel given that Laravel is PHP's version of Rails?

[pdimitar]

This is what I have been told by a former Rails dev who is now doing Laravel. He said that Rails has much more automatically injected code that behaves in a way you can't anticipate intuitively (and many libraries encourage and extend that behaviour). As a former Rails dev myself I agree with that part.

[imhoguy]

When my small SaaS customer calls and asks for an extra extension at current hard times, then all I need is to open up Rails production console (pry) and live type in an ad-hoc code with auto-completion aid:

    $ rails c
    Loading production environment (Rails 5.2.0)
    [1] pry(main)> s = Subscriber.find_by_email('[e-mail]')
    => #<Subscriber:0x000055dbb64c3bb8
     id: 12913,
     email: "[e-mail]",
     state: "active",
     expires_on: Fri, 15 May 2020 14:10:19 UTC +00:00,
     ...
    [2] pry(main)> s.expires_on += 2.months
    => Wed, 15 Jul 2020 14:10:19 UTC +00:00
    [3] pry(main)> s.save!
    => true

It is done now! Good luck! Bye! - end of call.

Cargo culting? From whom? I don't give a sh*.

[pdimitar]

I can do the same with Elixir's Phoenix, with exactly 3 lines in a production console like in your example.

What you describe is not exclusive to Rails.

[imhoguy]

Yeah, maybe I should rewrite one day, but customers wouldn't care much and I am content wit Ruby.

[pdimitar]

That's fair. Nobody is making you do it. Use what feels right to you.

I simply felt compelled to point out that Rails is not at all as unique as many of its long-time users believe.

[FanaHOVA]

> Is it "slow" enough to matter? Probably not until you get to a medium scale.

Phew, I'm glad GitHub and Shopify's scale is still small.

[dijit]

Pedantry aside, we've reached a point in our industry where we can do a lot with horizontal scalability.

I mean, every programmer who funnels through university understands map reduce, and that helps on multi-core threading up to system job running.

But there is a limit, usually in the persistence and caching layers. What you'll find is that those "large scale deployments" are going to have a -lot- of internal cache systems and I can pretty much guarantee that the services running those caches and persistence will not be written in ruby.

You can make anything* scale, but how many CPU cycles you need to burn to get the functionality you want is a matter for the finance department.

If you're running in a lossy business, you can bet that those CPU cycles will begin to cost more than developer velocity is worth, because servers are an eternal and ongoing cost.

On the flip side if you make more money than the infra+devs cost, then nobody is going to hound you for wasting 2x 3x the cost. Because "it's the cost of doing business" is easier to justify when you're cash positive.

[joelbluminator]

> services running those caches and persistence will not be written in ruby

So what? What's wrong with using software like redis for cache, for a very small (but important) part of your business? I bet java apps use redis as well, and redis isn't written in java. So?

[pdimitar]

Is this an honest question? I honestly can't tell and I am not saying it to show disrespect -- just wondering if you are sarcastic.

Erlang/Elixir have built-in caches that respond in the matter of 30-150 nanoseconds.

Why would you need an external service for that? It's adding complexity -- and likely hosting costs.

Isn't it self-evident to you that adding Redis as a caching layer to your stack is a bandaid to a deeper problem?

[antirez]

Local caches and local node caches are both very useful. (That's why Redis 6 introduces this https://redis.io/topics/client-side-caching), but anyway from what I saw in the past, the major speedup of using Redis in such a context is that you want to use a shared very fast view that is global in nature. A simple to understand, but good example, is the leaderboard problem in multiplayer games that have million of users (Facebook games and such). Even if you have a local cache, and even if you have an additional store where you record the high score of each user, you need a global and very fast to update view of all the sorted scores, to tell the user its rank, users nearby, the rank of their friends. There are a number of problems like that that require to use different data structures and a global view. The problem is that using Redis with the Memcached mindset, will always severely limit the potential benefits.

[pdimitar]

Yes. Redis has very valid use cases.

You're quite right: people using it as a mere cache don't get most of its benefits.

[joelbluminator]

> Why would you need an external service for that? It's adding complexity -- and likely hosting costs.

We're also dependent on mysql, are you gonna implement that in Elixir as well? Redis is a great piece of software, and it's a real SHARED cache, so it could work for sessions or other small state management you sometimes want to remember for example. What you described won't work for that.

[pdimitar]

Both are not equal at all. Redis you can definitely do without. A database you can't skip in most apps.

Sessions work quite fine in Elixir's local cache as well. :)

[ronjouch]

Interesting but not surprising; I'm being regularly pleasantly surprised by the Erlang/Elixir ecosystem :) . Can you precise what you're talking about when you say "Erlang/Elixir have built-in caches" ?

What's the name of the concept and where in the typical stack does it fit? Is this https://blog.appsignal.com/2019/11/12/caching-with-elixir-an... or something else? Care to share a few link to docs/articles? Thanks.

[pdimitar]

Yes, ETS is the usual go-to but there's also `:persistent_term`[0] for very rare (or never) changing caches.

There are libraries that combine Erlang/Elixir's caching mechanisms in an attempt to achieve the best performance for most scenarios[1] as well.

Technically, ETS is not perfect because it copies data from its mutable cache to the process that requests it. But it's still orders of magnitude faster than outsourcing that to Redis.

[0] http://erlang.org/doc/man/persistent_term.html

[1] https://github.com/gyson/ane

[dijit]

My point is that for all the talk of how performance doesn’t matter and that we can scale ruby, the real heavy lifting is not handled by ruby.

It’s not a “problem”, but if you’re going to talk about large companies scaling something you need to understand that they’re likely scaling it in spite of limitations.

Largely, some systems don’t scale too well (latency on network accessible cache, throughput in persistence layers such as databases) so a lot of application layers will lean on those things heavily and they are exclusively written in relatively “faster” languages.

[throwawaylabor]

> I mean, every programmer who funnels through university understands map reduce, and that helps on multi-core threading up to system job running

I wish this were true. There is a high degree of variability between skillsets from different American universities, even in my state of Washington.

Other than that, I agree whole heartedly.

[pdimitar]

> Phew, I'm glad GitHub and Shopify's scale is still small.

Phew, good thing they can afford to burn a lot of cash for hosting.

[tim333]

I guess that's so though it's interesting in the early days Github didn't:

>...a web startup like ours doesn’t need any outside money to succeed. I know this because we haven’t taken a single dime from investors. We bootstrapped the company on a few thousand dollars and became profitable the day we opened to the public and started charging for subscriptions.

Tom Preston-Werner in 2008. I guess the thing is not how much the hosting costs in absolute terms but how much it costs relative to what customers are prepared to pay for the service.

[pdimitar]

Once a business grows to certain size and beyond the shareholders don't want to hear anything about tech rewrites. They are happy the product is working, they are not alarmed by slow response times (which GitHub has plenty of on my gigabit connection that streams 4k@30fps without any lag) unless there's a big customer churn, and hosting costs, even if big-ish, to them are just the cost of doing business.

My point is, yes, you are right -- but there's a lot of conservatism involved once the business gets to a certain size. Nobody cares about improving anything from then on (which usually leads to the now-giant to start steadily losing relevance; GitHub is quite far from that but we all remember Microsoft, right?).

[todotask]

I recall Shopify hired a dev who works on a project, FaastRuby, written in Crystal language for their web app.

[ryansouza]

I guarantee the tradeoffs matter to them

[sosodev]

I’ve seen videos on Twitter of the Shopify CEO saying that Ruby’s performance literally doesn’t matter to them. That it’s easy enough to scale it horizontally and the benefits outweigh the cost.

[joshmn]

Probably helps that Tobias also codes, not to mention contributed to Rails quite a bit.

[Thaxll]

Shopify is actually replacing slow ruby code with Go. And yes they ACK that Ruby is too slow. Also Shopify is a big monolith so it does not help.

[ch4s3]

A monolith doesn't necessarily mean slower, even with Ruby. There are lots of opportunities to run less code on each request, do some work with the db, and to split off measure bottlenecks into services in a faster language. It's often good to build things quickly, find fit, and then carefully measure before you introduce calls over the network.

[Thaxll]

A monolith is a problem which they are also breaking down, when you want to make something faster it's easier to target the service that does it vs the giant app.

Edit: getting downvoted by people that don't work at Shopify.

[byroot]

I work at Shopify. I can confirm that what you are saying is totally false.

[tekstar]

Lol none of these statements are true

[meesterdude]

Stop painting ruby as slow. In benchmarks i've seen it's handily beat out PHP, which still runs much of the web. the ruby 3x3 goal, of getting running super mario at 60FPS, was if i recall correctly, already reached (or close to it) in ruby 2.6. https://developers.redhat.com/blog/2018/03/22/ruby-3x3-perfo...

additionally: > Sinatra + Sequel is already very competitive in web performance with Go > Between Ruby 1.8 and 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released.

https://news.ycombinator.com/item?id=17220967

[jerf]

"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.)

[e12e]

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.

[lizmat]

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.

[b2gills]

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.)

[pdimitar]

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.

[meesterdude]

> 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.

[pdimitar]

> 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.

[wolco]

Ruby is slower than php.

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

[meesterdude]

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.

[cygx]

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.

[VWWHFSfQ]

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

[cygx]

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....

[stevebmark]

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.

[meesterdude]

> 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.

[igouy]

> …much slower than Perl

To do some things but not others?

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

[saagarjha]

People used to think JavaScript was too dynamic to optimize, too. Then people poured time and effort into it and now good JavaScript virtual machines can hold their own against competing implementations for other languages.

[pdimitar]

...While still not being multicore. I feel that those efforts you mention don't go far enough.

And I am pretty sure backwards compatibility will continue dragging JS down for quite a long time still as well.

[igouy]

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

multicore.

[pjmlp]

Surely they are, via workers and worklets.

[goatlover]

It's interesting because Lars Bak was optimizing Smalltalk and Self VMs in the 90s.

[gscho]

We can't forget to consider the cost of productivity gains and developer happiness from using ruby. It can significantly out weigh the cost of some additional hardware.

If it doesn't bring you that, then we have a problem!

[igouy]

> …but all benchmarks show Ruby as slower than compared dynamic languages. The relative speed difference is different per benchmark, but across the board Ruby is slower.

No & No.

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

[barrkel]

In my simple relative comparisons of a couple of sample programs, I've found Ruby to be about as fast as, or faster than, Python, and slower than JS.

[cutler]

Ruby and Python, for a long time, have been almost identical in laguage benchmarks and Python's lack of speed hasn't stopped it being the most adopted language by some metrics. So this whole speed thing is a red herring.