This is great an all, but it's too bad they didn't just decide to do away with gems and everyone switch to rip.
But since they didn't, I'm glad they have decided to effectively move hosting to S3 (which is essentially what this change is about). There seems to be a tangible difference between the old hosting speed and s3's bandwidth (especially for people hosting their apps on EC2).
I love the ideas behind rip, but I think even Chris would say it's not quite ready to replace gems yet. For one thing, it depends on specific bash-isms.
One of the nice things about Rip is that it supports RubyGems so, to an extent, you can have your cake and eat it too. The collective investment Ruby developers have in Rubygems is pretty large, so if it gets replaced by something else, it's not going to happen overnight.
Definitely. I see Rip as a superset, of sorts, of Gems. That is, Rip is great for managing both Gems and in-development code, and doing so in swappable environments. Gems, on the other hand, tend to represent mostly mature code.
But since they didn't, I'm glad they have decided to effectively move hosting to S3 (which is essentially what this change is about). There seems to be a tangible difference between the old hosting speed and s3's bandwidth (especially for people hosting their apps on EC2).