Just saw this on twitter. Scala, you have my attention. There were a lot of talks about "the tools of yesterday" and "the tools of the future" lately. Scala getting closer to the metal, without the JVM is a significant step toward "the tools of the future".
I would argue scala' main selling point is making the jvm palatable to people who hate Java. However, it's entirely unclear without the jvm why I would choose it over, say, rust, Haskell, go, c++, etc.
Have a look at the adoption of Scala.js.
The ecosystem of Scala.js is larger than the "compile-to-js" ecosystems of "rust, Haskell, go, c++" combined.
One of main strengths of Scala is that people get things done. It's the only language of the ones you mentioned which has reasonable support across three vastly different platforms.
Who actually uses Scala.js, though? It still seems firmly in the hobbyist camp.
> One of main strengths of Scala is that people get things done.
This is also true of rust, go, c++, and arguably haskell. I don't see anything about scala that inherently makes it easier to "get things done". If anything, I've spent a good 10% of my scala development time (over hundreds if not thousands of hours) debugging library, compiler, and documentation bugs and inconsistencies. This is not good for a language where you get things done.
No-one denies Scala is a fine language, but I don't think that's a narrow view of it.
It's actually a pretty good question. A lot of Scala's design is full of compromises made for Java inter-op. A huge motivation for using Scala is "I want a modern language which allows me to use all these existing Java libraries and tools". If you remove the ecosystem and the inter-op, what is there left for Scala? Why not use a better language?
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.
I remember Martin Odersky explaining how the Scala compiler has to do a lot of work to compile FP code to a JVM that is mostly geared for the Java language only.
Because of that the compiler is well positioned to compile to other targets as well. Like Javascript or LLVM.
Are you talking about compromises in the language or the standard library?
In the language itself I can only think of type erasure for generics having to follow the JVM choice.
Snif.
sbt demoNative/compile
seems to work. But
sbt demoNative/run
produces a scala.scalanative.linker.LinkingError
Unresolved dependencies:
`#scala.Serializable`
I don't think the amount of compromises in Scala is more than the amount of compromises in any other language. No matter how clean the language starts up to be, after a certain time it always has to accumulate compromises with it's own previous design decisions, unless it's being kept in the never-ending alpha release state.
Can you provide an example of what you think is a better language?
Over rust/go/c++: more powerful type system, more concise code. Over Haskell: explicit about lazy-or-not, support for traditional OO inheritance when you need it.
Some people from losing ecosystems like to spin it that way¹, but the truth is people are happy, adoption is great, and companies see that pain-points get addressed.
Of course there are companies which drop Scala, but often like in LinkedIn's case it's not caused by a dissatisfaction with Scala, but new leaders making different decisions like "we are using 10 different languages, we should consolidate on X and Y!".
The last unhappy company which is commonly mentioned is this social-network company Yammer.
That was half a decade ago, and most of the issues mentioned have been addressed in the mean time.
(Yammer has been bought by Microsoft, so it also made some sense to use a language that makes getting bought out easier.)
¹ I remember there was some very very bitter Groovy evangelist a while ago.
I know for a fact LinkedIn dropped Scala because of dissatisfaction over Scala. Things like maintainability, the fact it was just a single company developing Scala, etc that caused them to switch away.
Kafka is deprecating their Scala clients because of maintainability issues as well. Scala keeps making breaking changes on dot releases, making it impossible to maintain long term.
That's funny, when I talked to Neha (ex-Linkedin, cofounder of Confluent) she explicitly denied this meme about moving away from Scala.
The new Kafka client library is in Java just to reduce the number of dependencies, the server is still written in Scala. Strangely, using Java hasn't stopped Confluent from making breaking changes on dot release of the client... which really puts the lie to your explanation.
Even if some random kafka committer that you can't source believes that, the reasoning doesn't add up:
SBT makes it fairly straightforward to cross publish for different dot releases of Scala, and libraries in the Scala ecosystem do it all the time.
Scala dot releases are far apart. It's been over 2 years since 2.11, and 2.10 released in 2012.
By contrast, the JAVA client that the Kafka project published in November is already undergoing breaking changes for the current release candidate. It's pretty clear that avoiding breaking changes is not an overriding concern for them, and even if it is, it's equally clear that Scala was not the inherent problem.
Note that the use of major.minor.revision actually predates the formal SemVer specification by something like 20 years.
That doesn't mean you're wrong; but it does explain the confusion. I'm a fan of Scala but I'll admit I was confused by this as well when getting started with it since I've been trained to see everything after the first decimal as "minor".
> I remember there was some very very bitter Groovy evangelist a while ago
Apache Groovy has always been good for scripting stuff on the JVM, including for Grails and as a DSL for Gradle. Unfortunately, one of its backers tried to retrofit it to do static compilation, and pitched it as a alternative to Java instead of simply an accompaniment. That's when the trouble started. Groovy's static compilation can't be as good as that of a language designed from the ground to be statically compiled, e.g. Java, Scala, or Kotlin. To this day, Groovy's own codebase is still Java. Even though some people talk anonymously of "1 million line Groovy codebase where static compilation is required", Groovy's own "million line codebase" isn't statically compiled Groovy and until it is, any claim of such codebases is just a claim, nothing more.
I like Scala, and this is purely anecdotal: but with Java 8 becoming pervasive and large companies adopting Scala style guides that recommend most of the advanced features away [1], Scala becomes a less compelling choice.
Sure, companies aren't dropping existing code in Scala, but I would be surprised if large organization were to push for new code to be written in Scala instead of Java 8.
There are worlds between Java 8 and Scala and the gap is widening with every release.
Of course you can write Java in Scala and then the benefits over Java aren't that high (but are still there), but Scala is so far ahead in terms of language compared to Java that most current Scala libraries just _can't exist_ in Java.
Adoption these days seems to be great and accelerating, and given the growth of the library ecosystem there are more and more reasons to leverage the benefits of libraries written in Scala especially compared to legacy stuff written in Java.
A teaching page will naturally recommend away from advanced features during the teaching phase. Twitter's style guide for first-class scala code is http://twitter.github.io/effectivescala/ and code written in that style has huge advantages over Java.
Twitter is not moving away from Scala. Scala continues to grow at a faster rate internally then any other language, and is ~50% of Twitter's backend codebase.
