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