4 ms·

> I don't see it ever getting too much faster ruby 3 will be 3 times faster http://engineering.appfolio.com/appfolio-engineering/2015/11/18/ruby-3x3 http://eng

> I don't see it ever getting too much faster ruby 3 will be 3 times faster http://engineering.appfolio.com/appfolio-engineering/2015/11/18/ruby-3x3 http://engineering.appfolio.com/appfolio-engineering/2015/11... > Rails is... kind of wacky, still, in what manner? it is one of the most well well crafted and thoughtful pieces of software i've ever used. It has never been "wacky" for me, behaved unexpectedly, or require convoluted effort.

JohnBooty 9y ago
> ruby 3 will be 3 times faster The goal is "three times faster than Ruby 2.0" though, which means we're already part of the way there. I'm not entirely sure the 3x speedup is possible; it was just kind of a vague goal from Matz meant to be a rallying cry. You can get a taste of the future today with bootsnap (not to be confused with Bootstrap) which enables roughly 2x faster app startup thanks to compiled bytecode caching. The other major speedup on the horizon is probably the effort to make all objects invariant by default. You can get a taste of that today with frozen string literals, though the impact is not huge, which is why the "3x faster" thing seems like a stretch to me. (It's possible that more impactful optimizations are possible if/when this invariance-by-default becomes a core language feature) I'm no low-level Ruby VM hacker though so my opinions are not especially well-informed. I hope I'm wrong and we soar right past 3x and get a 10x speedup eventually. =) > in what manner? it is one of the most well well crafted and thoughtful pieces of software i've ever used. I like Rails! The main wacky thing to me is the way in which it modifies so many core Ruby classes. I understand the the ability to so is a part of the core Ruby and/or Rails magic, but I actually don't necessarily like my framework to blend so seamlessly with my language. 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.
- meesterdude 9y ago
  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

> ruby 3 will be 3 times faster The goal is "three times faster than Ruby 2.0" though, which means we're already part of the way there. I'm not entirely sure the 3x speedup is possible; it was just kind of a vague goal from Matz meant to be a rallying cry. You can get a taste of the future today with bootsnap (not to be confused with Bootstrap) which enables roughly 2x faster app startup thanks to compiled bytecode caching. The other major speedup on the horizon is probably the effort to make all objects invariant by default. You can get a taste of that today with frozen string literals, though the impact is not huge, which is why the "3x faster" thing seems like a stretch to me. (It's possible that more impactful optimizations are possible if/when this invariance-by-default becomes a core language feature) I'm no low-level Ruby VM hacker though so my opinions are not especially well-informed. I hope I'm wrong and we soar right past 3x and get a 10x speedup eventually. =) > in what manner? it is one of the most well well crafted and thoughtful pieces of software i've ever used. I like Rails! The main wacky thing to me is the way in which it modifies so many core Ruby classes. I understand the the ability to so is a part of the core Ruby and/or Rails magic, but I actually don't necessarily like my framework to blend so seamlessly with my language. 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.

meesterdude 9y ago
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.