Ask HN: Java 8 or Scala?
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?
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.
38 comments
[ 6.6 ms ] story [ 98.0 ms ] threadWe 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.
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.
Because of this, it's possible to be much more expressive in Scala and it's possible to be much more terse/obtuse.
I like Scala's powerful type system -- I just have a hard time reading most other people's Scala.
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).
I use Ruby on Rails and Django - and in ruby and python, it's interpreted on the fly.
How will a type system, let alone a "powerful type system", help improve ruby or python's web apps?
For example, Javascript's type system (such as it is) is not, in my opinion, as powerful as Java's -- since there's no compile-checking and the runtime coerces stuff all over the place and does basically no checking at any point.
Python's is somewhat better: there's runtime-checking, but it's duck-typed -- so you could call some array methods on an instance of, say, "FootballField" just because the FootballField has a "__len__" property and the runtime wouldn't catch it.
Java's type system is a tiny bit more powerful -- the compiler does a lot of checking for you (so you can enforce that a method must take an array or a List<something>), but it's not as flexible (until JDK8, there was almost zero type inference, so you had to be super-explicit everywhere).
Scala's type system is more powerful still; traits allow you to describe similar classes in a duck-typed-esque way (without the classes themselves having to opt-in), and there's really good type inference.
I'm not an expert in Scala, so I could be wrong about some of its features in particular, but that's the sort of thing that I mean by "powerful type system".
There will be a transition time for non-scala devs, but it should easily pay for itself down the road.
I miss Java's verbose-ness. It's hell, but for large codebases and tooling - I wish I had a bottle of JDK 8 right now.
I heard a lot of this "prescription"-like talk, it'll buy us a lot X down the road. I blame our "this or nothing" attitude toward scala.
We would unconsciously, I think, immediately cast aside any contrary information. We thought ourselves as using this perfect tool and were condescending to anyone who used other things.
We wrote everything in it. We fired 2 node/python coders.
We're too invested and afraid to admit reality, it's a flawed language. Too complicated. Too many idioms for the lexer to handle.
Frankly, the only scala engineer who ever admitted it (they outright ban scala detractors on the mailing list and freenode) was Brad Phillips. Don't take my word for it, I recommend looking him up.
1) succinct != readable
2) ReSharper and Roslyn IDE support makes a difference
3) there is no work opportunity to learn it
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
Where will the team get Scala expertise?
Where will it get Java expertise?
What is the buy in to Scala from the team as a whole? What is the buy in for Java?
What is the level of expertise with Play?
What languages and frameworks has the team used previously on successful projects? What has it used on unsuccessful ones?
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.
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.
Good luck.
I might consider taking a step back and reconsider your decision making steps to this point.
If for some reason you have to use Play then the only sensible choice is Scala.
Why scala? Because LinkedIn and Twitter use it?
I have had great experience with Django in the past 8 years. Nice tooling. Nice template engine. Nice ORM. Mature. Scalable. Robust.
The main detractor you'll hear about it is performance. You're just building a website. Even in situations where I'm recompiling LESS (bootstrap), with all debug tools on, and rendering images in the same pageload, it takes 200ms.
Since python is interpreted, you just refresh the page. No 10 minute compiling just because you had a typo.
One thing about django I don't like though is you never get the "snappy" feeling of just loading a page like lightning fast. Java / scala / golang gives the impression.
Edit: Oh, right. After reading your other comments, it's obvious that you haven't used Scala.
Before I get into that, you may want to not focus on the framework so much, at least not before you choose the language!
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).
Java is super easy to find answers if you need to and super, super easy for one developer to inherit the code of another.
But then again, Scala might be the right choice if you HAVE to use Play, as Play was written in Scala.
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.
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.
After switching back and forth between Java and Scala a lot I find that I prefer Scala. I have never used it in teams of more than a few people though.
I would recommend the same thing I recommend to all teams. Mandatory code reviews. Don't think of them as judgement. Think of them as async pair programming.
If you want really bad IDE support you can always cross compile Java and Scala in same project with Maven.
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.
One way that Scala does win big is supporting a repl style of development. One great example of this is the Spark repl.
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.
Checked exceptions make Java 8 lambdas basically worthless.
Play is a Scala project first and foremost.
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).
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!
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.
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.
I'm absolutely loving Scala right now. I was writing a lot of stuff in Go until I started a new project that needed to leverage some Java libs. I had been wanting to try Scala, so I went with it instead of Java (or Clojure, etc).
I liked Go for it's elegant concurrency, ease of deployment, and fast compiler, but Scala's type system and composition with for comprehensions is really nice.
Java interop is pretty seamless so far. Scala has nice primitives for wrapping null and exceptions in safer ways and eliminates a lot of ugly x != null checks everywhere.
Coming into it, I'd heard that Scala was hard to learn, but I didn't find that to be true. I was only vaguely familiar with pattern matching, monads, traits, ADTs, etc from playing with Rust, but I found plenty of good resources for learning Scala.
I really found this series of blog posts to be helpful: http://danielwestheide.com/scala/neophytes.html
Scala has the best collections package I've ever seen in any language so far.
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.
As somebody else mentioned, using Spark API in Scala was a joy. Same code in Java becomes several times more verbose.
At the end of the day you need to evaluate your team & develop a consensus. Your team might have some valuable opinions too.