Earlier quoted context omitted.
Except it does not handle neither installation (available via ruby-build), nor gemsets (has a plugin).
Who needs gemsets? Isn't that the point of Bundler?
I'd rather do gemsets than preface commands with "bundle exec"
Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped
21–27 of 27 posts
Re: Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped
#22Earlier quoted context omitted.
Who needs gemsets? Isn't that the point of Bundler?
I'd rather do gemsets than preface commands with "bundle exec"
yes! Though I just discovered the other day you can use the --binstubs option which obviates the need to use bundle exec in the project
Re: Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped
#23Rails needs to do a release solely focused on speed. Dropping 1.8.7 is a good step for a lot of people, but I feel Rails itself has gotten slower since 2.x and I know a lot of people would agree with me. I do a lot of work in CodeIgniter as well as Rails (w/ Ruby 1.9.2 in production), and there's no doubt that my CodeIgniter apps on slower servers with little-to-no deliberate optimization are faster than my Rails app…
> For just one particular example, I have found rendering partials in Rails are such a point of poor performance that I have often found myself avoiding it. A good caching plan obviously helps with these kinds of issues. > There's this red herring (and a pet peeve) that making the framework 'less bloated' by dropping components or making them optional equals performance. In the case of Controllers, inheriting from Ac…
> A good caching plan obviously helps with these kinds of issues.
Caching is suggested far too often and too frequently in the Rails world. The solution to "the default tools for template abstraction are too slow to use" is not "use a difficult-to-get-correct system with concerns that cut across the entire project."
As someone else mentioned, Rails is much slower than other frameworks. It does an order of magnitude less than 5000 req/s. Obviously you can just scale it out and load balance, but that suffers increasing costs from an operations perspective. Aside from per-machine cost, there are peaks where adding more servers requires a big change in your management techniques. Those costs shouldn't be trivially dismissed, and if we can look at reworking our tools to keep most (ideally, all) of the productivity but save on the utilization (read: management overhead), how is that a bad thing?
Re: Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped
#24Earlier quoted context omitted.
I'd rather do gemsets than preface commands with "bundle exec"
yes! Though I just discovered the other day you can use the --binstubs option which obviates the need to use bundle exec in the project
Isn't that exchanging bundle exec command for ./bin/command ? Still not as convenient as just using command
Re: Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped
#25In case you guys missed it, there was a recent HN article on the speed improvements in jruby + jdk 1.7.
I too lament the slowness of Rails - and before you throw the usual arguments at me about perf being relative and 'good enough' blah blah - the ruby/rails community should have seriously addressed this _long_ ago. I've only started with rails recently (this year) and am experimenting with jruby since my patience has worn thing with ruby's speed.
Re: Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped
#26Earlier quoted context omitted.
> For just one particular example, I have found rendering partials in Rails are such a point of poor performance that I have often found myself avoiding it. A good caching plan obviously helps with these kinds of issues. > There's this red herring (and a pet peeve) that making the framework 'less bloated' by dropping components or making them optional equals performance. In the case of Controllers, inheriting from Ac…
I don't really care if my app only manages 5000 requests per second, versus framework x's 6000 or more on the same hardware. Nitpick: Your numbers are a little off. Rails/REE tops out at around ~300 reqs/sec on a current commodity box (16 cores/16G). This is of course application-dependent and optimization can squeeze it some, but it's a different ballpark. When you look outside of ruby-land you can indeed find frame…
When you use Metal endpoints, as i mentioned in my comment, 6000 requests per second is actually very possible. Yes, you need a lot of resources, but I didn't suggest otherwise. And yes, on this hardware other frameworks will manage even more requests.
EDIT: My low budget netbook just gave me 327 req/s with an out of the box Rails config, and running the benchmarking tool on the same machine.
Re: Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped
#27Earlier quoted context omitted.
> For just one particular example, I have found rendering partials in Rails are such a point of poor performance that I have often found myself avoiding it. A good caching plan obviously helps with these kinds of issues. > There's this red herring (and a pet peeve) that making the framework 'less bloated' by dropping components or making them optional equals performance. In the case of Controllers, inheriting from Ac…
> A good caching plan obviously helps with these kinds of issues. Caching is suggested far too often and too frequently in the Rails world. The solution to "the default tools for template abstraction are too slow to use" is not "use a difficult-to-get-correct system with concerns that cut across the entire project." As someone else mentioned, Rails is much slower than other frameworks. It does an order of magnitude l…
> Caching is suggested far too often and too frequently in the Rails world. The solution to "the default tools for template abstraction are too slow to use" is not "use a difficult-to-get-correct system with concerns that cut across the entire project."
I'm not selling caching as a silver bullet (and I'm not saying it's trivial to implement, either). It's just something a lot of people either don't use at all, or just get wrong. And surely, if something can be cached, it should be.
> As someone else mentioned, Rails is much slower than other frameworks. It does an order of magnitude less than 5000 req/s
With Metal endpoints, proper configuration and lot's of resources, this is very possible.