[vvillena]

Scala dev here. "Having to learn Java" is not true at all, unless you interact with Java dependencies in special ways, or if you maintain a Java API for your Scala code. There are Scala libraries for almost anything, and it's easy to use some Java libs here and there. Creating wrappers is also simple.

One of the coolest things about Scala it that it already contains lots of Java best practices. Case classes, singleton and companion objects, traits, powerful generics... almost every Scala feature is a builtin answer for a Java pattern. Hell, even implicits in all its various forms are elegant solutions to common Java problems. People getting creative with these features is an entirely different issue. It's possible, and desirable, to use Scala to craft simple, elegant, and understandable code. Fancy but unmaintainable code should not ever be accepted: it's the job of the developer to teach the reader what the code does, and while this is true in any language, is more important when coding Scala, because the multiparadigm approach means there are multiple ways to solve things.

What you have to learn, at least in a basic form, is how the JVM works.

[lcall]

Thanks. I used Scala for some years and was always drawing on my java knowledge. Are there now good scala learning materials that don't assume java knowledge?

And the maintainability issue seems similar to perl vs. python in that way: it can be done, but I've found it takes much more work and long-term attention & presence, to enforce things with code reviews than with a project-level config that everyone knows why it is there. Just once when you are not looking and now you have a new (large or small) social and technical headache.

(Edit: in other words, while code reviews are essential I think for many reasons, any time there is a way to enforce something good, before the review, it seems like a win.)

[vvillena]

As for learning resources, I always loved the Oreilly "Programming Scala" book: http://shop.oreilly.com/product/0636920033073.do

It's one of the few books that is structured in the same way a Scala developer thinks. Lots of Scala books follow the same order: keywords, usual syntax, features also in Java, features exclusive to Scala. I think this is damaging for any person looking to learn Scala, because it does nothing to lay out the way the features interact together. for instance, the Oreilly book shows pattern matching and implicits before class hierarchies, and that maps well with how Scala devs work, because the former features are encountered daily, while the latter tends to be uncommon.

As for maintainability: you're right. Stricter languages are more maintainable. There's also the issue of powerful languages attracting certain kinds of people. Over the years, I've settled on a simple policy: reject everything that is not documented. This goes for both internal code, and external dependencies.

[lcall]

Another follow-up about my point #2 above: if scala had done this early on (in an armchair hindsight kind of way), I don't know what need there could have been for Kotlin, and we could be learning one language for both purposes (better java and lots of headroom to learn/grow), instead of requiring 2-3 languages or more. Edit: I would appreciate better thoughts to improve my view on that.