Starting out, it makes sense to just "write Java in Scala", and gradually introduce the advanced concepts of Scala as you learn them.
That way, you can be immediately productive.
That way, you can be immediately productive.
> There will be some very tense discussions about how things things ought to be implemented (...)
Encoding as much as possible of the problem domain's logical constraints in types. Any property enforced by a type checker (and not subverted via a type system escape hatch) is a property that you do not have to test.
> (...) and if not well managed, it can feel like "this approach is wrong. your code is bad and you are a bad engineer"
My experience with most programmers using Java/C#/Python/whatever is precisely that: "Their approach is wrong. Their code is bad. And they are bad engineers." I have to waste my precious time subverting their brittle type systems (downcasts, reflection, assuming stuff is not null, etc.) and enforcing correctness the hard way (extensive testing or even good old non-computer-assisted brain usage), when I could simply read type signatures, get free theorems, run a couple of tests for checking stuff that cannot be inferred from types, and move on to the next thing.
If you see your time as much more precious than your colleagues, and default to treating them with contempt, you're going to have a hard time finding colleagues. Which you may not care about.
But what should matter to you is that it's basically a self-fulfilling prophecy. If you treat your colleagues like that, they're never going to get better, and they're going to be the ones who eventually vote to throw out all your beautiful code and go back to Java, where they at least understand what's going on and nobody condescends to them all day.
I have obtained much better results by first developing a nice logical model (not necessarily 100% formal, but at least rigorous enough to be amenable to formalization), and only then picking a programming language into which the model can be translated with a minimum amount of effort. In this regard, a good language is one that allows translating as many logical constraints as possible into statically verifiable constructs (such as types). The nice thing about static verification is that errors in the translation can be detected as soon as you make them. Heck, in some cases, even errors in the original conceptual design can be detected.
Scala is a better language than Java because its type system is so much more powerful. Using Scala as if it were Java nullifies this advantage, and leaves you only with the inconvenience of having to learn a new syntax. So, what is the point?
Scala only has very limited inference. In fact, so limited that, based on this criterion alone, I would take Java's powerful refactoring tools over Scala's inference anytime. (One of my main uses of inference is enabling fearless aggressive refactoring.)
But let's say Scala had a type system amenable to global inference with a nice principal types property. This does not prevent you from having to annotate types when, at a module boundary, you want a term to have a more specialized type than its principal type. (Within module boundaries, it is admittedly no big deal to have terms whose types are more generic than their use would warrant.)
> "no semicolons, and a shorter form of final"
You cannot tell me with a straight face that cosmetic syntactic changes are a particularly compelling reason to switch languages. (Well, you can, but then you cannot convince me you are a pragmatic engineer.)
> "it's already an improvement over java."
Yes, but, without taking advantage of Scala's powerful type system, is the improvement over Java substantial enough to justify the investment in learning a new language?
What investment? You just write the same code that you were writing in Java. You can do that on day 1 (at least, assuming your IDE and build system have scala support already) - on day 1 your productivity is just as high (or slightly higher, because of the cosmetic syntax improvements) as it was in Java. On day 2 your productivity is higher, as you pick up a little bit of scala. So there's no initial cost - just an improvement. I know this is possible because I have done it.