The fun part of developing in scala is that it supports multiple completely different styles and paradigms, each has its own strength and weakness. You can pick the most suitable one for the functionality you are working on. On other hand it also make learning more complex. To be most effective, you need to learn these styles and paradigms and the subset of the language features you limit yourself to when in that style. Otherwise, scala is definitely one of the languages that is most capable of producing messy programs.
> The fun part of developing in scala is that it supports multiple completely different styles and paradigms.
Putting on my management hat that thought fills me with horror.
For example pull requests become a nightmare when you have extremely experienced Scala devs using every trick in the book and producing code which no one else on the team understands except those with similar levels of Scala knowledge.
Honestly, it's greek for the rest of us and furthermore it seems each Scala expert has their own way of implementing the same functionality.
I enjoy programming in Scala, I write code in it (when I have to) but in all honesty as cool as it is we find ourselves needing to stick with Python, Java and JavaScript to ensure we have some sort of consistency between new hires and experienced devs.
This is a very good point. I work on a team with 7 Scala developers of varied experience. When someone commits code it is reviewed. If the reviewer doesn't understand the code we will talk it over as a group and either learn the new technique or decide that the complexity is not worth the benefit and maybe even rewrite the commit. We encourage people to talk about new techniques before implementing so that rewrites are rare.
I agree with this 100%. Having too many ways of doing things, and no way to pick between them, results in everyone doing things every which way, all different.
That's why this document exists at all. We can definitely make things better, but to do so requires putting together guidelines, proposals, and consensus (things developers are historically pretty poor at), rather than just cranking out code and complaining (both of which developers excel at, especially fueled by coffee)
But we went through that with C++ already: all companies used to publish their own guidelines of what C++ features were allowed and not allowed to use. Of course, all these subsets were different. And of course, if you work on open source project, it's just impossible to be productive in such a language without knowing all of it.
