Update (19-Nov-2012 18:30pm) - The following post is a subjective rant. It isn’t meant to convince you that you should or shouldn’t use Ruby, or any other technology. The context of the points below is that of Web development, rather than computer programming in general. My attempt in this post is to surface some points made over the years by developers I met from other programming communities in respect to Ruby as a Web development technology, and illustrate that people should try and keep an open mind when it comes to unfamiliar grounds. Enjoy.

I recently gave a 15min talk about things I love about Ruby as a programming language and an eco-system.

Naturally, that meant upsetting a few tender-hearted PHP, .NET and Java developers, who, instead of becoming curious, felt I was being condescending and critical of their much-loved technology.

Since this isn’t about religion but about opening up to new things, I thought it might be a good idea to come up with all the reasons others might give for not using Ruby for your Web development needs.

1. Ruby isn’t as mature as Java or PHP

It’s true. Java and PHP have been used for Web development longer than Ruby. Well, you know what? My grandmother has also been around longer than Ruby, but I don’t go about using her to build Web apps every other day. In the Web era, where technology reinvents itself every couple of years, being old and mature isn’t necessarily an advantage. In many respects the Ruby community has learned from the mistakes of the past and was able to adapt and adopt better, modern solutions faster than the fragmented PHP community.

If your only criteria for assessing a technology is age, you’re in the wrong line of work.

2. Ruby isn’t as performant as .NET or Java

You’re right. Ruby is also slower than Erlang, Lua and C++ but you don’t go about writing Erlang or C++ code every day, do you? Web development isn’t all about code performance. Your new shiny Web app doesn’t have a million users a day for day one. You need to code it, test it, release it, rinse and repeat, and you need to do that quickly. So, initially, the important factor is developer performance rather than code performance. Hiding behind the “performance” argument is not only cowardly, it’s plain wrong, because instead of focusing on releasing your app as quickly as possible, you’re focusing on the unknown promise that one day you might have to worry about scale. Well, Ruby apps scale as well as .NET or Java apps. We all end up there, clench our teeth and handle it like adults. We might do it differently, but we do it all the same and usually begin at the DB level rather than the application level. Curious, right?

3. Ruby doesn’t work well on Windows

Of course it doesn’t. Windows is great for many things, but Open-Source Web development isn’t one of them. When you think about it, Ruby, like many other great technologies was first developed for *NIX and only later ported to Windows. It’s a bit like buying a scooter and trying to use it for off-road bike racing. It wasn’t designed for that.

Instead of banging your head against the wall, complaining that you’re used to Windows and all that jazz, just take a deep breath, install Linux and get on with life. Technology is about learning new things, not staying in your comfort zone forever.

4. Ruby isn’t as popular or commonly used as PHP

You’re absolutely right! Just do me a favour and mind your head before going back into your DeLorean as you go back to the future (erm, I meant present). Technology isn’t a popularity contest, otherwise we would all be developing Websites in Javascript (currently the most popular language on Github). Technology is means to an end. Popularity is a warped factor that tries to measure adoption rate and community activity to help people gauge production-readiness, code stability and support level. Here’s a novel idea for you then - Try checking production-readiness, code stability and support level on a per-technology basis, rather than throwing popularity figures into the thinning air.

5. The Ruby community is condescending and snobbish

Well, yeah, and the Java community is stubborn, the .NET community is closed-minded, the Perl community is quirky and the C++ community is a bunch of middle-aged, pipe-smoking elves.

I’ve met all sorts of developers from all sorts of backgrounds. I’m not saying there aren’t any Ruby snobs, but from my experience they’re not the majority (and I have met some very snobbish Java and .NET developers as well). Mostly, I think that people mistake pragmatism for condescension. Since Ruby is relatively young, and tends towards early adoption of many technologies, Rubyists have a relatively easy life when it comes to trivial stuff like tests, deployment, integrations with 3rd parties and so on. So when a Rubyist is “boasting” that things are easier in the Ruby world, they’re not looking down at you, but merely suggesting there’s a simpler, more pragmatic way of doing things.

6. Ruby is too opinionated and takes away my freedom to do things my way

This is one of those statements that’s not only wrong, but just plain dumb. Let me ask you this - How many ways are there to write an HTTP routing component for a Web app or an image manipulation library?

