We are going to start on a new project. We will be 7-8 developers. 5-6 know Scala basics. We are deciding between choosing Play with Scala vs Play with Java. What do you think will help?<p>I personally like less verbose code and that's why prefer Scala. But considering team would be working and shipping the project, not sure whether Java 8 or Scala would help better.
If your team is open to learning new things and comfortable with the occasional bout of feeling lost, then Scala is absolutely the better choice. The advantages of Scala is not it's lack of verbosity primarily, (Ceylon, Kotlin, F#, etc. are all similar in verbosity) but its support for functional programming. And I should add that 'lambdas' do not make a language functional, imho.<p>Scala's focus on immutability (case classes, std lib), monadic comprehension (for expressions), type class support etc. all make it a joy to be productive in. But it also has proper lambdas that just work right (Java8s lambdas are done poorly for sake of backwards compatibility).<p>You'll find less of a need to rely on frameworks (DI is trivial with just language features, you learn them once, you're good, no spring needed), you'll have less bugs, and it will be more fun!<p>Reasons not to use Scala would be the lack of tooling (you're IDE will annoy you more than if you pick java), your team may get frustrated at times and need to ask the mailing list or IRC channel for help, and new developers who don't have scala experience will need a bit more handholding.<p>We're finding for some cases we get a 100x LOC reduction coming from C#. This is not a joke, and it's not about us writing extra terse impossible to read scala and fitting too much on one line. The type system just allows us to reuse a few abstractions EVERYWHERE. We are getting insane code reuse, even between teams.
From my experience, Java while more verbose offers better tooling, standards, documentation and support. Scala certainly is more concise but there is a cost that you will incur later when trying to debug or maintain s large fast moving code base. Sbt blows, ide support for scala is spotty and good luck defining a code convention and standard that you can automatically lint and format. To me it's c++ for the jvm (not a good thing ☺).<p>The next thing I'd advise is to not use play but to consider dropwizard or better yet spring boot. You may be thinking "ugh spring.. Isn't that so heavy?" Possibly but it's a lot simpler to use, extremely powerful and well documented and supported. Play just doesn't have that maturity and support going for it that a spring or dropwizard have.
Scala for sure. It is a more expressive language that leads to less bugs down the road. Encouraging lots of immutability is huge, as well as a bunch of other benefits.<p>There will be a transition time for non-scala devs, but it should easily pay for itself down the road.
How well does the team know the domain in which the project rests? If it's a well trod domain, going to a new language (Scala) would do well to keep interest high, while not getting bogged down in the challenges of solving a known problem.<p>If, however, the problem domain is relatively unknown, I would recommend Java8, so you and your team aren't fighting two unknowns at the same time.
My preference is Java 8 because I find the Scala tooling to be so-so. I really don't like sbt. I find Java 8 to be "good enough."<p>If you do like Scala, I recommend Martin Odersky's Coursera class. I took it a few years ago and it was great! Really fun and I learned a lot. He is a great lecturer.<p>One way that Scala does win big is supporting a repl style of development. One great example of this is the Spark repl.<p>If you live in the JVM world, Clojure (which I use more than any other programming language) and JRuby are also worth a good look.
I work at a company that exclusively uses Scala for the backend of our applications/services, and I found that if developers are willing, it's almost never a problem to have them learn Scala within a reasonable amount of time, if they come from a Java background.<p>We found that it's very hard to find Scala developers when hiring, so we basically dip into the Java pool and look for strong and talented developers there, that are eager to try and learn Scala. We then train them on the job, which almost never takes more than a couple of weeks before they really become productive.<p>So I'd say, if you're confident in your team as far as their quality as developers goes, then go for Scala. The time lost in learning, will be made up in productivity once they get the hang of Scala and the start experiencing the productivity boost that a more functional approach can give you.
The strange part of that question is you appear to have decided on the framework before the language. Strange because having used Play quite a bit, it's really not all that great in many ways, not good enough to be a default choice anyway.<p>I might consider taking a step back and reconsider your decision making steps to this point.<p>If for some reason you <i>have</i> to use Play then the only sensible choice is Scala.
<i>5-6 know Scala basics.</i><p>Where will the team get Scala expertise?<p>Where will it get Java expertise?<p>What is the buy in to Scala from the team as a whole? What is the buy in for Java?<p>What is the level of expertise with Play?<p>What languages and frameworks has the team used previously on successful projects? What has it used on unsuccessful ones?<p>What matters more in this decision are the human factors, not the technology. That's why you're not considering Clojure among alternatives. If the team is split over language, that's a team problem and the solution can only come via working to get buy in from those who feel they have something to lose if Scala or java is the way forward.<p>Finally, if the long term goal is to transition from Java to Scala, Play with Java is a good first step. It gets Scala in the door, but keeps it out of the way as people are in the early stages of onboarding.<p>Good luck.
Java is the right choice.<p>Before I get into that, you may want to not focus on the framework so much, at least not before you choose the language!<p>Scala is great for the right purpose, it's powerful and should make you productive much faster. Yes, Scala is much less verbose which seems like it would be much more efficient. Enter one Scala developer who has small stylistic inconsistencies and you have set everyone back quite far (especially when using other sources to answer a problem).<p>Java is super easy to find answers if you need to and super, super easy for one developer to inherit the code of another.<p>But then again, Scala might be the right choice if you HAVE to use Play, as Play was written in Scala.
Scala is more flexible (for better or worse) and less verbose (for better or worse).<p>Because of this, it's possible to be much more expressive in Scala <i>and</i> it's possible to be much more terse/obtuse.<p>I like Scala's powerful type system -- I just have a hard time reading most other people's Scala.<p>If you're sure you can get a consistency of style and approach in Scala among your team, sure, by all means. But if you believe that you're likely, at least in the short term, to have stylistic inconsistencies among your team, I'd lean a little more towards Java (just on "worse-is-better" principle).
In my personal experience, Java 8 is a safe bet. Yes, it is more verbose which I don't like either. If you avoid the over engineered frameworks in Java-land its not that bad. You mentioned Play, which as others have pointed out is a Scala first framework. I prefer modern Java frameworks like Dropwizard or Vertx.<p>I tried to evaluate Scala after getting to know some basics & was thrilled at how concise code becomes in Scala vs Java. However, Scala does have a steep learning curve. I found that there were many different ways of implementing the same thing, which is time consuming in the beginning. There is opinion that it pays off later, I was not able to get to that stage because of initial impediments.<p>As somebody else mentioned, using Spark API in Scala was a joy. Same code in Java becomes several times more verbose.<p>At the end of the day you need to evaluate your team & develop a consensus. Your team might have some valuable opinions too.
In .NET as a similar choice, <i>very subjectively</i>, I would pick C# over F#, because:<p>1) succinct != readable<p>2) ReSharper and Roslyn IDE support makes a difference<p>3) there is no work opportunity to learn it<p>4) learning it in spare time would mean not implementing something else - I would prefer to solve domain problems rather than language AND domain problems
If your devs are bright and want to learn something new, go for Clojure. If you already have strong Java skills and need to deliver fast, go for Java 8.