3 ms·
Scala is my favorite language. I use it every day. And yet, the language, and its ecosystem, have big problems nobody wants to tackle. They have nothing to do w
by hibikir 11y ago
Scala is my favorite language. I use it every day. And yet, the language, and its ecosystem, have big problems nobody wants to tackle. They have nothing to do with the myths people talk about though.
For me, the biggest problem is how fractured the community is. Scala is not a very opinionated language at all, so work from different subcultures barely looks like the same language. Working with scalaz? You won't touch the standard library at all. Finagle? Twitter came up with a Futures library before it came standard with Scala, and there seems to be no interest in migrating out of that, so you have multiple libraries for basic concurrency (along with the scalaz version of course). Those groups, that use the language so differently, do not share many interests when it comes to the evolution of the language, what parts are good and bad. This leads to much infighting, and an environment where instead of learning Scala, what people learn is that the community is divided, and often very rude. It makes learning a challenge. Each community also has a different idea of what it is considered acceptable behavior to other human beings. The scala mailing lists has postings that make your average Linus Tovalds post seem sensible and polite.
Another part that makes learning a challenge is how different application level Scala and library level Scala are. In a language like Java, it's easy to go into the standard library, or into whatever popular library you want to use, and look under the covers, even and a newbie, and learn how to write idiomatic Java (whether that's good or not). In Scala, the standard library, and pretty much every major library out there, use language features that are not needed at all for regular use, but are very valuable for building libraries, and yet make the code very hard to understand for someone new. For the worst case of all, look at the source code of Shapeless: Even very seasoned Scala programmers find it difficult to understand, because it's attempting to do things that the designers never even expected people to do with the language.
Another problem, related to the previous one, is that since it's so easy to build DSLs in Scala, pretty much every major library does it. Internal DSLs, implemented around a bunch of implicit conversions that you need to understand pretty well to solve syntax errors. For instance, say you want to use json in your spray web service. There are two ways to do it: Follow a tutorial without understanding it and hope you do not have errors, or spend the time to understand the type class pattern.
And that leads to the last, problem: There are basic intro articles out there. There's information for experts. But the route from basic knowledge to mastery is a big cliff with very little information, and it's easy for people to give up. As it is now, Scala is a language better learned tribally: You have a few gurus, and when complicated questions happen, go ask one of the gurus to see if he can teach you about whatever problem you are having, or about how a feature really applies to your problem.
I love Scala, I really do, but if the community problems are not resolved, the rest of the problems will not get resolved. It will remain a hard language to learn, and other languages that right now do not offer all the rich features of Scala will just steal what they can and replace it instead, just because they have better, less fractured communities.
- adriaanm 11y ago(Scala team lead @ Typesafe here). Thanks for the kind & insightful words! We absolutely want to resolve the issues you're referring to, and we welcome everyone's help and input to speed up this process. We're working on refining our process and our plans regarding library evolution, especially in light of the recent controversy around adding a JSON module to our platform. The first (baby) step I've taken towards bringing the communities closer was embarking on modularizing the standard library in 2.11, which will continue in 2.13. The goal was to create room for other modules to compete with the ones that were originally in scala-library and to allow community maintainers to step forward and own a module (every module now has a community maintainer, who is in charge of everything, short of promoting staged artifacts to maven). I'm very pleased with how this turned out, and we'll continue this effort in 2.13, where we'll focus on modularizing the collections library. (We alternate compiler and library-focussed releases for smoother upgrades, 2.12 is focussed on making the most of Java 8's new VM features.) Two more examples, in which I was not involved: the design of the 2.10 Future API, which was done in collaboration with Twitter; I'm also very excited about the prospect of including Reactive Streams in JDK 9! Personally, I prefer to write a bit of boilerplate over relying too much on extreme implicit magic to eradicate every last line of unneeded code, but I think it's cool that you can do that it you like to. (Disclaimer: I did a lot of work on enabling this implicit magic, between implementing support for higher-kinded types and improving the interaction of implicit search, type inference and dependent method types.) The whole Scala Team is very concerned with the experience of our community in our forums, and we do our best to step in when things get out of hand, including banning repeat offenders (which we don't do lightly). Because Scala fuses so many different PL concepts, it's not possible to make everybody happy all the time. I really like Martin's quote on using abstraction responsibly: > [...] trading abstraction capabilities for basic features > is exactly the opposite of my design philosophy. > My design philosophy is more like free speech. > We protect it even if it is abused. In fact free speech would be a > fiction if there were no abuses. In the same way, abstraction > capabilities would be a fiction if there was no over-abstraction. > I completely agree this approach comes with challenges. It is our > responsibility as good engineers to realize that abstractions have > benefits as well as costs, and to collectively develop designs where > the benefits exceed the costs. Regarding learning the language, I believe we have a lot of excellent post-tutorial material out there, including many books and the Coursera classes. There are many stages of Scala mastery, but you don't have to get to the boss level in order to be productive. Part of the joy of Scala for me is that you can keep learning new features and improve your understanding of how it all fits together (quite nicely, if you ask me).