8 ms·

This is mostly due to the Scala compiler being a bit slow. The team at Typesafe is working on that, but if you don't want to wait just buy a decent recent machi

This is mostly due to the Scala compiler being a bit slow. The team at Typesafe is working on that, but if you don't want to wait just buy a decent recent machine with a SSD and you will get back the snappiness you had with Play 1.

papsosouid 14y ago
I'm running on an i7 with an SSD already. Our solution was to not use play (or scala for that matter).
- coopdog 14y ago
  What did you switch to?
  - papsosouid 14y ago
    We ended up using Haskell, which is also famously slow at compiling. But it has been significantly faster than play thus far (using snap's development mode).
    - harichinnan 14y ago
      You are one lucky B!!! Not everyone gets such a choice. It would be either Play or Spring and family.
- coopdog 14y ago
  What did you switch to?
dwhitney 14y ago
I agree with eloisant, if you get a decent machine with an SSD, Play is quite snappy. Recompilations are around 1 second on my MacBook Pro with retina display, which is a small price to pay for the type safety you get with Scala
- deleted 14y ago
  [deleted]
laureny 14y ago
> This is mostly due to the Scala compiler being a bit slow. True. Reloading pages on Play 1 (Java) took less than a second. It's about ten seconds now on Play 2 because of Scala. The move to Scala feels like a mixed bag to me: it added both features and bloat to Play. Play 1 feels so light and fast in comparison. It seems to me the Play developers moved to Scala more for personal fun than for their users (nothing wrong with that, just making an observation).
- zmmmmm 14y ago
  I wish they had gone with Groovy. Groovy 2.x offers pretty much all the benefits of static compilation and dynamic language features together, it compiles on the fly instantly (being at its heart a dynamic language), and has meta programming features (intercepting it's own compilation and changing the AST, etc.) that would rival Scala's. There's a project out there somewhere for integrating Groovy with Play but it looks quite immature.
  - vorg 14y ago
    > I wish they had gone with Groovy. Play 2 stripped out all the Groovy code from Play 1. There must be a reason. > Groovy 2.x offers pretty much all the benefits of static compilation and dynamic language features together Groovy's dynamic compilation is reliable, but sloooooooooow. The static compilation added in Groovy 2 is much faster but still buggy e.g. http://stackoverflow.com/questions/14774709/groovy-2-1-0-weird-behaviour-of-switch-case-break-statement-with-compilestatic http://stackoverflow.com/questions/14774709/groovy-2-1-0-wei... It was written by one developer, and first shipped in Grails only 2 months ago. And does Grails actually use any of Groovy's static compilation features? I haven't seen anywhere it's used: point me to somewhere in the Grails codebase if it does. You don't get all the benefits of static compilation and dynamic compilation together, you can get bugfree (but sloooooooooow) code, or faster (but buggy) code.
    - zmmmmm 14y ago
      > Groovy's dynamic compilation is reliable, but sloooooooooow. I guess you mean execution speed, not compilation? Compilation is fast enough I think. Execution certainly compares fine with other dynamic languages, at least, in my usage (and for some things it is much faster). > The static compilation added in Groovy 2 is much faster but still buggy The bug you mention is certainly bad, but it was addressed extremely quickly. Are there other examples? > It was written by one developer, and first shipped in Grails only 2 months ago A little misleading - static compilation has been in core Groovy for 9 months or so and is now supported by the core groovy team. > And does Grails actually use any of Groovy's static compilation features? I don't know, but it's not really relevant. I'm not advocating for Grails here, I'm advocating use of Groovy with Play. Part of the reason I want that is that I'm not extremely fond of Grails for various reasons.
weakwire 14y ago
play ~run solves that problem for me. As soon I refresh the page compilator is already done 90% of the times
- nessus42 14y ago
  I was going to say the same thing, but I'll just second you. When you use "sbt ~run", sbt compiles each file as soon as it changes. I.e., as soon as you save out the editor buffer. By the time you click on the reload button, sbt has usually already compiled all your changes, and it only takes a second or two for either your working page to reload, or for you to see a compiler error message.
codygman 14y ago
This is one of the reasons why Go's fast compilation is a definite plus. There is a framework in Go that was inspired by Scala: https://github.com/robfig/revel https://github.com/robfig/revel It didn't feel like idiomatic Go to me, but was a very nice, featureful, and complete framework.
- nnq 14y ago
  ...the thing that put me off was the lack of a real ORM for Go (it's on their wishlist but nobody's working on it). I know, I know, "ORMs are all wrong and evil", but when it comes to boring web cruds I'm an ORM whore.
  - codygman 14y ago
    ORM's can be a timesaver, but there are advantages to not envisioning your sql tables as objects, and envisioning them as tables. One thing that comes to mind is ACID compliance. Any other pluses of using sql over an ORM would be appreciated. I have a friend who swears by it, who taught another friend that is now swearing by it.

papsosouid 14y ago

I'm running on an i7 with an SSD already. Our solution was to not use play (or scala for that matter).

coopdog 14y ago
What did you switch to?
- papsosouid 14y ago
  We ended up using Haskell, which is also famously slow at compiling. But it has been significantly faster than play thus far (using snap's development mode).
  - harichinnan 14y ago
    You are one lucky B!!! Not everyone gets such a choice. It would be either Play or Spring and family.
coopdog 14y ago
What did you switch to?

dwhitney 14y ago

I agree with eloisant, if you get a decent machine with an SSD, Play is quite snappy. Recompilations are around 1 second on my MacBook Pro with retina display, which is a small price to pay for the type safety you get with Scala

deleted 14y ago
[deleted]

laureny 14y ago

> This is mostly due to the Scala compiler being a bit slow. True. Reloading pages on Play 1 (Java) took less than a second. It's about ten seconds now on Play 2 because of Scala. The move to Scala feels like a mixed bag to me: it added both features and bloat to Play. Play 1 feels so light and fast in comparison. It seems to me the Play developers moved to Scala more for personal fun than for their users (nothing wrong with that, just making an observation).

zmmmmm 14y ago
I wish they had gone with Groovy. Groovy 2.x offers pretty much all the benefits of static compilation and dynamic language features together, it compiles on the fly instantly (being at its heart a dynamic language), and has meta programming features (intercepting it's own compilation and changing the AST, etc.) that would rival Scala's. There's a project out there somewhere for integrating Groovy with Play but it looks quite immature.
- vorg 14y ago
  > I wish they had gone with Groovy. Play 2 stripped out all the Groovy code from Play 1. There must be a reason. > Groovy 2.x offers pretty much all the benefits of static compilation and dynamic language features together Groovy's dynamic compilation is reliable, but sloooooooooow. The static compilation added in Groovy 2 is much faster but still buggy e.g. http://stackoverflow.com/questions/14774709/groovy-2-1-0-weird-behaviour-of-switch-case-break-statement-with-compilestatic http://stackoverflow.com/questions/14774709/groovy-2-1-0-wei... It was written by one developer, and first shipped in Grails only 2 months ago. And does Grails actually use any of Groovy's static compilation features? I haven't seen anywhere it's used: point me to somewhere in the Grails codebase if it does. You don't get all the benefits of static compilation and dynamic compilation together, you can get bugfree (but sloooooooooow) code, or faster (but buggy) code.
  - zmmmmm 14y ago
    > Groovy's dynamic compilation is reliable, but sloooooooooow. I guess you mean execution speed, not compilation? Compilation is fast enough I think. Execution certainly compares fine with other dynamic languages, at least, in my usage (and for some things it is much faster). > The static compilation added in Groovy 2 is much faster but still buggy The bug you mention is certainly bad, but it was addressed extremely quickly. Are there other examples? > It was written by one developer, and first shipped in Grails only 2 months ago A little misleading - static compilation has been in core Groovy for 9 months or so and is now supported by the core groovy team. > And does Grails actually use any of Groovy's static compilation features? I don't know, but it's not really relevant. I'm not advocating for Grails here, I'm advocating use of Groovy with Play. Part of the reason I want that is that I'm not extremely fond of Grails for various reasons.

weakwire 14y ago

play ~run solves that problem for me. As soon I refresh the page compilator is already done 90% of the times

nessus42 14y ago
I was going to say the same thing, but I'll just second you. When you use "sbt ~run", sbt compiles each file as soon as it changes. I.e., as soon as you save out the editor buffer. By the time you click on the reload button, sbt has usually already compiled all your changes, and it only takes a second or two for either your working page to reload, or for you to see a compiler error message.

codygman 14y ago

This is one of the reasons why Go's fast compilation is a definite plus. There is a framework in Go that was inspired by Scala: https://github.com/robfig/revel https://github.com/robfig/revel It didn't feel like idiomatic Go to me, but was a very nice, featureful, and complete framework.

nnq 14y ago
...the thing that put me off was the lack of a real ORM for Go (it's on their wishlist but nobody's working on it). I know, I know, "ORMs are all wrong and evil", but when it comes to boring web cruds I'm an ORM whore.
- codygman 14y ago
  ORM's can be a timesaver, but there are advantages to not envisioning your sql tables as objects, and envisioning them as tables. One thing that comes to mind is ACID compliance. Any other pluses of using sql over an ORM would be appreciated. I have a friend who swears by it, who taught another friend that is now swearing by it.