From an outsider perspective (but my last company used Scala heavily), Scala supports nearly every language feature under the sun to the point that idiomatic use of the language is hard to define (unlike say Python, which has very strong idioms).
It seems that if you want a multi-paradigm language, Scala is excellent. But if you just want to go down the functional route or OO route (without overlap), there are arguably better choices.
Most of my background is in Python, but I've dabbled in a lot of languages out there from Haskell, lisp, Perl...etc. The point being I don't mind trying new things. I don't know Java and the JVM very well though and a lot of hosted languages like Scala, Clojure, Kotlin...etc seem to assume that you're intimately familiar with it which is a pain. Also, the Scala tooling when I last checked ~2 years ago was complex. I just wanted to write a simple app and started drowning in the complexity of SBT and gave up pretty quick. Your mileage may vary, especially if you're already familiar with the Java ecosystem. I've had more success with F# and OCaml.
Note that I'm not saying Scala is bad, it just wasn't an easy enough transition for me to justify climbing the plateau. Clojure ended up being a similar situation. These languages are also optimized around writing large software projects and that was a hindrance rather than a benefit to someone that does more scripting than anything.
Non-FP folks can hate on it because FP is confusing.
FP folks can hate on it because it doesn't have pure functions.
I don't believe the "best of both worlds" selling point.
Anyway I don't think it's worth dwelling on popularity. Networking and political effects seem to be more powerful than the merits of a language.
I'm doubling down on my "both worlds" point, whether you state it as (scala = FP and OO) or (scala = FP or OO).
My choice to be null-free does not survive my coworkers' choice to use null. Likewise with mutability, purity, inheritance etc.
The feature that I want is to look at (n : T) and understand that T is T, not (T | ? extends T) and that n is n, not (n | null), or n now and n' later.
The academic origins give the language a clarity that's great, at the same time macros and implicits and other language features make IDE support slow and error-prone and the compilation process as a whole rather slower than Java's or Kotlin's. On top of that, the designers introduce breaking changes in every minor release, which makes it a poor choice for software that you want to last very long.
All of these factors contributed to Scala adopters like LinkedIn subsequently retracing their steps and doing new development only in Java.
So, academic origins are fine (many good programming languages have academic or at least research-influenced origins), but an academic attitude to the development work that a language should support (predictability of breaking changes, possibility of good IDE support) harms the adoption of a language.
There are well established programming languages for every single niche requirement. What's Scalas unique selling point? Where are they supposed to get/"steal" their users from?
At a concrete use case level, it's a language where you can write Java- or C#-like code with no "magic": no reflection, no AOP, none of the stuff that tends to be the biggest cause of bugs in real-world Java/C# codebases. All of the stuff that you would need reflection or AOP (or metaclasses or macros, in other languages) for, you can do in plain old Scala code.
In the abstract, it's the only mainstream language to offer both higher-kinded types and traditional OO ("extends") inheritance. From one side it offers all the good stuff of OCaml, F#, Swift, Kotlin, or Rust, but with a better type system that makes handling secondary concerns via "context-like" types a breeze. From the other side, it offers similar power to Haskell, but with more understandable performance, a better library/tool ecosystem (IDE, profiler and so on), less reliance on memory-unsafe code in practice (a lot of things in Haskell require C-wrapping libraries for things like image formats, whereas the corresponding cases in Scala wrap Java instead), and the ability to use traditional OO style if you want.
Well the oblivious answer would be Java, but I get that my contempt for it is the only thing causing me to look at Scala and that's by no means universal as most people are pretty happy with the latest versions.
Maven itself works fine. In nine years of Scala I've never understood what problem SBT is supposed to solve - it seems very complicated to no real benefit.
I had heard that use case mentioned now that I think about it. To my mind it makes much more sense to have the IDE handle that part; the IDE knows which file I've edited and when I've saved it rather than having to scan the filesystem. But I guess some people must find it useful.
I have never fully understood why people are often upset with SBT.
Sure it is not perfect, but the alternatives are much worse and most of the issues people have with SBT projects are other people abusing the build file.
The REPL, fast incremental builds, continuous unit testing, shared SBT sessions, etc makes my day so much better.
I live all day long with: `~testOnly *WalabySpec -- -z killRoo`.
Whenever I have to jump into an app using Maven or only slightly better Gradle it is so frustrating.
Present (1.1+) SBT is much much nicer. It's the same core, but the new syntax does a great job of exposing what it does. It's still a complex tool, but it has become learnable.
Also SBT has been much less of a nuisance recently. They've made quite some effort to get rid of the most obscure syntax and with the recent improvements in compiler speed it's inching to 'acceptable' territory.
Because Gradle requires an additional daemon sucking up 2GB and uses Groovy for plenty of its tasks, instead of using declarative builds implemented in Java without using background daemons.
I seldom see conference talks how to optimize Maven builds, Gradle talks about build optimization, at least one per Java conference, and several per Android one.
That's just bizarre. And so far removed from my experience I'm genuinely surprised.
I've never had a gradle build that didn't manage to remember I've only just compiled the code and haven't changed any of it. I can't remember ever having a maven build that could tell I didn't need to compile every single time. And the same the whole of the way down the stack.
Nice attempt to imply gradle isn't declarative though.
