2 ms·
(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 everyon
by 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).