I work at a major online fashion aggregator and my team uses Scala extensively for our search API (with Twitter's Finatra) and also in several of our data pipeline systems (Akka, Spark). When I joined a few years ago, I was honestly not most excited about working with Scala, but the more I got into it, the more I realised that Scala got a lot of things just right. In particular, I really miss working with the collect…
I used Scala five-ish years ago, and I loved it, but I had two qualms: 1. The community was terribly split between FP purists who wanted to write Haskell on the JVM and pragmatists who leaned more towards the "better Java" side of things. Plus the occasional ex-Rubyists who came up with method names consisting solely of interpunction ("embedded DSL!"). Has any side won? It would be nice to have anything resembling "i…
Using types for side effects (eg Slick does it for DB IO) and error handling (see also Rust's Result type) is great.
Scala's for-comprehension (which is Haskell's "do" notation) is a bit awkward (you have to understand that it's a syntactic sugar, and you have to learn about monad transformers, because you have to align the types, so if you started with an Option you have to return an Option, so you have to wrap your Futures and Lists, but it's pretty automatic).
There are a few things that seems harder if you are used to less pure languages, let's say you can't just manage a request context "somewhere" and rely on the dark arts of whatever Java (or Python's Flask) frameworks do. You have to pass around a context. Use implicits. For async Scala already wants you to pass around the execution context. And that's a good thing. Less black magic is always nice in the long term.
Going full FP can be ... painful. When all you see is functions, functions getting passed function, that return functions, that can be called with other functions that ...
Yes, sure, in the end the data is passed/transformed/filtered/mapped/reduced the same, but usually reading FP code is a lot less straightforward than it should be. (For example nice chained functions / data-pipelines are great, easy to read, etc. But going overboard with currying and function passing is not.)