Ruby might be faster than you think
johnhawthorn.com
Ruby might be faster than you think
1–10 of 39 posts
Re: Ruby might be faster than you think
#2>The Ruby implementation has a subtle mistake which causes signficantly more work than it needs to.
To be fair, I do not think that is a "mistake" as such. I have written Ruby professionally for 6 years or so and have committed to several Ruby open source projects and haven't seen an innocus `nil` sitting at the end of a loop, to prevent array allocation.
The argument would be fair, if it wasn't idiomatic Ruby.
More like - knowing internals of a language will allow one to gain more performance out of it. That has been true for almost every programming language, but general speaking the goal of a VM based language is to not require that _specialized_ knowledge.
Re: Ruby might be faster than you think
#3[flagged]
Re: Ruby might be faster than you think
#4>The Ruby implementation has a subtle mistake which causes signficantly more work than it needs to. To be fair, I do not think that is a "mistake" as such. I have written Ruby professionally for 6 years or so and have committed to several Ruby open source projects and haven't seen an innocus `nil` sitting at the end of a loop, to prevent array allocation. The argument would be fair, if it wasn't idiomatic Ruby. More…
+1. I love golang, because for the most part, there is only 1 way to do something. With ruby, there are a billion ways to do the same thing, with some being slower than others.
Re: Ruby might be faster than you think
#5YJIT and Ruby 3.3 have really impressed me as well. Their VM engineers are clearly doing something right.
Related to Ruby perf, I still hear folks worried about rails “not being able to scale”. Let me say something controversial (and clearly wrong): Rails is the only framework that has proven it _can_ scale. GitHub, Shopify, AirBnb, Stripe all use rails and have scaled successfully. Very few other frameworks have that track record.
There’s plenty of reasons to not use rails, but scaling issues doesn’t feel like a strong one to me.
Re: Ruby might be faster than you think
#6[deleted]
Re: Ruby might be faster than you think
#7Honestly it’s been my experience with Ruby that it’s Rails that can potentially be slow. Ruby is quite fast and even has a JIT option. Rails is by design opinionated, and for some cases I’ve found that I’ve had to work extra hard to ensure performance. That means refactoring code in slightly non traditional ways and having a deeper understanding of how Rails works under the hood (esp in the ORM). So if you think you can just use Ruby+Rails out of the box in its simplest form without experience and depth of understanding: yes it might be slow. But like with all things, you can go quite far with care and experience.
Re: Ruby might be faster than you think
#8>The Ruby implementation has a subtle mistake which causes signficantly more work than it needs to. To be fair, I do not think that is a "mistake" as such. I have written Ruby professionally for 6 years or so and have committed to several Ruby open source projects and haven't seen an innocus `nil` sitting at the end of a loop, to prevent array allocation. The argument would be fair, if it wasn't idiomatic Ruby. More…
> if it wasn't idiomatic Ruby
It's idiomatic Ruby in a very particular case that likely was explicitly chosen to demonstrate such a dramatic effect.
You're _usually_ not returning implicit arrays from loops in production code. Parallel assignments, when they're used, are almost always in the first line of an initialize method, not the returned line of an enumerable block.
Re: Ruby might be faster than you think
#9>The Ruby implementation has a subtle mistake which causes signficantly more work than it needs to. To be fair, I do not think that is a "mistake" as such. I have written Ruby professionally for 6 years or so and have committed to several Ruby open source projects and haven't seen an innocus `nil` sitting at the end of a loop, to prevent array allocation. The argument would be fair, if it wasn't idiomatic Ruby. More…
I don’t think there’s any language, interpreted or otherwise, with the goal that knowing its internals won’t help you gain more performance. I mean, that would be nearly impossible.
Ruby code, perhaps more than most code, is written for readability and “beauty”. It’s a part of Ruby culture that I greatly appreciate. But if you care about performance, you will act differently, regardless of language. And the whole point of this code is to show that if you care about performance above all else, there’s of plenty of room to maneuver in interpreted Ruby.
Re: Ruby might be faster than you think
#10>The Ruby implementation has a subtle mistake which causes signficantly more work than it needs to. To be fair, I do not think that is a "mistake" as such. I have written Ruby professionally for 6 years or so and have committed to several Ruby open source projects and haven't seen an innocus `nil` sitting at the end of a loop, to prevent array allocation. The argument would be fair, if it wasn't idiomatic Ruby. More…
+1. I love golang, because for the most part, there is only 1 way to do something. With ruby, there are a billion ways to do the same thing, with some being slower than others.
I've just started learning Go as a very long time Rubyist. I really enjoy both languages for very different reasons. In Ruby, I can write code that really makes me happy to read. Enumerable is just wonderful. You can go a long way in Ruby without writing a single if statement. It's great. If I'm working on a solo-project, it's the language I'd choose every time. But working with inexperienced or people who "know" Ruby, but never adopted "the Ruby way" is a nightmare. Ruby code, written poorly, can be extremely brutal to follow. When the great deal of freedom Ruby offers isn't handled responsibly, a hot mess can ensue.
Go is the opposite. It's great, as you say, because it's dirt simple. It's a brutalist get-the-job-done kind of language, and I think if I were to start a company working with other engineers, I'd absolutely choose Go for that reason. It's easy to read. It's easy to reason about. And there's very little implicitness in it.