44 ms·

Yeah, we'll have to see about ruby 3. I know they're at least making deliberate effort - and are pondering some static typing. I've never been truly bitten by r

Yeah, we'll have to see about ruby 3. I know they're at least making deliberate effort - and are pondering some static typing. I've never been truly bitten by ruby performance, or ever found it so. But Crystal seems like an interesting language if/when that becomes a larger issue. > The main wacky thing to me is the way in which it modifies so many core Ruby classes. Ok, fair enough. I actually wish they were part of ruby, more often than not. But I do appreciate them, and use them often. I don't have a puritan objection to their presence, though. I view it as making the world a little nicer. > Most non-trivial Rails apps need to veer off the rails at some point due to user/business needs, and that's when dealing with Rails (and the tendrils it has wrapped around so much of Ruby) gets tough. I must disagree with you about jumping off rails. There are numerous, complex large scale applications out there, running on rails. Github, hulu, shopify, basecamp, to name a few. I've worked on complex rails applications and they've performed really well, overall. On top of that, they were approachable and maintainable, even for junior devs. Most businesses are in fact fine starting on rails, and staying on rails. When i say most, I mean 95%. Short of becoming a twitter or reaching similar huge scale, rails will carry you very, very, very far.

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.

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.