I haven't personally looked at the play framework, though a former colleague who is steeped in both rails and scala did a pretty thorough comparison a few months back. He is definitely not a rails partisan, and much prefers scala to ruby as a language, but his conclusion was that while play has a solid core and does many things right (including some things better than rails), it comes up short on convenience and utility functions, templating, and ecosystem.
I think the ecosystem in particular is an area where rails magic makes it possible for the community to create very powerful gems that just work, and is probably where the most time is saved vs. other frameworks that have more of an explicit bent. I understand the skepticism towards the implicit approach--it has certainly bitten me before, and I try to minimize magic in my own rails code wherever possible--but again, if you're optimizing for productivity, it can be a worthwhile tradeoff.
Take devise as an example. Despite using all kinds of implicit and convoluted magic underneath, it can save huge amounts of time, especially early in a project, and is well tested and proven in the community. I'm not aware of a lib in any other framework that can handle so many boring authentication issues (sessions, roles, encryption, email confirmation, lockouts, remember me, forgot password flow, session expiration, redirect flows, etc. etc.) with such minimal code and configuration.
Sorry if I put words in your mouth. I do think a framework like play has more conservatism in its blood, which is great. It's good that there are other options for when security, stability, and scalability are at more of a premium than developer productivity .
But seriously, maybe your friend just wasn't all that well versed in Scala. I'm no pro (yet), but on the topic of Utility functions, I haven't run across any big holes. The Collections API is very Fluent (in the Martin Fowler terminology describing Ruby's Array), so it's hard to fault that. In fact, it goes quite a bit farther.
You have Option, Try, Either to use FP in a way Ruby-only programmers probably won't ever grasp. I certainly didn't. I've never seen any real Ruby code that comes close to a foldMap (foldLeft(Tuple2[Accumulator, Map])), or a Try pattern match, or (you could go on and on...).
Templating I don't get unless you're wed to HAML maybe. There are similar libraries for Scala, but it's hard for me to imagine someone being able to compare Twirl (Play's templating) to ERb and declaring ERb superior on any metric. Twirl is arguably simpler, definitely far faster, has no identifiable magic, and Scala+Twirl makes it silly easy to avoid a whole class of common problems with branching logic (hello id=4 my old friend!).
Play has First Class Forms. Rails doesn't. I'm sure Rails will some day. Declarative data binding is simply better. Safer, simpler, provable correctness.
I'd give Play a second look. :-)
To be fair, the one gap I've come across is in String manipulation. A few minutes of googling and a little tweaking and I've got a quick slugging function though: https://gist.github.com/sam/5213151
And then there's stuff like writing:
10 seconds
Which makes me giggle a little inside every time I write it. :-D
On the other end of the spectrum, there's all the things Play gives you Rails doesn't: Futures. Actors. Async. Chunked Responses (which maybe Rails 5 will have?). WebSockets. Awesome XML (it's nice to use a lib that does not suck if you have to deal with it). Better JSON support. Functional Programming. Pattern Matching. Performance. Built in (Memory) Cache Concurrency. Functional Testing with Selenium. A built-in production ready web-server. Continuous Testing. Deployment Packaging. Bootstrap. LESS compilation. SBT: A single tool that provides file system watchers, Tasks, compilation, packaging, dependencies (including Git). All the JARs a Jar Jar could Jar if a Jar Jar could Jar Jars.
The only significant downsides I've run into are:
1. Sharing your code as a package is harder. Much harder. Nexus isn't nearly as low friction as rubygems.org.
2. Binary Compatibility concerns means sometimes your best option is a source dependency.
Git dependencies have been a good solution to #1 for me so far, but I know the day will come when I'll have to figure out hosting on Maven Central.
I think the ecosystem in particular is an area where rails magic makes it possible for the community to create very powerful gems that just work, and is probably where the most time is saved vs. other frameworks that have more of an explicit bent. I understand the skepticism towards the implicit approach--it has certainly bitten me before, and I try to minimize magic in my own rails code wherever possible--but again, if you're optimizing for productivity, it can be a worthwhile tradeoff.
Take devise as an example. Despite using all kinds of implicit and convoluted magic underneath, it can save huge amounts of time, especially early in a project, and is well tested and proven in the community. I'm not aware of a lib in any other framework that can handle so many boring authentication issues (sessions, roles, encryption, email confirmation, lockouts, remember me, forgot password flow, session expiration, redirect flows, etc. etc.) with such minimal code and configuration.
Sorry if I put words in your mouth. I do think a framework like play has more conservatism in its blood, which is great. It's good that there are other options for when security, stability, and scalability are at more of a premium than developer productivity .