@idelwords - It's worth noting that this talk was given at the Bay Area Sala Enthusiasts Meetup hence the focus on the tool (scala) and not the product.
@wavesplash - It's true that there are potential scaling issues when you have stateful servers, but the vast majority of our requests are API requests which do not have this issue significantly mitigating the risk.
It's not the focus of the talk that I take issue with, but that the choice of tools (fun, new, poorly tested) seems to have been made without regard to the needs of the product.
Personally, I think it's better to innovate at the product layer and use the most boring technologies you can get away with below that.
Sometimes there are sound reasons to go with a new technical approach, but by your own admission this was not the case here.
And so the classic symptoms appear - full rewrite, unexpected delays, interoperability problems in the new layer requiring a change in an unrelated part of the app (mysql to postgres migration in this case), hacking on an ORM, the joys of being the first people to discover a new class of bugs at scale.
All of this effort could have been more productively channeled into making the product unique and awesome, however boring the backend.
Unfortunately the rewrite was necessary no matter what tools were used (even if we had stuck with PHP). The existing codebase was bad. Very very bad. And, all things considered 3-4 months for a full rewrite was pretty good.
Whatever downsides there are to the scala/lift decision we have not experienced them yet. Though certainly we may run into them in the future.
Ok, I didn't mean for my comment to seem a bit snarky, which I think it did. He made some valid points and I just wanted to see the discussion continue.
@wavesplash - It's true that there are potential scaling issues when you have stateful servers, but the vast majority of our requests are API requests which do not have this issue significantly mitigating the risk.
-harryh