3 ms·
I've never been truly bitten by ruby performance, or ever found it so I've never by bitten by Ruby's runtime performance. It's "fast enough" and for common use
by JohnBooty 9y ago
I've never been truly bitten by ruby performance, or ever found it so
I've never by bitten by Ruby's runtime performance. It's "fast enough" and for common use cases that need more performance, there's usually a C extension (nokogiri, etc) on tap.
Mostly, performance is an issue with large apps and their rspec run times and app startup times. (And of course, those are not purely -- or necessarily even primarily -- Ruby's fault, but still)
There are numerous, complex large scale applications out there, running on rails.
Rails is definitely pretty hackable to fit one's own needs, but that's where the "convention over explicit configuration" stuff becomes a hindrance rather than a help.
Don't get me wrong, it's not awful, it's pretty good.
Most businesses are in fact fine starting on rails,
and staying on rails. When i say most, I mean 95%.
I agree! Like I said in my initial post I generally like where Ruby and Rails are at.
Our big old Rails monolith (started on Rails 2, currently on 4.2, and hopefully on 5.x in a few months) has carried us to about $500mil projected revenue this year. Could other stacks have done the job better? Quite possibly, but they quite possibly might have been much worse as well. =)
- meesterdude 9y ago> Mostly, performance is an issue with large apps and their rspec run times I hear you! I hate long test suit runtimes, and they are easily grown. I made a gem to address this, by running your test suite across a cluster of cloud VM's and reduce test times from 30 minutes to 30 seconds. http://github.com/meesterdude/cloudspeq http://github.com/meesterdude/cloudspeq > but that's where the "convention over explicit configuration" stuff becomes a hindrance rather than a help I feel It just gets you going - you have a foundation you can run with - and one that other devs will know "out of the box", which means onboard is easier/faster. But it's never meant it's not configurable. You'll still need to cache, to adjust web servers and background jobs and all of course. But rails makes it possible, easy (and fun!) for one person to do all that. > Our big old Rails monolith (started on Rails 2, currently on 4.2, and hopefully on 5.x in a few months) has carried us to about $500mil projected revenue this year. Dayum! Well done! Do you know how many requests a second you serve and the avg. response time? > Could other stacks have done the job better? I think so long as you haven't been severely bitten by scaling or performance issues; the product itself is what matters so long as the technology can deliver on it. Clearly you're doing pretty well regardless! Proof is in the pudding.