Really surprised how many commenters are talking about using a faster language when the example of slow code in the post is failing to cache the results of an expensive database query.
In my experience, even in "slow" languages, that type of thing is the predominant source of major performance problems, and the supposedly "slow" language would be perfectly adequate if you an stop shooting yourself in the foot (and if you can't, a faster language will not help you).
I'm sure there are extremely high-performance or high-scale points where language choice starts to matter more, but I'm also not surprised if Shopify is correct not to think they're there yet.
Most CPU intensive functionality in the core Ruby lib is implemented in C anyway, to ensure performance.
The vast majority of overhead in the rails app I work on is poorly build data models and poorly written queries. It makes no sense to talk about marginal gains of a few percent or a few ms per request when there are DB queries that take multiple seconds to complete.
In our case, a large part of that is due to the decision that someone made 5 or 6 years ago to store large amounts of data as serialized ruby hashes in the DB, rather than JSON (unsure if postgres supported it at the time), or simply as separate tables.
None of the poor performance of our codebase is down to Ruby itself. Most of it is due to features and data models being implemented with no thought for performance, a lot of which wasn't an issue when first written but as we've grown have become a constant thorn in our side (e.g. retrieving a multiple-MB serialized hash from the DB just to grab 3 values, then doing this 10 times in a request)
It is surprising until you realize that Rails' ActiveRecord consistently wastes 100-200ms on every request just to serialize / deserialize data from/to the database.
So yes, a language that's both faster and has less overhead in its ORM / DataMapper library definitely will help you.
Most languages bring their own ecosystem and associated phosphophy of how you'll use it.
The Ruby phosphophy seems to be lots of magic (in a good way) and in exchange you accept that details get lost behind the scenes and that it's only fast enough, but not truly fast.
Switching to a language that values speed with tools that have a different phosphophy can then make such a bug much more visible, due to the lack of behind the scenes magic.
First thing I tell anyone when they say "this code is slow because of X" is to profile it. Profile, profile, profile! More often than not your assumptions are wrong.
There's a myriad of tools out there for profiling, some language specific, some not. Learn at least one of them well, how to read flamegraphs and how to benchmark properly (warmup code, synthetic vs real traffic, etc). There's definitely a jump between making guesses and hoping you improve performance vs truly understanding what your code is doing.
Not sure when they clarified the licensing around GraalVM, but it's what kept me away from it since it's inception. Looks like the single executable binary is under the Oracle license side of the equation.
Last time I tried to run Truffle on the company test suite it spent an hour processing 1/8th of the suite. Then it was killed by the OOM killer. On a 32 GB machine. To be fair there was only one or two errors during that, so compatibility is at least getting there.
Meanwhile Ruby 2.6.5 chugs along and finishes the whole suite in 8 minutes. Never hitting any unreasonable amounts of memory.
I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language.
Ruby used to be able to say we sacrifice performance for developer productivity.
I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing wildly more performant code.
If you want the luxury of scale problems down the road you do RoR until you lock down that first couple billion dollars of valuation. Just ask Stripe, Github, AirBnB, Gusto, Shopify, Coinbase, Dropbox, Twitter, Door Dash etc. Then you can have the "problem" of picking the wrong language. Massive survivorship bias in the panning of Ruby/RoR IMO...
Also the Ruby/RoR community and culture is better than most other languages/framework. I think culture is a totally valid performance reason to pick a language. Sure there are faster languages and there are jerks everywhere but on average it seems RoR devs are on average nicer and more collaborative people relative to peers.
There is a just a mindset for wanting to write in a language optimized for developer happiness that dovetails with wanting to be happy and work happily with other people. Ya sure those C++ guys can write more performant code but I know who I want to work next to 8 hrs a day. And who I will be more productive working with.
Also I don't think there are plenty of languages that are Ruby/RoR peers. Django doesn't come close. JS ecosystem is a dumpster fire. Some functional and JVM languages maybe but they often come with a corporate culture that kills their benefits. Kotlin would be my bet I guess?
Also if scale is your issue and rails isn't cutting it then you need to go to a proven language with a proven and hirable developer base. That rules out a lot of new and promising languages. Sure they might be just as productive languages but they are resource constrained at the people level. It is really hard to hire Elixir/Phoenix devs etc. You need a talent pool of thousands. Also you need to KNOW the language will be there with a community in 10 years and that it has a history of evolving without screwing over the community. I guess Twitter going to Scala would be an example of this, from my understanding it doesn't solve all their problems.
Total aside: plenty of language need massive tuning to work at scale but it seems like Ruby is unfairly singled out if someone does "exotic" tuning of it but if someone tunes a JVM language or invent their own it is supported.
> there’s plenty of languages out there that developers can be just as productive with
There aren't that plenty really. Golang has nothing like Rails, neither does Node. You can say Django / Laravel but then it's the same performance issues.
Or maybe you're talking good old enterprise software like Spring / Asp. I don't think Ruby/Rails should feel inferior to any of those names for web development.
I don't wanna answer for Shopify because I don't work there, but:
1) Shopify LIKES Ruby. The founders love it. You don't drop this after 15 years to gain 20% more speed.
2) Rewrites are hard. We're talking about millions(?) of lines of code
3) Their teams will have to adapt to a new language
4) Maybe 10 years from now a faster language appears - do they do a rewrite yet again?
5) Optimising things is a part of what we do as developers and even love to do. Is it unheard of to try to optimise your code in java?
6) > there’s plenty of languages out there that developers can be just as efficient in.
That was always the case. Rails devs still believe (for the most part) their framework is productive and fast enough.
I don't see why that would be the case. In fact, the performance improvements during the 2.x era seem to indicate the contrary: that Ruby can be faster.
You only need to be more efficient than the competition, and there’s a shared incentive to push out products faster than you can maintain existing ones. Over the long term it never makes sense to use ruby; only in the short term when it provides a marginal improvement over the competition does it pay off.
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.
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.
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.
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.
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!
> …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.
> Interesting; Shopify doesn't use TruffleRuby, but instead prefers MRI?
Shopify's investing in TruffleRuby as well as MRI - they employ me to work on it. We have it able to run one major app, but still working on making it as fast as we'd like.
Crystal's performance is simply amazing––not just in comparison with ruby, I recently noticed some Python data-ingestion script was on course to take 12 hours to finish. I spent 30 minutes reimplementing it in Crystal, and it took 7 more minutes until it was done!
That was probably a particularly lopsided comparison: lots of CSV and JSON reading, string-mangling, and writing back; it was using Python stdlib functions only, and numpy and similar would have also helped enormously. But I do regularly get factor 100x with all sorts of tasks compared to ruby of python.
That said, Ruby's console (or Pry) is without equivalent in Crystal, and I tend to do most everything on the cli in it. And, as someone already pointed out, the compile cycle is too slow. I've also noticed that even with practice, the intricacies of the type system do slow me down by maybe 30% or so? And the currently existing frameworks are still far away from the ease of whipping up an interface to whatever data you have lying around that Rails offers.
Seriously, if you need high performance out of the box, you should probably just skip Ruby. I love that language to death but most of the time you cannot use of it for a decent scale.
Same for me with Elixir. I love that little thing so much but there are workloads where it objectively shouldn't be used -- for web apps it's definitely one of the best picks out there but that's a different topic.
I've lately been writing several Rust tools and mini apps and have admitted to myself that even if a language stack clicks with you almost perfectly, you should still reach out to other tools when appropriate.
Even us the senior devs forget that, and it pays to get reminded of it every now and then.
...Rewrite in almost anything else and you'll have fast code. :)
It's quite amazing the lengths the companies will go to just to avoid changing their status quo. But for them it makes sense.
---
EDIT: Downvoters, calm down. Ruby on Rails is objectively quite a slow framework and this is proven in many public benchmarks (Techempower included). And Ruby isn't the fastest among the dynamic languages either.
Stuff like this always confuses me. It's like asking how to exercise without sweating. I would think the first sign of performance problems would mean some profiling and some porting of sections to a native language. Instead some companies go down a crazy rabbit hole instead of just making some shared libraries.
benkuhn|5 years ago
In my experience, even in "slow" languages, that type of thing is the predominant source of major performance problems, and the supposedly "slow" language would be perfectly adequate if you an stop shooting yourself in the foot (and if you can't, a faster language will not help you).
I'm sure there are extremely high-performance or high-scale points where language choice starts to matter more, but I'm also not surprised if Shopify is correct not to think they're there yet.
toomanybeersies|5 years ago
The vast majority of overhead in the rails app I work on is poorly build data models and poorly written queries. It makes no sense to talk about marginal gains of a few percent or a few ms per request when there are DB queries that take multiple seconds to complete.
In our case, a large part of that is due to the decision that someone made 5 or 6 years ago to store large amounts of data as serialized ruby hashes in the DB, rather than JSON (unsure if postgres supported it at the time), or simply as separate tables.
None of the poor performance of our codebase is down to Ruby itself. Most of it is due to features and data models being implemented with no thought for performance, a lot of which wasn't an issue when first written but as we've grown have become a constant thorn in our side (e.g. retrieving a multiple-MB serialized hash from the DB just to grab 3 values, then doing this 10 times in a request)
pdimitar|5 years ago
So yes, a language that's both faster and has less overhead in its ORM / DataMapper library definitely will help you.
fxtentacle|5 years ago
The Ruby phosphophy seems to be lots of magic (in a good way) and in exchange you accept that details get lost behind the scenes and that it's only fast enough, but not truly fast.
Switching to a language that values speed with tools that have a different phosphophy can then make such a bug much more visible, due to the lack of behind the scenes magic.
rdoherty|5 years ago
There's a myriad of tools out there for profiling, some language specific, some not. Learn at least one of them well, how to read flamegraphs and how to benchmark properly (warmup code, synthetic vs real traffic, etc). There's definitely a jump between making guesses and hoping you improve performance vs truly understanding what your code is doing.
ykevinator|5 years ago
alberth|5 years ago
From what I understand, it's the fastest VM out there at the moment for Ruby.
And yes, it's from Oracle but they have GPL'd the code [2]
[1] https://www.graalvm.org
[2] https://www.graalvm.org/docs/faq/
Edit: looks like TruffleRuby is built onto of Graal.
https://github.com/oracle/truffleruby
mey|5 years ago
Not sure when they clarified the licensing around GraalVM, but it's what kept me away from it since it's inception. Looks like the single executable binary is under the Oracle license side of the equation.
yxhuvud|5 years ago
Meanwhile Ruby 2.6.5 chugs along and finishes the whole suite in 8 minutes. Never hitting any unreasonable amounts of memory.
nateberkopec|5 years ago
imhoguy|5 years ago
llamataboot|5 years ago
def benchmark_time(repetitions = 100, &block) require 'benchmark' Benchmark.bm{ |b| b.report{ repetitions.times(&block) } } end
praveenperera|5 years ago
Ruby used to be able to say we sacrifice performance for developer productivity.
I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing wildly more performant code.
pcmoney|5 years ago
Also the Ruby/RoR community and culture is better than most other languages/framework. I think culture is a totally valid performance reason to pick a language. Sure there are faster languages and there are jerks everywhere but on average it seems RoR devs are on average nicer and more collaborative people relative to peers.
There is a just a mindset for wanting to write in a language optimized for developer happiness that dovetails with wanting to be happy and work happily with other people. Ya sure those C++ guys can write more performant code but I know who I want to work next to 8 hrs a day. And who I will be more productive working with.
Also I don't think there are plenty of languages that are Ruby/RoR peers. Django doesn't come close. JS ecosystem is a dumpster fire. Some functional and JVM languages maybe but they often come with a corporate culture that kills their benefits. Kotlin would be my bet I guess?
Also if scale is your issue and rails isn't cutting it then you need to go to a proven language with a proven and hirable developer base. That rules out a lot of new and promising languages. Sure they might be just as productive languages but they are resource constrained at the people level. It is really hard to hire Elixir/Phoenix devs etc. You need a talent pool of thousands. Also you need to KNOW the language will be there with a community in 10 years and that it has a history of evolving without screwing over the community. I guess Twitter going to Scala would be an example of this, from my understanding it doesn't solve all their problems.
Total aside: plenty of language need massive tuning to work at scale but it seems like Ruby is unfairly singled out if someone does "exotic" tuning of it but if someone tunes a JVM language or invent their own it is supported.
joelbluminator|5 years ago
There aren't that plenty really. Golang has nothing like Rails, neither does Node. You can say Django / Laravel but then it's the same performance issues. Or maybe you're talking good old enterprise software like Spring / Asp. I don't think Ruby/Rails should feel inferior to any of those names for web development.
joelbluminator|5 years ago
epidemian|5 years ago
I don't see why that would be the case. In fact, the performance improvements during the 2.x era seem to indicate the contrary: that Ruby can be faster.
pdog|5 years ago
monadic2|5 years ago
stevebmark|5 years ago
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|5 years ago
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.
FanaHOVA|5 years ago
Phew, I'm glad GitHub and Shopify's scale is still small.
meesterdude|5 years ago
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
saagarjha|5 years ago
gscho|5 years ago
If it doesn't bring you that, then we have a problem!
igouy|5 years ago
No & No.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
barrkel|5 years ago
jbverschoor|5 years ago
jbverschoor|5 years ago
lidHanteyk|5 years ago
chrisseaton|5 years ago
Shopify's investing in TruffleRuby as well as MRI - they employ me to work on it. We have it able to run one major app, but still working on making it as fast as we'd like.
ch4s3|5 years ago
enitihas|5 years ago
The_rationalist|5 years ago
kipply|5 years ago
Includes some rare, bonus ruby implementations too <3
newintellectual|5 years ago
[deleted]
sealthedeal|5 years ago
[deleted]
IfOnlyYouKnew|5 years ago
That was probably a particularly lopsided comparison: lots of CSV and JSON reading, string-mangling, and writing back; it was using Python stdlib functions only, and numpy and similar would have also helped enormously. But I do regularly get factor 100x with all sorts of tasks compared to ruby of python.
That said, Ruby's console (or Pry) is without equivalent in Crystal, and I tend to do most everything on the cli in it. And, as someone already pointed out, the compile cycle is too slow. I've also noticed that even with practice, the intricacies of the type system do slow me down by maybe 30% or so? And the currently existing frameworks are still far away from the ease of whipping up an interface to whatever data you have lying around that Rails offers.
kenforthewin|5 years ago
https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html
technics256|5 years ago
fxtentacle|5 years ago
It's that easy :)
sky_rw|5 years ago
donretag|5 years ago
unknown|5 years ago
[deleted]
unknown|5 years ago
[deleted]
StreamBright|5 years ago
pdimitar|5 years ago
I've lately been writing several Rust tools and mini apps and have admitted to myself that even if a language stack clicks with you almost perfectly, you should still reach out to other tools when appropriate.
Even us the senior devs forget that, and it pays to get reminded of it every now and then.
timwis|5 years ago
pdimitar|5 years ago
It's quite amazing the lengths the companies will go to just to avoid changing their status quo. But for them it makes sense.
---
EDIT: Downvoters, calm down. Ruby on Rails is objectively quite a slow framework and this is proven in many public benchmarks (Techempower included). And Ruby isn't the fastest among the dynamic languages either.
Less cargo culting and more facts, please.
BubRoss|5 years ago