Because all the other languages mentioned are better only from very specific perspectives. Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too.
Scala gets a bad rap precisely because people are big fans of their own way of writing code, call it better, and think that anyone that wants something else is deluded. The Scala way is to say 'sure, you can do that too, to hell with purity'. I'd rather have power over purity any day.
Note: I use Scala in my day job. I consider it better than Java, but worse than other languages. I definitely agree that all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable.
That said, in my opinion Scala's blunders are many. You can find out about many of them from Paul Philips, ex committer of Scala, but if he sounds too bitter to you (he does to me; at this point he sounds like there is bad blood between him and Odersky), here are some of mine:
- Null. Null will come back to bite you in Scala code, whenever you call Java libraries, and the occasional Scala library that didn't get the memo. Sure, you can wrap every suspect value with Option(...), but why should you do this?
- Type inference is not as powerful as in a language with a cleaner type system such as Haskell. I'm told this is because Scala tries to be both OOP (inheritance) and FP at the same time. Here is a clear case of Scala's attempt at being a "jack of all trades" resulting in it being inferior than the sum of its parts.
- Type signatures in Scala collections and core types are extremely hard to read. You do not need to read them, but if you try, you are in for a world of hurt. This in itself is not a mortal sin, but of course if you're willing to forgive Scala this much complexity, surely you're willing to forgive other languages as well?
- Tooling is bad. It's getting better, but it's still bad. SBT is painful to use. As for IDEs, IntelliJ is now the recommended choice; I've tried both Scala IDE and IntelliJ, and they both suck. Slow, spurious compilation errors, uncomfortable to use.
- And finally, telling bit of personal experience: I do NOT use Haskell professionally, yet whenever I want to try a quick idea and see if it typechecks, I find it easier to open ghci (the Haskell REPL) and try my idea than do the same with the Scala REPL. What does this say about Scala?
> all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable.
Scala devs deprecate and remove things that haven't worked out well. They have an established track record of making these migrations easier with each release.
> Null
Upcoming versions will make references non-nullable by default. If you want things to be nullable, you will have to opt-in explicitly with T|Null.
> - Type inference
Type inference is not a huge priority, because people think that it's a good thing that declarations require type annotations (just like it's recommended in Haskell, too).
One of the last pain-points, higher-kinded unification of type constructors, has been fixed recently which will make type inference "just work" in exactly those cases where the lack of type inference was most annoying.
> - Tooling
I think tooling is pretty amazing. Sure, Java has still some advantages in some places. But the tooling is superior to almost all other languages out there. SBT is amazing. IDE support is getting vastly better, not only have Eclipse and IntelliJ improved vastly, but also IDE support for Emacs, Vim, Sublime, etc. is coming along at a rapid rate, and it's just amazing to use. There are so many tools in the Scala ecosystem which just don't exist in this combination anywhere else.
> If you want things to be nullable, you will have to opt-in explicitly with T|Null
I can see how the opt-in null references might help prevent you from writing Scala code that uses null, but how does it help when interacting with Java code?
I didn't downvote you. In fact, I consider your post interesting, because (for example) I didn't know about the opt-in nullable references. Here's a +1 to counter the downvote.
I think that there is not much Scala can do here. All existing evidence from other languages that tried this shows that there is a large semantic gap between "nullable values" and "values of unknown nullability".
As Scala is much more independent of Java it is a much smaller issue, but improvements with Java interop require action from Java library authors first.
The approach of supplying external nullability meta data has largely been a failure, because
a) authors are not aware of the stated, external constraints, so they could break these assumptions in future releases without even knowing
b) it's really really hard to retrofit nullability guarantees into libraries which have been designed without this requirement in mind
c) the existing ecosystem is not very amenable to these guarantees, as nullability metadata would be largely limited to final classes and members, because everything else could be subclasses or overridden in third-party code, breaking these assumptions
As soon as Java library authors themselves start using @Nullable/@NonNullable annotations everywhere, there is a good opportunity of reading these annotations and typing the values accordingly, but without it, benefits are very slim.
The planned changes are valuable for dealing with nullable types, but as mentioned "unknown nullability" needs a different solution, and I think it's currently not worth adding something to the languages as long as there is still hope for widespread adoption of nullability annotations.
- I've never experienced null problems in Scala. There's theory and there's practice. In practice if a NPE does happen, you treat it as a bug and wrap it. I don't experience problems, because Scala libraries are well behaved and for Java libraries I read the docs.
- Being a "jack of all trades" means Scala has the superior module system. In Scala you can have abstract modules, the way you have in Ocaml. In Scala type-class instances are lexically scoped, whereas in Haskell they are global. Haskell's type-classes are anti-modular, which is why there are people avoiding type-classes. A big part of what makes Scala so good is OOP. Haskell needs extensions to achieve similar functionality in a half-baked way and modularity is the main complaint of people coming to Haskell from Ocaml.
Btw, if you ask a C++ developer to describe OOP, he'll say it's the ability of having structs with a VTable attached. Most people think OOP is about state. That's not true, OOP is about single (or multi) dispatch and subtyping (having a vtable), hence it's not at odds with FP, unless you want it to be ;-)
- SBT is amongst the best build tools ever available. I could rant all day about the clusterfuck of Javascript (npm, Bower, Grunt, Gulp, Brunch.io, etc.) or Python (easy_install, setuptools, virtualenv) or .NET (MSBuild, Nuget, dotnet) or Haskell (cabal). For all its quirks, SBT is by far the sanest dependency and build management tool I've worked with. In fact, amongst the best reasons for preferring Scala.js is being able to work with SBT and avoid Javascript's clusterfuck completely.
- I've been working with IntelliJ IDEA with the Scala plugin for the last 3 years. I've had some problems with it, but all minor and it's amongst the best IDEs available, giving you everything you expect out of an IDE. Other platforms either don't have an IDE (Haskell), or require extra commercial plugins to behave like an actual IDE (Visual Studio).
And let me give an example: in IntelliJ IDEA I can click on any identifier in any third-party dependency and it automatically downloads and shows me the source code and I can set breakpoints and debug any third-party dependencies that way. Such a simple thing, yet it's a tough act to beat. Try it out in Visual Studio sometimes.
> I've never experienced null problems in Scala. There's theory and there's practice.
Yes, and I'm speaking in practice! If your language allows nulls, they will be used. I've experienced plenty of NPEs in Scala code, both from Java libraries and from misbehaving Scala code, to know this is real. Lucky you if you haven't experienced them! (As an aside: avoiding NPE is almost never a matter of simply "reading the docs". Many times there aren't docs at all, and even when there are, nulls are seldom documented).
> Being a "jack of all trades" means Scala has the superior module system
Your comparison with Haskell modules is fair. But that's just one aspect. Being a jack of all trades means Scala has poorer type inference, way worse type signatures, and generally it feels less clean than both a purer OOP language and a FP one. Scala does fine in all fronts, but not great. If you want to do FP, there are far better languages. I assume it's the same with OOP.
> SBT is amongst the best build tools ever available
If true, that's... unfortunate. SBT is uncomfortable and bizarre. Before you mention it: Maven looks likewise bizarre to me. These are tools to suffer with resignation, not to celebrate. Talking about Haskell, I'm trying to learn stack, which some say makes cabal more bearable. Are you familiar with it?
I agree IntelliJ is now an acceptable IDE for Scala. It's still ages from the comfort of using Eclipse with Java (at least what Eclipse used to be, not the unbearable beast it is now), and to be honest, IntelliJ only recently became usable. A couple of years ago (definitely less than 3 years), the IDE choked on Scala code and highlighted compilation errors left and right where there were none -- and I'm talking about vanilla Scala code, nothing advanced.
Couldn't agree more with all of this. In practice NPEs are extremely rare in decent Scala code, and very easy to fix. The tooling is great, sbt has a slow startup time but is otherwise good, and I too love the mix of OOP and functional programming in Scala, they're really not at odds with one another.
What languages would you say have definitely better tooling:
I'd say for sure the .NET languages, C++, Java, and Javascript but I'd put Scala just at a level below that, no? The tooling stories for Go, Rust, Haskell I don't think are as strong (yet), but that's definitely going to change though.
- C++ IDEs seem to be constantly fighting with constructs that manage to break the IDE's understanding of the code. It's gotten better with LLVM, but even VisualStudio is far away from providing a reliable experience.
- JavaScript is dynamically typed, so IDE support is not reliable.
Sorry, I didn't see your question before. I don't know if you'll see my answer now, but here is what I dislike about SBT:
- It's unclear whether SBT wants you to write build.sbt or build.scala project files. It's recommended you use build.sbt by default, but I've seen plenty of "simple" projects, sometimes examples but often templates generated by tools, which default to build.scala. And now I've read build.scala is deprecated...
- The syntax of build.sbt is confusing. Is it Scala? Is it a DSL? Knowing Scala is certainly not enough to understand SBT (even for build.scala files!), but if I remember correctly one of its selling points was that it was "just Scala".
- Let's get not started about build files for build files...
- The structure of the file is confusing. I never know when defining a key is going to work or not. There seem to be tons of ways of doing something, which is fine in a general-purpose language but undesirable in a configuration format!
- The many third-party plugins are confusing to configure and are often poorly documented, which reminds me of Maven's discouraging "plugin hell"... I don't think I've ever seen a plugin for Maven which was adequately documented, which means you end up copying someone else's configuration without fully understanding it. I fear SBT is the same.
- Neither IntelliJ nor Scala IDE are entirely happy compiling SBT's project files. Thankfully the support has gotten better, but it's not 100% there yet. This used to be maddening in the recent past; a "compiled" project file which your IDE fails to properly understand is unusable!
> Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too.
This also essentially describes C++. This is also why both languages can be so terrible to use: every library has its own dialect.
Scala gets a bad rap precisely because people are big fans of their own way of writing code, call it better, and think that anyone that wants something else is deluded. The Scala way is to say 'sure, you can do that too, to hell with purity'. I'd rather have power over purity any day.