Imagine another codebase uses a feature like self-types extensively: https://docs.scala-lang.org/tour/self-types.html
A small team has no good way to resolve the argument if self types should be used all over the place or avoided entirely.
A lot of the hardcore Scala community hates Spark which sort of summarizes the situation.
Decoupling modules isn't always obvious in a codebase that's grown organically for 6-7 years now (long before I joined) and the cohabitation with Spark is inevitably going to cause some pains. A couple examples:
- Play-json codecs aren't serializable (ironically enough, Circe, the "hardcore Scala" library is).
- Any library that depends on Jackson is likely to cause binary compatibility issues due to the ancient versions shipped with Spark. Guava can be a problem too. Soon enough you'll need to shade a bunch of libraries in your Spark assembly.
- We have a custom sparse matrix implementation that fits our domain well, it was completely broken by the new collections in Scala 2.13. It makes cross-publishing complicated if I don't want to be stuck to Scala 2.12 because of Spark.
This is an interesting point. Perhaps part of the reason my current employer has been successful with Scala has been that we never were integrated into that part of the community.
We hire non-Scala programmers and they write Scala without any training, and it generally turns out OK and ends up converging in a pretty boring style without any fanciness