- Author picks Lift/Scala not on the best future interests of the company (ease of hiring, scalability, agility, maturity) but on fit for his world view about type safety and it would be fun for him.
- Author commits startup to stateful servers / scaling issues from day 1 of the rewrite.
It's funny because when Paul Graham writes articles about how the web lets us use whatever language we want (see http://www.paulgraham.com/avg.html), everyone celebrates the possibilities of writing their web site in their favorite lisp dialect. Yet here we have this evil engineer who picks a technology he likes, successfully improves a product and meets business requirements with it, and is ridiculed for picking a relatively obscure technology!
Check out tiobe. I wouldn't be surprised if in a year Scala passes the combination of all lisp/scheme dialects in the rankings.
In contrast, the Asana guys are writing their own language+framework and if it delivers on it's early promise they'll be outgunning the competition with a 10x improvement on development time and code size.
That's the sort of advantage Paul Graham had by using Lisp in ViaWeb vs. his competition that was mostly writing c++.
As for your argument on scalability, while I have dabbled in Lift, I am too ignorant to know how much work it would take to scale Lift versus alternative technologies. I find it hard to believe that choosing Lift is really going to make it that hard to scale. David Pollak and the creators of Lift seem like they are pretty smart people to me. However, I have no evidence to prove you wrong and therefore did not even address that point.
Here's my point as a startup conjecture:
"Sacrifice the network effects of established languages/frameworks only when it gives your startup an unfair (10x) advantage."
There are at least 3 areas of technical focus at a startup after you reach product/market fit: 1) ease of feature development 2) ease of hiring 3) ease of scale under load
The author sacrificed 2, needlessly created well-known scale issue that could be avoided in 3 (basic distributed systems class), for no substantial improvement over the other options for 1.
Yes, I have a bias towards startup team members factoring in their future impact on their coworkers and the company.