Jared Friedman, founder of Scribd, recently wrote a blog post titled "Why I wouldn’t use Rails for a new company". In it, he makes three points as to why Rails is 'past it' and why new start-ups should look to some other framework or language for their products:
- Rails isn't the hottest thing any more.
- Other frameworks have caught up with Rails. Rails is static.
- Ruby is slow
He then draws on these points to make a startling conclusion:
"If you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now."
The myth of 'hotness'
Points 1 and 2 are unarguably correct. Rails isn't hot any more and is not evolving at the pace it used to be. But this isn't a bad thing. It's a sign that Rails has matured, it's now an adult framework and not the spotty teenager who grows taller by an inch every month. Its growing pains are behind it, the rough spots have been ironed out and all Rails needs to do now is position itself in a changing technological environment. With Rails 5 it seems this process has already begun. That's partly what maturity is about: the ability to assess a changing scenery and see your place within it. Not playing catch up with the Joneses. Let's leave that to all the other frameworks which have been 'inspired' by Rails over the years. This is by itself a testament to the success and influence of the framework. As the saying goes:
"Imitation is the sincerest form of flattery."
The myth of 'speed'
Ruby is slow. I know it, you know it, the world knows it. The question is : 'Does it matter?'
Let me tell you a secret. I was around in 1996, in my first job as a C++ engineer (yes, I'm that old). It was when Java first came out. I was one of the many C++ developers who had a good laugh about it. 'It will never catch on', we said, 'it's just sooo slow!'.
And it was. This was Java release 1, way before the JIT optimisations and the HotSpot. It was an order of magnitude slower than anything we built in C++. Even today, after all the Java performance improvements, C++ natively-optimized code is still faster than its Java counterpart. Did that stop Java from becoming, arguably, the most popular language on the planet? Nope. Did that stop Java from replacing C++ as the language of choice for enterprise back-end and desktop applications? Nope.
So why didn't Java's lack of speed stop it from spreading like a virus? The answer is simply: 'context'. In the context where Java apps were being used, Java's slow performance didn't make a difference. Think about it, the average HTTP request takes about 0.5 secs. Many database transaction times are measured in seconds (PS: you should optimise these, BTW). Why would I put in the time and effort to re-write my 250ms Java applet to a more performant 50ms C++ DLL, when it will make no difference at all to the end result? Oh, and also did I mention that my Java code would crash half as often as my C++ equivalent? (no explicit memory management mistakes, see)
So what about when you needed that extra performance boost or this explicit memory management in your app? Well, then you just didn't use Java, you used C++. As simple as that. Ease-of-use, productivity and safety are usually valued over app performance. As someone famous (I forget who) once said: "Developer cycles cost more than processor cycles".
Now replace 'Java' with 'Ruby' in the above paragraphs and 'C++' with <your-choice-of-fast-language> and you'll see that the principle still stands. Ruby is a wonderfully expressive, flexible and highly-productive language (much more so than Java ever was). That's why you should be using it in your start-up. Ruby gets out of your way and lets you be creative. Rails is a tried-and-tested framework that's proved itself in the field. Yes it has its bad points- too much magic and some un-OO practices- but as a start-up you want to put your product out there as quickly and efficiently as possible and there are few better tools than Rails to help you achieve that.
Epilogue
If your main worry is about what engineers are likely to be using in three years time, instead of the best way to make your product available to your customers, then chances are you'll be joining the 90% of start-ups that fail within their first year. If you don't want to go down that route then use Rails to maximise your chances.