Persistent PHP processes in Erlang/OTP. “It’s so easy, in fact, that I now use it to debug WordPress functions from within Erlang.”
Since 7 reasons I switched back to PHP there seems to be a trend of Rails-bashing articles, epitomized by this one which is a fine example of the form until it advocates ASP.NET. Through it all, I still haven’t heard of a startup or web service that failed or succeeded due solely to its web framework or language. These articles are like the celebrity gossip stories of Web 2.0, complete with ad hominem attacks, and just as useless. Hacker News tends to be a fairly high signal source of discussions actually relevant to startups.
There have been two interesting responses to the podcast I did with Om and Niall the other week. The first was Scott Johnson who responded in a podcast. As I expected, most people are taken aback by my statement to “let the engineers pick” what language and enviroment you use for your product. I think there is one important assumption that wasn’t articulated in that statement: you have brilliant engineers and you trust them. As a psuedo-engineer, I find it insulting when people suggest engineers are unable to factor anything other than their selfish language preferences, things like loaded costs, hardware costs, platforms, long-term viability, hiring, etc are simple variables that can be considered by any intelligent person. If anybody in Automattic came to me that was writing a tool in Python, C, Perl (it’s happened) or whatever, I might ask a question or two but at the end of the day I know they’re able to weigh the costs and benefits just like I would. If you’ve hired an engineer that isn’t able to make these decisions as well or better than you, then you’ve already lost the battle and over time more and more of your time will be spent plugging holes in a descent to mediocrity.
The second response was on the Pronet blog which in an amazing feat of blogging acrobatics managed to mention and link every single person tangentially associated with the podcast except me, even though I’m quoted in every heading. The Google Pages example is brought up again to illustrate that all the hardware in the world sometimes solve a scalability problem, but I still think that’s faulty because none of us had any idea why Pages was slow when it launched, it could have been a faulty router for all we know. Pronet responds to “Go with what your happiest working with” with a set of points to consider for a language, but again with the right people none of that matters. Happiness, in all things not just the language, should be the number goal and metric for everything in an early-stage startup. Happy engineers work smarter, longer, more efficient, attract better candidates, and have a better quality of life. (A corollary is that if you’re already set on a language path, don’t hire anyone who isn’t thrilled with working in that language.) For an example of how this can work in a really extreme case, I suggest everyone read the story of Viaweb and Lisp. (Another talk.)In my mind Lisp is a ridiculous language to build a web application in, but to them and their engineers it was heaven and they had better products earlier than their competition as a result of their unusual choice.
(As an aside, I wonder how many people said the same thing about Ruby for web apps before David Heinemeier Hansson, Rails, and 37signals, or even about PHP before Yahoo and Wikipedia? An example (and a little bit of promotion) is better than a thousand whitepapers.)