4 ms·

Agree. Incidentally Play Framework that supports both Java and Scala was modeled after RoR, so you get both convenience of fast prototyping and the power of the

Agree. Incidentally Play Framework that supports both Java and Scala was modeled after RoR, so you get both convenience of fast prototyping and the power of the JVM at the same time.

akuji1993 8y ago
Hm haven’t heard about Play Framework yet thanks. I’ll check it out after I’m done with work today.
kazagistar 8y ago
Speaking of having to rewrite your entire application, play framework has changed how it interops with DI and a number of other significant details every single minor release, forcing significant changes to update versions frequently. We were pretty gung ho about it at first, but basically all our engineers have burned out on it and we are going so far as to embrace the relative stability and, dare I say, simplicity of spring-boot. It's possible that for Scala development it is a fairly good option, and some of the pieces like the typesafe config library are pretty nice, but at this point we consider play to be more like a curse word representing incompatible inflexible garbage.
- vvillena 8y ago
  That's because they are not minor releases. Play seems to follow the Scala style version numbering (epoch.major.minor). In any case, I'm with you in that some of the changes between major versions they did were painful, especially if the code was structured in certain ways.
vvillena 8y ago
Having used both Play (with Scala) and Rails to create some APIs in a professional environment, there's no competition. Play is extremely robust and quite featured, but Rails development speed is much much faster. Rails is extremely opinionated, but you can learn from every choice the framework made and apply it elsewhere. Play is much more freely structured, which is a double-edged sword. If I had to create a new API from zero, I'd go with Rails.
- neverminder 8y ago
  You may be able to go faster with Rails, but scalability is where Play would blow it out of the water. If suddenly tomorrow my Play services get hit with 100 times the usual user number I wouldn't even notice.
  - vvillena 8y ago
    It's the old tradeoff: dev speed vs performance. I just prefer to go with the tech stack that I feel makes me more agile, more capable of changing direction if need be. Both points of view are valid, of course.

Agree. Incidentally Play Framework that supports both Java and Scala was modeled after RoR, so you get both convenience of fast prototyping and the power of the JVM at the same time.

akuji1993 8y ago

Hm haven’t heard about Play Framework yet thanks. I’ll check it out after I’m done with work today.

kazagistar 8y ago

Speaking of having to rewrite your entire application, play framework has changed how it interops with DI and a number of other significant details every single minor release, forcing significant changes to update versions frequently. We were pretty gung ho about it at first, but basically all our engineers have burned out on it and we are going so far as to embrace the relative stability and, dare I say, simplicity of spring-boot. It's possible that for Scala development it is a fairly good option, and some of the pieces like the typesafe config library are pretty nice, but at this point we consider play to be more like a curse word representing incompatible inflexible garbage.

vvillena 8y ago
That's because they are not minor releases. Play seems to follow the Scala style version numbering (epoch.major.minor). In any case, I'm with you in that some of the changes between major versions they did were painful, especially if the code was structured in certain ways.

vvillena 8y ago

Having used both Play (with Scala) and Rails to create some APIs in a professional environment, there's no competition. Play is extremely robust and quite featured, but Rails development speed is much much faster. Rails is extremely opinionated, but you can learn from every choice the framework made and apply it elsewhere. Play is much more freely structured, which is a double-edged sword. If I had to create a new API from zero, I'd go with Rails.

neverminder 8y ago
You may be able to go faster with Rails, but scalability is where Play would blow it out of the water. If suddenly tomorrow my Play services get hit with 100 times the usual user number I wouldn't even notice.
- vvillena 8y ago
  It's the old tradeoff: dev speed vs performance. I just prefer to go with the tech stack that I feel makes me more agile, more capable of changing direction if need be. Both points of view are valid, of course.