Scala 2.12 will have a new compiler backend which should speed things up considerably. [1]
Other than that, as an avid Scala fan, I've been long wondering why people favour Go so much. Arguably, if you've started out with RoR, then Node.js was a great improvement (dynamic typing with awesome speed). Then came Go, which solves many of the issues you tend to encounter with Node.js. So now, after it has reasonably matured, many people are pivoting to it.
Scala, while having a rather "bloated" core library (i.e. quite exhaustive), already does most that Go does (i.e. an Actor is reasonably close to a goroutine etc.) and has an awesome type system. But then, I'm biased and YMMV ;)
Compared to Scala, Go is incredibly simple, both to learn and to use. If you don't have a lot of experience with Java and the JVM, Go also avoids that whole avalanche of complexity, apart from Scala itself.
I meant only that if you want to use Scala, you'll inevitably have to also know Java. It's two languages for the benefit of one. The JVM comes with its own issues: which JDK do I use[1]? What happens when one library I want to use recommends a different JDK than another library I want to use? Build tools questions: ant, maven, gradle? Oh, I need to learn Groovy, too? Three languages for the benefit of one. Yay.
There's just an enormous amount of stuff to learn, and most of it is required-but-incidental; none of it (except Scala, in our example) is an inherently necessary part of getting from learning to a production system running Scala on the JVM, but you will end up having to become conversant with many of these things, and probably dozens of similar infrastructure and tooling systems.
Now I don't know if it's intentional or not, but many things you are saying are just FUD. You seem to be assuming that the only way to do JVM stuff is considering all the difficulties that enterprise Java shops with legacy projects put up with. That is far from the truth, as any tutorial for Spray, Play or Akka could tell you.
> Which JDK do I use[1]?
The Oracle JDK (which is the same as OpenJDK FYI).
> What happens when one library I want to use recommends a different JDK than another library I want to use?
There is a 3-month period or so every three years when a new major Java release is done when some developers of enterprisy libraries might want to do some more testing before making a recommendation. It's not a big question in the JVM world at all, and it's definitely not a big problem even for early adopters.
> Build tools questions: ant, maven, gradle?
SBT. You're building a new Scala project.
> most of it is required-but-incidental; none of it (except Scala, in our example) is an inherently necessary part of getting from learning to a production system
You would have been right five years ago. Today, many people run Akka/Spray/Play projects in production just fine without deeper devops knowledge necessary than with other runtimes.
> You seem to be assuming that the only way to do JVM stuff is considering all the difficulties that enterprise Java shops with legacy projects put up with.
Ah, that's because that was the only place I've had much experience with Java and Scala. We wanted to use Elasticsearch (Java) from our CMS (Java), and the recommended way to do that (at the time: embedding ES in your application as a search-only node) turned out to be infeasible, due to ES and the CMS (which was started in 2006ish) being unwilling to share any specific JDK without a lot of code changes to the CMS. We ended up building a system involving RabbitMQ and a thousand lines of PHP, as the easiest solution. :(
So, yeah, I recognize that a lot of my bad feelings about JVM languages are not particularly relevant to green-field development, whether in Java or Scala. I just got ranty. Sorry.
Why wouldn't you just run ES as a standalone server and use its REST API? ES is a core part of the stack at the startup I work at and it never would've occurred to us to run it as an embedded service.
You'd run the data nodes as standalone servers, but the recommended way to talk to ES from your Java app was, at the time, to embed ES as a non-data node in your app, which means that you could talk to ES in-process, and the local ES would be part of the cluster, just pass on queries and data to the data nodes. This was 2011 (0.18.x or 0.19.x, I think), so maybe that's not the recommended way any longer. The REST interface was also available, and recommended for anything that wasn't Java, and that's what we ended up using (but given the opportunity not to write the code that interfaced between database and ES in Java, we took it, and wrote that in PHP, with just a tiny bit in Java to push a job on the queue).
It looks like that's still what's happening in the Java API: http://www.elasticsearch.org/guide/en/elasticsearch/client/j... I'd like to reiterate that moving our app to a more recent JDK would have also been a good solution, except that we didn't have the dev and qa resources at the time to devote to that.