Convention over configuration, best practices and clear codings standards don’t take freedom away from developers. Instead they help them focus on the important things like business logic, rather than the menial, repetitive things like static asset minification and concatenation.

Ruby’s opinionated and convention-driven approach helps developers not only to become more productive, but also to adhere to community-driven standards that aim to reduce boilerplate code to a minimum. Many people can chant the “KISS & DRY” paradigms, yet not as many adhere to it.

The funny thing is that Ruby is one of the only languages I know that lets you change absolutely anything, anytime, anywhere. Yet, people seem to be happy to adhere to its standards and conventions because it makes them more productive, without compromising their ability to innovate and be creative. Curious, right?

7. Ruby isn’t as reliable as Java and .NET

Windows isn’t as secure as NetBSD. Oh No!!! I should dump my shiny new Windows for a NetBSD installation. If you’re only way to measure reliability is type-safeness, then you’re looking at things from the wrong perspective.

While static languages offer a performance boost in relation to dynamic languages, due to their compiled nature, and a strict mechanism to ensure private and public APIs are adhered to, lets be blunt - How many bugs, in your history as a programmer, were the direct result of a wrongly-typed variable?

Ensuring a method can only accept variables of predetermined types doesn’t ensure sound and bug-free code. If anything, it adds noise to an otherwise clean code in case you do have to cast variables or read compiler complaints about wrong types.

Ruby’s way of solving this conundrum is to promote testing as a culture. In other words, your code is as reliable as your tests, not as reliable as your method signatures.

8. Ruby lacks entreprise-level support

Sure, if you’re an enterprising ant working for a bunch of bureaucrats who consider COBOL to be cutting edge stuff. Ever heard of Engine Yard? No? But they offer fantastic enterprise-level Ruby support.

The whole chant about enterprises and support comes from the olden days where companies who made technology felt the only way to ensure a steady income from their products, was to tie end-users to their platform. There are hoards of enterprise official who come up with amazing reasons for you, the developer, to stick to their expensive, reliable, solid, state-of-the-art, technology. Does it mean you have to? Are you so incapable that the mere threat of being left alone “unsupported” deters you from choosing a piece of tech. that might actually be more suitable for your needs?

Let me ask you this - How long do you think it will take a company like Microsoft, to find, fix, admit, and release a fix to a security hole in IIS? Now think again, taking into account all the bad PR this could generate. Do you honestly think that a PR-conscious, money-driven monopoly cares about your Web app’s security?

In an era where technological innovation goes hand-in-hand (and is often driven by) open source code, choosing a closed-source, monopolised, technology for the sake of support is choosing to stay one step behind everyone else. Just take a look at companies like Basho, RedHat, Canonical, 10gen, Cloudera and Engine Yard, who all offer open-source technologies as well as enterprise-level paid support.

9. Ruby doesn’t scale well

That’s an old one, dating mostly to the days of Twitter’s childhood, when Twitter grew so fast, they had to fix deep-level code inside ActiveRecord to add support for multiple MySQL DBs inside their Rails application. Sadly people confuse Ruby and Rails and in the Twitter example forget to mention that Twitter admitted they owe part of their rapid, successful growth to Rails’ ease of use and rapid development principles.

There comes a time in any successful application’s life-cycle when scale becomes and issue. Facebook solved it by compiling PHP to C++, Twitter opted for Scala, YouTube still run on Python, Apache and MySQL. Since no two Web apps are exactly alike, one should learn from battle-hardened experience of successful Web apps, rather than proclaim one technology is superiorly scalable than another.

10. It’s a lot harder to find experienced Ruby developers in today’s market

That’s actually true, depending on where you are in the world. In Israel, for example, where .NET and PHP are more widely used, finding good Ruby developers is harder. But, you know what? It’s also harder to find experienced Javascript developers. In my mind, that’s a clear indicator that a certain segment of the market is in demand, and is on the rise, which is definitely a good thing.

To top it all up, I can safely say, that finding good PHP developers is also hard, especially in a rapidly growing and vibrant high-tech market. I would even argue that finding good PHP developers is harder than finding good Ruby developers because being a good PHP developer requires both more experience and more discipline, in relation to Ruby, due to PHP’s fragmented, user-generated documentation and inconsistent API.

So, instead of shying away from a good thing because it’s hard, why not train Ruby developers yourself? I mean, if you agree it’s the right technology to use, why not invest in it?