I was being snarky in my another comment and was downvoted as hell. Oh well, I am OK with that. However, I can't help thinking of the failure of Scala at Yammer, which caused a big buzz two years ago [1] and [2]. From the blog posts I've read about Scala and Yammer, they planed the transition to Scala carefully and with passion, and they switched away from Scala in merely one year.
Has the situation changed totally? I don't know. Maybe Scala has improved significantly since then and all the pain points back then have been addressed nowadays. I'd like to be enlightened on these factors.
It's perhaps better to look at other examples such as Twitter [1] and Foursquare. The Yammer issues largely focused on extreme edge cases for performance, which have been improved in 2.10. It's not hard to write Scala code which runs at exactly the same speed as Java code, but is more expressive.
Things haven't changed, using Scala doesn't offer significant benefits over Java and it is just a noisy minority that pontificate over Scala and its supposed (largely academic) benefits.
This is the thing I find most annoying regarding Scala use, and people advocating its use, it just doesn't do anything that Java can't do - plus the tooling for Java is wayyy better, there is a smaller learning curve, you can hire people to work with it and you don't spend your days endlessly debating what obscure language feature that may lead to tighter code in release 2.11.B.3.48d.M1.
> "Scala and its supposed (largely academic) benefits"
Perhaps you would like to discuss the "academic" benefits with the likes of Twitter and Foursquare?
> "it just doesn't do anything that Java can't do"
It's a more expressive language. You could argue that Go and Python can't do anything that C or assembler can't do. That doesn't make Python irrelevant.
> "plus the tooling for Java is wayyy better"
In terms of the JVM the tooling is exactly the same. In terms of coding I use IntelliJ for both Scala and Java development, without noticing much difference in quality between the support for either language. In terms of libraries Scala has access to all the libraries that java has as well as additional libraries designed specifically for Scala.
Most (actually all) Java developers that I know grumble when having to code in Java after they are exposed to Scala.
> Perhaps you would like to discuss the "academic" benefits with the likes of Twitter and Foursquare?
Academic vs Practical probably? What's the point of discussing with <big-name-company>? Devs there do like to try out new tools, new languages, new platforms for the sake of trying as well. Devs are humans with ego as well, just like the rest of us.
> Most (actually all) Java developers that I know grumble when having to code in Java after they are exposed to Scala.
I code in Java, Python, JavaScript (modern) and playing with Ruby/Rails lately but I never grumble when I have to go back to Java because I know there are limitations/disadvantages of the other platforms as well. I use SVN and Git and I never grumble when I go back to SVN on a very large project with multiple component that have dependencies.
I'm also in Java->Scala->Java boat. Supporters often say Scala codes are concise, but we can also write concise Java codes--by properly using 3rd party packages. Also, if you code using frameworks like Play!, there's no significant reduction of LOC (for Scala vs Java)
Scala may be good for one-dev company; but terrible in terms of readability and maintenance for a team where more than 3 programmers work on the same code.
Scala can work great in a large development team. Your sentiments about poor readability and maintenance have little to do with the technology itself; you could say this about any programming language.
People new to a technology have a tendency to flounder around a bit in the beginning because they're naive to common coding standards and principles. After those are found or established then Scala codebases are just as easy to collaborate with on than any other.
It is not mainly about conciseness. Conciseness by itself is not that important. Conciseness is a side-effect of being able to apply DRY and to build more powerful abstractions. You could write more concise Java by using one letter identifiers everywhere, but that would only make things worse, wouldn't it?
Joda's impression of Scala is very insightful and it shows that Joda is an awesome engineer. But first of all, Joda was also careful to explain in his second post (the one that was meant to go public) that Scala didn't work in their own freaking context and that all platforms suck depending on perspective.
Let me address some of the points raised ...
(1) Scala is difficult for Java developers to learn, because Scala has new concepts in it, like type-classes or monads and these concepts are exposed within a static type system. Are these concepts useful? After using Scala for the last 2 years, I can bet my life on it. However there's a learning curve involved and Scala is definitely more expensive to learn than Java. That's why context matters. If a company has the resources to invest in this learning curve, then it's worth it, otherwise it isn't.
(2) Scala is not complex as Joda mentions. Not in the original sense of the word "complex". Scala is in fact pretty simple, as the features exposed are pretty well thought and orthogonal. But those features are powerful. The real complexity comes from its interactions with the JVM, as they had to do some compromises. It's important however to differentiate "easy" versus "simple". See this awesome talk by Rich Hickey ... http://www.infoq.com/presentations/Simple-Made-Easy
(3) As any new community, the Scala community started by doing lots of experiments, pushing its syntax and its type-system to its limits, going as far as to use features that aren't fully baked yet. This happens with languages that try new techniques. But as the community is maturing, those problematic edge cases get flushed out and there are fewer and fewer libraries that go nuts, as more and better best practices emerge.
The favorite example of Scala bashers is the Dispatcher library, that originally went nuts over operator overloading, but that was rewritten [1] and these days Scala libraries are actually quite sane and elegant.
Also, there's nothing wrong with the existence of experimental libraries, like Scalaz. Contrary to public opinion, it's not in wide usage in Scala projects, it's very useful for people that need it and such projects end up exposing weaknesses and pushing the language forward. The existence of libraries like Scalaz is a virtue and really, people work on whatever they God-damn please, you can't blame a whole community for it. Joda used it as an example for the dramatic effect, in a private email, OK?
(4) SBT's syntax looks awful until you get the hang of it, because it uses operator overloading to achieve a declarative syntax for building an immutable data-structure that describes the build process. This syntax will likely get fixed, but it's also a really pragmatic tool and I now use SBT even for Java projects and I miss it when working with Python/Ruby. There's also a Maven plugin as an alternative and Joda mentions the stalled Maven plugin and its lack of support for incremental compilation, however that's no longer true.
(5) Joda mentioned problems with the upgrade cycle. Scala 2.8 should have been in fact called Scala 3.0, as the changes in it were dramatic, which is why when Joda wrote that email, many companies were still on 2.7 and the upgrade to 2.9 scared the shit out of people. However, things are a lot better these days. Minor versions no longer introduce backwards compatibility issues, so if you're using 2.10.3, then you won't have any problems with libraries compiled for 2.10.x and you can even use many libraries compiled for 2.9. It's much more stable.
In regards to why is backwards compatibility affected by new versions, well it happens because the standard library hasn't stagnated. Java has awful pieces of junk in its standard library that were never pulled out or redesigned, but as a new and still growing language, Scala cannot afford to freeze its standard library. And we are not talking about major changes here, just a simple addition of a method to a base interface can trigger the necessity for recompilation.
But these days there are a lot of useful libraries with multiple contributers and that get compiled for newer Scala versions as soon as those versions come out. And personally I haven't bumped into problems because of it, as upgrades for the stack we've been using have been really smooth.
(6) At my old startup, we've built a web service that was able to handle 30,000 requests per second, with responses being processed in under 10ms on average, using only 10 EC2 h1.medium instances. Actually we started by running that code on 10 Heroku dynos, but then moved to AWS for more control. And the code was written largely in a functional style, using Scala's standard immutable data-structures all over the place. People that complain about performance degradation do have a point in the proper context, but people that bitch about it based on other people's opinions or based on silly benchmarks, well such people don't know what they are talking about, especially since immutable data-structures help a lot with multi-threading woes, giving you room to efficiently use the resources available.
Actually, I think Joda's actions of eliminating Scala's data-structures or closures from the whole codebase, were excessive (and I'm trying hard not to say silly).
(7) It's all about the libraries. If every library you're using is a Java library like Joda mentioned they did (as Scala makes usage of Java libraries easy), then you might as well use Java as a language. But if you're using Scala's strengths and libraries built with Scala, with a Scala-ish interface and you like those libraries (e.g. Play, Akka), then Scala suddenly becomes inexpensible.
(8) Stephen Colebourne, for all his talent, is a douche-bag.
>> Scala is difficult for Java developers to learn, because Scala has new concepts in it, like type-classes or monads and these concepts are exposed within a static type system. Are these concepts useful? After using Scala for the last 2 years, I can bet my life on it. However there's a learning curve involved and Scala is definitely more expensive to learn than Java. That's why context matters. If a company has the resources to invest in this learning curve, then it's worth it, otherwise it isn't.
This sounds similar to some of the stories about Twitter's switch to Scala. The developers who liked Ruby loved Scala, while the rest of the team stuck with Java, I believe.
Or, instead of telling me that it's a free country, you could be productive, correct me and (ideally) provide a source. I'm happy to learn something new or have a mistaken belief corrected.
Has the situation changed totally? I don't know. Maybe Scala has improved significantly since then and all the pain points back then have been addressed nowadays. I'd like to be enlightened on these factors.
[1] https://news.ycombinator.com/item?id=3297750 [2] https://news.ycombinator.com/item?id=3292555