Stephen Colebourne, developer of the Joda Time library and spec lead for the JSR 310 date time improvements to the Java language, has posted a thought-provoking piece on the applicability of the Scala language. He compares it to EJB 2, which he said was the nadir of the Java EE specification:
… where huge amounts of boilerplate, XML and general complexity were foisted onto the Java industry. The spec was widely adopted, but adoption was followed by criticism. Developers found that while EJB 2 sought to reduce complexity in building an enterprise application through an abstracted higher level API, in reality it added more complexity without providing the expected gains.
Although he notes he prefers the Fantom language – but is also open to other languages like Kotlin, Groovy and Ceylon – he thinks that Scala is not suitable for the future.
One of his objections is that Scala doesn't provide a suitable module system. He notes that Java didn't initially provide a module system (and currently still doesn't, though at least now it's an acknowledged need) and had to have others such as Maven, Ivy and OSGi add onto the basics. However, those who choose to ignore module systems can still cause problems for those who want to modularise; and when working with large systems, modularisation is an important maintenance tool to have.
Stephen also suggests that had Java had modules, it would be possible to ship a JVM without CORBA support, a legacy technology that is now rarely used outside of RMI in the Java landscape (and generally has been superseded by either SOAP or REST for inter-server communication).
In fact, there was a proposal for modularity over two years ago, which was quickly canned. There was severe resistance to cater for versions or modules (upon which every module system needs in order to operate). At the time, Scala was not enterprise ready and over two years later, is still in the same situation.
Stephen also identifies the type system as being overly complex, agreeing with Steve Yegge's views:
The... the the the... the language spec... oh, my god. I've gotta blog about this. It's, like, ninety percent [about the type system]. It's the biggest type system you've ever seen in your life, by 5x. Not by an order of magnitude, but man! There are type types, and type type types; there's complexity...
They have this concept called complexity complexity<T> Meaning it's not just complexity; it's not just complexity-complexity: it's parameterized complexity-complexity. ... I mean, this thing has types on its types on its types. It's gnarly
Stephen also highlights the fact that the type signatures – initially used to demonstrate that a method compiles correctly – have effectively become meaningless, even before the Unicode method support is used. He gives the following method signature, from the Scala core libraries, and challenges those to describe what it does:
def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That
In fact, Stephen argues that the use of static typing is giving static typing a bad name:
Oh, and by the way, I do get the idea that the humongous type system is there to prevent compile errors and pre-check your code. But applying that logic in the opposite direction would imply that no-one gets any real work done in languages with dynamic type systems. For me, Scala's type system is way way beyond the point of sensible returns for a language feature.
In essence, Scala's type system is giving static typing in general a bad name.
These are not particularly new views. Ceki Gülcü, creator of the Log4J and SLF4J projects, asks if Scala is worthy of your trust, noting that the language has evolved and broken backward compatibility so many times (with no views to the future of fixing it) that it cannot be used:
However, there is one aspect to the Scala language which I find deeply annoying. Scala keeps breaking binary compatibility with every new release. In spite of previous promises, compatibility was broken in release 2.7, broken again in release 2.8 and broken yet again in 2.9. As I understand it, Scala language designers are forced to breaking compatibility whenever Scala library traits change in an incompatible way
To expand on Ceki's point, it is broadly the case that before Java came along, compiling from source was the way that portability was achieved between different operating systems and different versions. It wasn't until a standard C ABI was created that binaries could be made available and then used for different versions of the same operating system, ultimately leading to binary distributions like Debian, RedHat and Ubuntu. It was a lack of these ABIs that prevented companies from shipping binary versions of their commercial products (and they certainly didn't want to share the source) in the earlier 1.x releases of the Linux kernel and operating system.
Ceki further makes the point that "Competing languages will eventually close the gap, and Scala will stop being cool." Scala had a chance, when it was new, to capture the imagination of a large set of Java programmers. It still initially tempts those who want to learn about functional programming aspects and to provide concise code. But by consistently ignoring what makes a language stable over time, and following the same path of bloat that Java had done years before (whilst ignoring Java's compatibility between releases) has kept Scala in the sidelines of major enterprise projects. Yes, there are some success stories of teams adopting it initially, but there are no success stories of teams successfully maintaining that codebase a year or two later.
And now, we have a raft of other JVM based languages that provide a similar avenue of exploration, from Fantom to Xtend, which are stepping up to take their place. Even Java is providing both modules and lambdas in the next release; and even though it's been delayed a further year, is still likely to bring functional programming to the Java masses far quicker than Scala will stabilise. It may be too late for Scala to put its house in order before Java overtakes it.