I wonder to what extent the use of Scala at an organization is a "red flag". No disrespect to the language. I've used it a couple times and if you're all in on FP then it's probably the way to go.
But say you're interviewing for a job - what does it say about an organization if they've picked a somewhat obscure, academic tool to build their product? They are probably exceedingly clever, but are you in for long technical debates about arcane minutiae? Are they stubborn and uncompromising? Do they make impractical technical decisions?
You can ask them a single question to know the answer: do they have any cats/scalaz in their production code? Without their ilk Scala 10 years ago was the language Kotlin and Java are still trying to be.
But from what I have observed in the last few years Scala is either used in legacy projects or you're talking to a hard-core FP shop. The saddest fact that it's true even in Data Engineering with Spark :(
We eventually migrated the vast majority of our Scala code over to Kotlin (and a bit of PySpark).
I found Kotlin to be great for writing very performant concurrent code. It was actually easier to write faster code in Kotlin, and even though the pattern matching isn't quite as powerful, it was good enough. The code was also much easier to grok.
> I've used it a couple times and if you're all in on FP then it's probably the way to go.
It's a hybrid paradigm language and back when I used it (v2), it was perfectly possible -- and common -- to write code without using more FP idioms than is now common in most languages, Javascript, Python and Java included. A lot of people used Scala as "a better Java" back then.
I don't know what's the situation with Scala 3 nowadays, but judging from TFA it remains a hybrid language.
It is also important to keep in mind that there are two very different styles of FP one sees with Scala. Odersky et al envisioned ML on the JVM. And there is also a strong population of Haskell style FP.
Probably just means the decision to use Scala was taken back when it looked like it could really be the next big thing. These days it's clear that Scala has lost all momentum. Scala 3 was an attempt to fix that by appealing to Pythonistas, but I doubt it'll work. It may stick around as the Spark language, but it's hard to believe in a bright future for it.
If an employer uses Scalaz or Cats, on the other hand, run for the hills.
An experienced Scala programmer told me that something he's found important is to restrict a Scala codebase to only some subset of Scala features (or approaches). That's because in Scala you have an extreme variety of ways you can tackle most problems, and everyone has a different favorite way, thus, if that is left unchecked, the codebase can quickly become a zoo of many many different language features and techniques. I think of Go as the opposite, for example.
I can see how that can be a real challenge, but I, for one, am excited by this aspect of Scala more than any other.
But say you're interviewing for a job - what does it say about an organization if they've picked a somewhat obscure, academic tool to build their product? They are probably exceedingly clever, but are you in for long technical debates about arcane minutiae? Are they stubborn and uncompromising? Do they make impractical technical decisions?