Scala runs on the JVM and puts a strong type system in front of it, which means whole categories of error are caught while the code compiles rather than while a customer is using it. NUZM uses it for back-end services with complicated rules, and where an existing Java estate has to be worked with rather than replaced.
What this includes
- Domain rules encoded in types, so an invalid state is a compile error rather than a support ticket.
- Interoperation with your existing Java libraries, which usually removes the case for a rewrite.
- Property-based tests alongside example tests, which find the inputs nobody thought to try.
- A documented build, because an undocumented JVM build is the thing that stops working the week the person who wrote it leaves.
Is this the right choice for you?
Right for data-heavy back ends, financial and rules-driven logic, and teams already invested in the JVM.
Wrong for a small service that Go or PHP would finish sooner. Scala rewards a codebase big enough for its type system to pay for the compile times, and punishes one that is not.
Worth knowing before you commit
The usual complaint about Scala is that every team writes a different dialect of it. That is true and it is a project decision, not a language one. We agree which subset the codebase uses and write it down, so the next developer reads one style rather than three.