>Rapid iteration: change the code, refresh the page, and see the change instantly.
I see the play people tout this all the time, and I assume it is in reaction to an assumption of dynamic language people that you have to manually compile every time you make a change. But it is really misleading. You make a change, refresh the page, and wait 10 seconds for it to compile and reload. Iteration speed was just as poor with play as it was with bloated J2EE monsters on jboss.
I have 8 GB of Ram and SSD and compilation speed hasn't been an issue with me in Play. The refresh process in Play is also a lot better than a JRebel-based solution or something similar, because in case of compilation errors Play generates a nice error page.
The refresh speed may indeed be annoying and could be better, but it's less of an issue with Play than in Rails or Django or whatever, because you're working with a static language and while writing code you feel less of a need to see what your new lines of code produce. In Scala, if you're using it as a functional language, all the code you write tends to be correct if it compiles and Play itself uses many functional idioms making it very suitable for a functional style.
It's worth noting what Play gives you when compared to Rails, Django and the like.
Remember that Rap Genius article from a few days ago, in which people complained about Heroku's Bamboo stack and having to work with over 70 Heroku dynos? I have a Scala module on top of Heroku that's processing 25,000 requests per second in under 100ms per request and that's running with just 8 Heroku dynos. And I'm actually dissatisfied because a high-CPU server on top of EC2 would be able to handle all 25K.
With Play you get the best of both worlds. A productive framework and the full power of the JVM. It's not easy to describe how it feels to get this combination, but it feels great, trust me.
>but it's less of an issue with Play than in Rails or Django or whatever
>It's worth noting what Play gives you when compared to Rails, Django and the like.
Perhaps for some, but we have no interest in dynamic languages or frameworks written in them. We were evaluating frameworks for decent languages only. I was only commenting on the compilation speed issue because they constantly brag about fast iteration when it is no faster than a typical bloated J2EE monster.
Not sure about play!, but with Grails most changes are picked up in < 1 second. Grails 2 is better than Grails 1 about reloading and dealing with domain changes (which by default are hibernate classes) - it used to be that most domain class changes required a restart - not so under Grails 2. I rarely restart my Grails dev env throughout a day - 95% of my changes are as fast as write/save/refresh with PHP.
On my wimpy Macbook Air, most Java changes reload in < 3 seconds. Compared to redeploying an entire Tomcat/Jetty app, this is several orders of magnitude better. Combined with the scala console in sbt for interactive coding, the ~test command in sbt for automatically rerunning tests on each change, and the amazing error handling, this is a massive step forward for Java/Scala web development.
>Compared to redeploying an entire Tomcat/Jetty app, this is several orders of magnitude better.
It is? Are you building a war/ear and copying it to a server to deploy or something? I think every java IDE has support for locally building and deploying within the IDE, which is no slower than play's reloading.
For simple setups, that can work. JRebel can help. For more complex servlet apps, especially those with Spring lifecycle management, this rarely works, which means a full redeploy after almost every Java change.
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.
Really? I can see claiming Scala is superior to e.g. Ruby would be controversial, but I can't imagine many people claiming Java is as powerful, particularly here.
Scala has way more language features than Java, that's for sure. It does have powerful abstractions and it makes a lot of things more elegant. You could say the same about C++ compared to C.
But in both cases, sensible people can disagree on whether or not the additional power justifies the additional complexity and those insane compile times.
And just to be a little more specific in what I mean by complexity: What I mean is, how much do you know about what a particular piece of code does when looking at it in isolation? How much additional context do you need to figure out what it does? How many possibilities are there?
Powerful syntactical abstractions are a double edged sword.
It might be surprising but Scala actually has significantly fewer language features than Java. It is also more regular, there are fewer special cases and surprises.
What Scala has done however is to pick particularly powerful features that are allowed to intersect as much as possible giving a lot of flexibility. At the same time it has introduced and encouraged functional programming concepts which are new to many OO programmers with Java backgrounds. This can make it seem a little daunting but I found it no more difficult to learn than any other language and easier than some.
The compile times are simply because the compiler is doing a lot more. It's always going to be slower than the Java compiler, though there are still optimisations that can happen. That's a trade off, the additional expressivity and safety of the type system is either worth it to you or not. In the case of Play, you're getting compile time checked routes and templates for example.
In terms of reasoning, it is much easier to reason about idiomatic Scala code in isolation than it is Java. This is because you have much richer type information and can apply the substitution model without being worried about mutation and side affects. It is true however that the flexibility you are given can be misused and you aren't forced to stick to a functional style, so when someone goes off the reservation that can result in hard to comprehend code. Most of the FOSS projects I've seen in Scala avoid this but YMMV.
I don't doubt that Scala does the things that both languages do in a cleaner, more regular way. But the kind of syntactical abstraction that Scala supports lets you replace semantics that you can't replace in Java, which creates uncertainty. Consider this:
a = b
In Java or C this can only mean one thing. The value of variable b is assigned to variable a. In Scala it could mean the same thing, or the = operator could be overloaded and b could be a method call. If you need to know which one it is, for instance because you're trying to understand someone elses code, then you have more work to do than in Java.
Not a great example because actually you can't override simple assignment but that aside, I was disputing that Scala had more features. It doesn't. I've acknowledged that the features it does have are more powerful and could be abused.
The fact that operators are methods and can be overridden simplifies things - you no longer need to know and remember operators. They are always methods on the type you are looking at. This is what I mean by more regular and fewer surprises, the footprint is smaller.
So you can use this simpler, more powerful feature to create DSLs. They are compile checked and are "real Scala". The tools autoamtically help you. Of course, DSLs exist in Java but they often involve tools like JTB and JavaCC, extra compilation steps, no compiler assistance for users - I could go on. Which is more complex?
Anyway, I agree you could abuse the more powerful language features to write hard to comprehend code. However if you take a look at Scala code in the wild, you will see that these concerns so far have been largely theoretical and of course you can also write incomprehensible junk in Java or any other language should you wish.
I'd encourage people to try the Coursera Scala course which is running again soon, and see for yourself.
It doesn't matter which operator you choose as an example. It's the same with a == b.
And I don't agree that it's a theoretical problem that only arises with bad code. It's simply a downside that we have to be aware of when we use DSLs, even well designed ones. For some purposes bland code is just better than smart code.
But I do agree that a Scala based DSL is hugely superior compared to any byte code manipulation based Java framework that obscures lanaguage semantics beyond recognition. It's also way easier to reason about Scala code than about Python/Ruby style meta programming.
It's funny that you keep picking blatantly wrong examples.
scala> def ==(a: Any) = false
<console>:7: error: overriding method == in class Any of type (x$1: Any)Boolean;
method == cannot override final member
def ==(a: Any) = false
^
Maybe you should actually use the language for a few minutes before commenting? :-)
Maybe you shouldn't try so hard to deliberately misunderstand what I'm saying. Your nitpicking doesn't change the fact that you can redefine what == does in your own classes.
I hope you do realise that my point isn't even specifically about Scala, but about syntactical abstraction in general.
> It might be surprising but Scala actually has significantly fewer language features than Java. It is also more regular, there are fewer special cases and surprises.
Yes, that's what all the Typesafe employees repeat ad nauseam at conferences and on mailing-lists. Anyone who has spent more than a year coding in that language knows how ridiculous that claim is.
I'll just pick one example: _ has six different meanings depending on where you use it.
It's fine to like a language (I love quite a few myself) but don't drink the kool aid and try to remain objective about the strengths and weaknesses of your tools.
You don't like someone's experience and claim that people who agree are basically paid by Typesafe? Great way to debate.
FYI: I don't work at Typesafe, and I share his experience.
One great thing about Scala is that one can immediately tell whether someone has actually used it by looking at the complaints.
Things like "OMG _!!!", "Null, Nothing, None ... sooooo confusing", "Perl", "C++" give it away immediately.
I wonder why people are not more upfront and honest about not having spent more than 5 minutes with Scala.
It's totally OK, no one can learn everything.
I don't deny that. What adds to complexity more than verbosity, though, is that Java's lack of abstraction facilities leads to the overuse of frameworks, including byte code manipulation and excessive reflection. At that point it can get really obscure.
But you can write straighforward Java, and on average reading someone elses Java code is easier than reading typical C++ code for instance. I don't have experience with reading other people's Scala code but it seems similar to C++.
One of the worse examples I have come across is using BigInteger. You end up with code like this:
BigInteger four = new BigInteger("4");
BigInteger sum = four.add(new BigInteger("2")); // assuming you won't need 2 again so why store a in var
I never wished for the ability to do operator overloading anymore than I do when I have to use BigInteger in java. It just makes math look so unnatural and hard to read. You end up with variables all over the place to do Math on numbers or have to create a bunch of them in the method arguments. Just an utter mess when compared to the similar class in C# that does it with operator overloading.
> Java can also become very complex because of it's simplicity.
Another way to say this is that Java is a lower-level language than many newer languages, consequently it's much more wordy. And it is certainly wordy, to the degree that it's difficult to follow one's own code. And I see you make a similar point.
I wouldn't say that. I think the main difference is that Scala spent its language design budget on more useful things compared to Java. Have a look at C# if you want to see a language with tons of features.
> What I mean is, how much do you know about what a particular piece of code does when looking at it in isolation? How much additional context do you need to figure out what it does? How many possibilities are there?
From experience, that amount of code is considerably smaller than Java because I can be pretty sure that some piece of Scala code usually won't mutate stuff all over the place.
Immutability is not a language feature in Scala as it's not enforced like it is in Haskell, so you don't have any guarantees about what a piece of code doesn't do. Granted, you can make a better guess than in Java where mutability is concerned.
Scala's syntax is flexible enough to let you build DSLs. It makes use of operator overloading, optional braces after method calls, infix methods, etc. All features that Java doesn't have.
Being able to build DSLs is a good thing, but the whole point of DSLs is to hide some of the semantics of the underlying language and let you think in terms of the domain the DSL was built for. So there is clearly a power/complexity/understandability trade-off.
Scala is too different from Java to call it better. Java comes with cheap programmers, some of the best tools in the world, reliability, and speed. Scala comes with style (functional, lack of boilerplate, sugar like xml(?)), anecdotal rapid development, and some pretty good concurrency.
Personally I think the syntax in scala is even uglier than Java's, if such a feat were possible, and looking at scala code makes me want to stab my eyes out with forks. Thankfully I don't think I'll have to touch the JVM any time soon.
I would not call Java's syntax "ugly". It is extremely regular and easy to grasp. What it is, however, is extremely verbose. On the other hand, Scala suffers from a bad case of Perlositis: why have one syntax for a language element when you can have three?
It's always about context: if an A/B test show you that changing a button's color from red to blue increases conversion rates by 50%, than red really is superior to blue for this context. Same, if your developers are 50% more productive in Scala than in Java that Scala is a better language for you, same way that red really is superior to blue in the above.
And I really like the dream of a "language agnostic-framework", though I know it's not really possible. It would be cool to have a Play framework which also supports Clojure or JPython or JRuby, as for some developer teams these languages might be superior to Java or Scala - but I know that the development effort would be huge*. But in the real world, 90% of good programmers will take Scala over Java anytime, even if they'll have to learn it! Heck, I'd take C# on mono over Java any day!
I really can't imagine how that is supposed to be even remotely controversial. That's probably as controversial as saying that a $200-CPU built in 2013 is faster than a CPU in 1993.
Isn't that just repeating the “all languages are equal”-myth?
I just hate it when people are right but choose a completely wrong analogy to explain their point: a language's superiority is always context dependent, while a CPUs speed is a cold hard scientific fact (with some gotchas, but nevertheless...). You're right and at the same time using such a wrong argument that you end up feeding the trolls in the process :)
There are certainly languages which are comparatively close, so that it is hard to tell, and where different weightings can lead to different results. That doesn't mean it is like this for every comparison.
For instance, the comparison between Java and Scala certainly doesn't belong to this group, just like comparing PHP with many other languages also leads to a clear outcome.
But honestly, I don't care. There are also people claiming that there is no "objective superiority" in cases like "evolution vs. intelligent design", "6000yo universe vs. billions of years", "software patents vs. no software patents", "no contraception/abortion vs. women's rights".
Its not controversial. Since "superior" is a superlative, it doesn't actually mean anything. So what you said is true but meaningless. Its just a matter of English, not ideology.
My point is that the language is conceited and vacuous, basically used to incite arguments and nothing more. I'm not going to agree or disagree with something that has no meaning.
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.
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-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.
> 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.
When Groovy's author said he prefers Scala (http://macstrac.blogspot.ro/2009/04/scala-as-long-term-repla...) it pretty much sealed the language's fate... though, in all seriousness, there really is too much language diversity on the JVM (how tf would one choose between Groovy, JRuby or JPython? - yeah, you choose the framework not the language, but still, it means that all the good developers are split working on different projects).
That statement is misleading. James Strachan left Groovy a long time ago. Guillaume Laforge has lead the project from almost death to one of the most popular languages in use today.
Most of the technical work has been done by Jochen Theodorou. Others who have helped technically are Paul King, Cedric Champeau, Alex Tkachman, and Jeremy Rayner. James Strachan also did a lot of technical work on Groovy in his day. I'd rather listen to what someone who's done technical work has to say than someone who shows powerpoint slides.
You mentioned Guillaume Laforge as leading the Groovy project, but from my experience, Graeme Rocher, the Grails Project Manager, seems to have far more say over Groovy's direction.
As for calling Groovy "one of the most popular languages in use today", it figures fairly low in most popularity ratings (e.g. not in Tiobe's top 50), and only shows the occasional burst when it's been actively talked up, e.g. just before a conference when the project managers are selling conference seats.
That piece is very dated, and your comment is misleading. He didn't consider Groovy as a replacement for Java at the time because it was not statically typed and did not compile to fast byte code.
In fact, if you read through all the reasons he recommends Scala, every one of them has been addressed in Groovy in the last few years.
Scala did it all first, and has been battle-tested over many years, while Grbdvy's only recently added static compilation. JRuby did invoke-dynamic before Grbdvy, and Clojure did concurrency before Grbdvy's GPars.
...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.
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.
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.
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
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).
You should run Play with "~run" which recompiles on file-change. Running with just "run" doesn't recompile until you hit refresh in your browser. This provides a noticeable difference in the "effective" compile time.
We did. The difference is negligable, it takes a fraction of a second to hit f5. In fact, it costs time fairly often as you save the file, notice right away that you have a typo, fix it and save again, but now it is still busy compiling from the first time so you have to wait out two compiles.
It's a bit sad to have to look outside the standard stack for good solutions to this, but I've had great results with JRebel. The rapid iteration it brings to java easily pays for itself almost immediately, if nothing else than in not having to pull your hair waiting for classloader reloads...
I see the play people tout this all the time, and I assume it is in reaction to an assumption of dynamic language people that you have to manually compile every time you make a change. But it is really misleading. You make a change, refresh the page, and wait 10 seconds for it to compile and reload. Iteration speed was just as poor with play as it was with bloated J2EE monsters on jboss.