It's just a pity that whilst everyone wants to meet us, no one knows what to do with us. Well that's not entirely true. If you've a passion for Rails you can currently make a killing in web development, and there are a number of firms now doing very nicely out of that kind of work. Very nicely indeed. It's also growing in popularity amongst system administrators and QA testers, areas that have always been open to light-weight languages with little learning-curve. But suggest that Ruby is a good fit for other problems and you run into this persistent brickwall of disbelief: it's too slow; it lacks major corporate backing; no one uses it for serious development; it's Rails isn't it?
- Well firstly it's not particularly slow. Ruby running on my Core 2 Hackintosh is orders of magnitude faster and more responsive than VB on a 100MHz Pentium, and as I've mentioned before I've used the latter as a target for significant performance-critical applications. My confidence that Ruby could do the same tasks is very high and several of the projects I'm involved with have similar performance requirements. Sure it's slow at number crunching, but so are most languages compared to raw assembler.
- The lack of corporate backing is common to most open-source languages, but in this case it's no longer true. JRuby puts a Ruby interpreter on the JVM and is backed by Sun Microsystems whilst Microsoft announced IronRuby this week as part of their Silverlight rich-media web client vision. The two heavyweights of Enterprise software are driving hard to include dynamic features in future versions of their respective platforms and Ruby has played an important part in inspiring this change in outlook.
- I love the notion that just because no one else appears to be using a new tool, that's a good reason to ignore it. One of the defining differences between excellence and mediocrity is the willingness to use new tools and techniques before they enter the mainstream, so if your primary argument for not using Ruby is that it's not yet mainstream you've just defined your project as mediocre. By the time you're ready for it, your competitors will be onto even newer tools. Paul Graham has written some excellent essays on this subject, go read them and get an education.
- Rails. It's all anyone ever wants to talk about. You'd think it was the key to world peace from some of the sycophantic outpourings you read on the blogosphere. It's good, but it's not that good! Of course a lot of this chatter is a recognition that the existing web development paradigms are borked and that Rails offers something fresh, but it also shows a more general truth: dynamic tools make for productive developers, productive developers generally produce more elegant and efficient applications, elegant and efficient applications make end-users happy. Ruby is a very dynamic tool and that means it's great for productivity and developer and end-user happiness - everyone wins! But this boost in productivity isn't limited to just web applications, you can use it anywhere.
So now we've dismissed the usual complaints, let's look at the core assumption that people are currently making:
Ruby = Rails = Web Development
If I have to do web development then Rails is definitely a step up from any of the non-Ruby frameworks I've used. However as I demonstrated at RailsConf Europe last year, rolling your own web framework in Ruby is a trivial task, and that's the point I'm trying to get across: a good dynamic language can make many tasks trivial that in static languages seem daunting.
Why does this matter? Because solving a problem well generally first requires solving the problem badly, and that means planning for multiple iterations if you want to hide the awful truth of how bad your first solution is from competitors and end-users alike. But multiple iterations with a static language are a huge risk thanks to their long development cycles and the substantially larger codebases they generate. Sure the corporate FUD-machine wants you to believe that static languages make for better products by identifying bugs earlier in the code design process, and they pump out all those lovely glossy brochures describing Enterprise debugging tools and benchmarks showing ten-fold performance on carefully chosen critical-path code, but FUD is all it is. With dynamic languages we're not in Kansas anymore, and the underlying assumptions of the static typing world no longer apply...
So next time someone tells you that they use Java or C++ for the
heavy-lifting server-sideask yourself just what that heavy-lifting involves and whether the majority of it wouldn't be better handled with a dynamic language like Ruby. Even if there are numerically intensive sections that are best handled by some tightly-optimised code these can be implemented as low-level extension libraries, but for the rest you can bet that code-complexity and development time will be greatly reduced by making the switch and that no one will notice the performance difference.