I hear that argument a lot, but it only seems to be true if you never need to look at code from outside your immediate team/project (either because you don't us

I hear that argument a lot, but it only seems to be true if you never need to look at code from outside your immediate team/project (either because you don't use it, or you use it without ever understanding it) In the case of Scala: If you ever browse the standard collections library you'll run into a lot of different variance rules and implicit constraints. It is quite hard to really understand the collections library if you don't get your head around those. If you want to use Spray for anything more complex than they spell out in their examples, then you need to understand their magnet pattern. If you want to be able to debug a problem in Slick then you'll need to understand shapeless. If you ever go anywhere near scalaz then you'll need to understand every esoteric symbol and operator in Scala, as well as be able to read and understand Haskell (because the patterns and types in Scalaz are often explained by reference to the Haskell equivalent) Yes, I can set rules for my own team about what features we use internally, but I want my team to at least broadly understand the syntax and patterns used in the APIs that they interface with, which means you need to either read & understand most of the features that you aren't using internally, or avoid a very large percentage of the scala ecosystem.