We've already gone down the Ruby road once. I think a lot of the
people involved with that would say it was a bad call, especially ops.
Ruby at scale can certainly be a lulz engine, especially for those on the sidelines. This project doesn't seem to place any software demands on the production cluster, or even necessarily require anything from ops though.
I had mentioned in IRC that I don't have any major ops objections as long as whatever gems are required are installable via apt in some way, rather than using gems.
I assume the road you refer to was the mobile gateway; I consider that to have been a train wreck primarily from a project standpoint as opposed to a technical one. When I stumbled upon it, there wasn't an employee with the combination of access and knowledge required to commit code changes to its read-only-to-us repo, and to deploy those changes. We were essentially passing bits of duct tape back and forth by transatlantic carrier pigeon. For a slew of reasons, it makes much more sense to do what we're doing now with MobileFrontend, but we've yet to reach the point where it does anything the ruby gateway couldn't have done with a bit of iteration. In its last incarnation, it was typically faster than the current MobileFrontend for a request not served by the frontend caching layer. The point being, I don't think language was the main issue there.
Ubuntu support for ruby was problematic. The need for a bunch of gems was also problematic.
This particular use of ruby is less problematic since we won't need to run a web service using ruby. My main objection is really that we're fracturing our codebase into a bunch of languages. It's hard enough getting people to write tests, and making people write their code in PHP, some of their tests in PHP, and some of the tests in Ruby is likely prone to failure. I don't think python is a reasonable choice here either, honestly.
Chris makes a compelling argument that his preferred route is closer to being off the shelf and widely supported by industry and community. I have no comment on what QA engineers prefer to hack on, but I think the ease of hiring new ones who are good at what they do and excited about the tools they get to use should be part of the decision.
I'd be more interested in what's more likely to grow and keep our community, and give us proper tests, than who's easier to hire. We're based on the concept of scaling people by building communities.
- Ryan