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.
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.