Contents
Introduction
I have been promoting Scala for quite some time now, and I have encouraged all of the developers in my office to try it out, hoping that at some point we can start using it for new projects.It was suggested to me that I put together a list of the pros and cons of Scala to help other people in the company evaluate whether they should consider using it for their projects. After pondering this I realized that this would likely be of interest to a wider audience than just at my company, and that it would make a good topic for my blog. Thus this post in which I list what I believe to be the most important factors that a company that wants to stay on the JVM platform should consider when deciding whether or not to move from Java to Scala.
Because this comparison is specifically Scala versus Java, I do not include the fact that Scala runs on the JVM, has performance on par with Java, interoperates easily with Java and after compiling is essentially indistinguihsable from Java. While these might be benefits for some companies when comparing Scala against other language such as Ruby or Python or other JVM languages, they do not distinguish Scala from Java.
The intended audience for this post is not the developers who might be using Scala, but the technical managers who are involved in the decision about what technology to use. I don't discuss Scala's cool features such as closures and continuations, easy interoperation with legacy Java code, traits with code, or a sophisticated type system with type inference, but focus instead on the business-level questions of how using Scala rather than Java might affect the success of a project, a team, or the company.
My company has not yet produced a product using Scala, so my experience is limited to some prototypes at the office and some personal work at home. The points below are based on that experience plus my interpretation of comments from others that I have read in the last couple of years. Everyone's viewpoint differs, so you may disagree with my statements or my evaluation of their importance. Similarly, the specifics of your situation may make your experience with Scala significantly different than mine. It is easy to find both praise and dismissal of Scala on the 'net. As they say, YMMV.
Pros
Higher Productivity
Studies and anecdotal evidence indicate that Scala programs are from 1/2 to 1/10 the number of lines of code as compared to a functionally equivalent Java program The larger the application, the more apparent this difference becomes. If you believe, as I do, that a given programmer can produce roughly the same number of lines of code per day independent of the language used, you can see how this reduction of lines of code can translate into a substantial increase in productivity and a faster time-to-market.Higher Quality
Scala encourages a functional programming style, which in turn leads to code with fewer bugs. Also, fewer lines of code means fewer bugs. Fewer bugs means higher productivity and a higher quality product.Scala's Actor library and its encouragement of immutable variables help to avoid race conditions among multiple threads and thus improve reliability in concurrent applications.
Better Developers
Programmers who learn Scala pick up programming practices such as functional programming that they can (at least to some extent) apply to other languages, such as Java. This makes them better Java programmers. Providing an environment in which developers can learn something new should also make for a more positive environment for those developers, so they will be happier with their jobs and less likely to leave the company. Likewise, a shop that uses a new and advanced language such as Scala is more likely to attract top-notch developers (which Paul Graham has named as "The Python Paradox").Rapidly Improving Ecosystem
The early adopters of Scala such as Twitter are well down that road. Here at the end of 2010 it is tempting to say that the early adopter window is closed and anyone who starts with Scala in 2011 or later is no longer in that category.Some of the cons listed below may never change, or change very slowly, but at least the tools issue will certainly improve. The rate of improvement of the Scala ecosystem is much faster than most other languages at the moment. The IDE tools are improving, the testing tools are improving, the documentation is improving, and the functionality of available libraries is improving. All of these improvements will continue to make the Scala ecosystem more attractive over time. If you evaluate the current situation and find it close to satisfactory, and the problem areas are the ones that will improve with time, then you probably won't have to wait very long for that to happen.
Cons
Learning Curve
Scala incorporates features and concepts that are not familiar to many programmers, such as functional programming and continuations. It can take some time to learn these concepts. Some people say the Scala syntax is more complicated than Java, but in fact the language spec for Scala is significantly smaller (191 pages) than the language spec for Java (684 pages). The difference is that Scala is much more regular and allows things to be combined in ways that can't be done in Java, which provides more power and expressiveness but also can take some time to learn.I have seen comments to the effect that it could take about two months for a Java developer to come up to speed on Scala, although a developer who already has experience using other languages with functional constructs such as Python or Ruby should be able to pick it up faster.
Limited Developer Pool
There are far fewer developers who already know Scala than who already know Java, which means it will be more difficult if you need to staff up quickly and don't want to spend any time training.Because of the more advanced concepts embodied in Scala, or at least concepts which are different from the concepts that many Java developers have internalized, it may be possible that some Java developers will have a difficult time coming up to speed on Scala. This would effectively decrease the overall pool of available developers even if you are willing to spend the time to train someone on Scala.
Until a much larger number of current Java developers try to learn Scala it will be difficult to know how much of a problem this will be. One possibility is that many current Java developers will not want to put the effort into learning the new concepts required to use Scala effectively, and that a large chunk of the growth in the pool of Scala developers will come from new developers who were educated with those concepts from the start.
Better Developers
Wait, wasn't this listed as a pro for Scala? Yes, this one is a two-edged sword. Even after accepting the Learning Curve and the current Limited Developer Pool, there is a possibility that not every Java developer has what it takes to become an effective Scala developer. Scala provides tools that allow highly competent developers to write very concise code, and if you give them those tools they will use them. Developers who are less competent may then have trouble understanding that code. Java suffers less from this particular problem because it doesn't provide the kinds of high-level constructs (such as higher-order functions and continuations) that can cause difficulty for less capable developers. If you take the Scala road and hire highly capable developers, you may be making a commitment to continue to hire only highly capable developers for some time.You should ask yourself this question: would your company culture allow you to hire and keep a developer who is twice as expensive and ten times as productive? If your answer is "probably not", then you should stick with Java where you can hire those developers who are half as expensive and one-tenth as productive.
Limited Commercial Support
If you have a large Java project and you find you quickly need some additional developers, you can call a consulting company such as Accenture or Cognizant and they can throw an army of Java developers your way. If your project is written in Scala, I suspect they will happily tell you they can provide you with those resources, but they might have more difficulty doing that due to the above-mentioned Limited Developer Pool.You could probably post a request to the Scala or Lift mailing lists and find some contractors with Scala experience to help you out, but there is not yet much in the way of explicit commercial support for Scala.
The recently founded company Scala Solutions is the first I am aware of that is advertising support for Scala in mission-critical applications. Large companies considering Scala may not be comfortable without having more choice here.
Tool Immaturity
The development tools for Scala are not as advanced as for Java. In particular, the IDE plugins are not yet as sophisticated, so developers who use IDEs may encounter some frustration. On the other hand, this issue should be addressed by Scala's Rapidly Improving Ecosystem.Former Cons
While browsing the web you may run across people complaining about the items listed in this section. As I note for each item, as of this posting at the end of 2010 I believe these issues have been resolved.Risk of Breaking Changes
As a new and evolving language, Scala has gone through some breaking changes a few times as new versions have been released. This has caused a lot of pain for some people, a number of whom have declared in their blog posts that this demonstrates that Scala is just an academic language and not ready for the real world. I believe that, while there still may be some changes to be made, with the release of version 2.8 the language has reached a level of stability that makes it suitable for production use.Risk of Abandonment
Scala is a relatively new language, and some people feel that it may not "make it" and survive as an ongoing language, in which case any code written in Scala would become hard to maintain. I believe this risk is now relatively small, given how it has been growing over the last few years and the number of big names who have adopted Scala (see the list below).Limited Documentation
While this may still be an issue for non-English teams, I believe there are now enough Scala books in English that this is no longer an issue for anyone who reads English. The Books on Scala page lists 19 books about Scala and Lift, including five Scala books in English and five in other languages (some of which are translations of the English versions) that are currently available.References
Web Sites using Scala
The Scala web site has a page on Scala in the Enterprise, last updated a couple of months ago (as of this posting), listing quite a few companies that are using Scala.Here are a few well-known web sites using Scala or Scala/Lift and some tech articles about them:
Other Posts
There are a fair number of posts listing technical pros and cons of Scala, or comparing Scala to various other languages such as Clojure or the others mentioned above, but it is more difficult to find commentary that is more specifically directed at the business or management questions. Below are links to some posts that, while often containing some technical content, also contain at least some more general comments. The posts are listed from newest to oldest.- A thread from September 2010 asking if there is a place for management to get support on Scala decisions.
- Some comments from August 2010 on looking for Scala developers (vs Java or Python).
- "Why is Scala so fashionable?" from July 2010 - mostly comments about the Scala technology, but a few others. David Pollack says Scala "lives up to its hype" and has a great community.
- "Why Scala" from May 2010, a 15 slide "Executive Overview", although the first half is all technical.
- "Is this the time to switch to scala?" from January 2010 - Geir Hedemarks blog entry in which he takes a step back and asks why a company might be asking if it is time to switch to Scala (as opposed to asking some other questions). (In July 2010 he accepted a job managing a group of Scala developers.)
- "Why Your Company Should Let You Use Scala at Work", January 2010 blog post by Graham Lea discussing switching from Java to Scala.
- "A Scala Success Story" from September 2009 about Capital IQ; mostly technical.
- "What is stopping you from switching (from Java) to Scala?", stackoverflow poll from September 2009.
- "Why should I switch to Scala?", August 2009 post with both technical and some business-related concerns.
Updated 2010-12-22: removed "Higher Performance" item per James Iry's comment, fixed Foursquare per harryh's comment.
25 comments:
Great post! Finally someone who can set things straight.
I think "high performance" should be dropped from this list for the same reason that you dropped JVM compatibility. Scala is fast compared to Ruby and Python, but not particularly fast compared to Java (in some cases faster, in some cases slower, but mostly a wash).
Related to Better Developers: most of the great developers I know definitely choose Scala over Java. I think starting a new project now with Java would be risky because of this as getting great developers willing to use Java in the future might be difficult.
Of course if you would want an army of not so productive developers that would be a different case and a risk on its own, but I hope that really isn't a real life case.
Great post!
Antti-Mattilla brings up an interesting point about elite java programmers. There's a good chance that, if not now, sometime in the future, they'll want to be doing Scala programming, and not java.
That could leave companies looking for top java guys in trouble if they havent switched to Scala.
On to your post:
I find the LOC discussion of Sala fascinating. In my time working on my Open Source Scala project, I've found that it does take me longer to type out each line of Scala compared to if I had done java. This is probably because Java has so much needless verbosity that doesn't require much thought.
So each line with scala is actually doing something significant, I need to give it more attention. However, the fact that my program is >3k LOC means I am never trying to remember what classes do what, or why a method works the way it does, or any of the other problems you have when working on an extremely large code base.
I'm not sure I'd be able to grok a 10k loc java project near as well as I do my Scala project, and I'm that much faster because of it.
From my experience, a developer spends less than 25% on writing code, if the code is substantial, the problem is moderate complex and he doesn't work on his ideas but implements business features.
A 90% reduction in writing LOCs will result in a 22.5% reduction in time.
Stephan
http://codemonkeyism.com
Gosu is a nice middle ground between Groovy and Scala:
http://gosu-lang.org
(Disclosure: I work on it.)
Cheers,
Carson
I'm a true Scala fan but I have sometimes worries about 2 fundamental things: the compiler speed and the number of generated class files.
My issue with that is about scalability. I'm working on a huge Java project at the moment. What would happen with Scala? Sure there should be less code. But at this scale, am I at risk of:
- having some tools choke up on the number of class files?
- having my developers sitting still while the compiler is doing its magic?
I'm pretty sure that we can come up with good engineering answers to those issues but, as a manager, I would like to have some proof of Scala "scalability" on a very large software project.
What do you think?
Very minor nit:
Foursquare or foursquare, but please never ever FourSquare.
-harryh, the guy who decided to use scala @ foursquare and considers it one of the better decions he's made at the company
James Iry: your comment is reasonable. I have removed "Higher Performance" from the "Pros" section and replaced it with a few words in my "I do not include" paragraph. For the record, here is the text that I removed:
+++
Higher Performance
As compared to other modern languages that are sometimes considered as replacements or extensions for Java, such as Groovy and Jython, Scala provides higher performance - on par with Java. For example, the Twitter back end runs on Scala, to which they switched from Ruby for performance reasons.
The Scala-based Lift web framework provides high performance for web applications, particularly at high-volume sites.
---
Eric: In comparing Scala to Java, David Pollack says he sees an 8x reduction in LOC but a similar number of class files, so I expect you are unlikely to run into problems due to number of class files. However, Scala does sometimes produce class files that contain constructs that Java class files don't typically contain, so I agree that you currently have a higher chance of running into tool problems developing in Scala as compared to Java. I consider this all part of the "Tool Immaturity" issue, which I expect will continue to improve relatively quickly.
harryh: Name and link corrected.
Thanks for this post; that's just the kind of info people need to make an informed decision.
I often hear people talk of the expressiveness of a language as being entirely about how long it takes to *write* code. In fact, you get odd comments like "yes, my Java code is 4 times bigger, but my IDE generated half of it, so who cares?"
Well, we *do* care. Writing code, I think we all know in our hearts by now, is a fraction of the total cost of software. We mustn't forget about the time it takes to review it and maintain it. If I remember correctly, studies in the 80s showed that maintenance accounted for something like 70% of the engineering effort on the code analyzed. Sure, it matters that you are writing 1/3 or 1/10 the code, but what matters much more is that maintainers only have to *read and understand* 1/3 to 1/10 the code.
We should also remember that the difficulty in understanding code does not rise linearly with the size of it. Humans have limited memory; it's probably more like nlogn. And beyond a certain size, you need to get multiple people involved, which introduces additional inefficiencies and opportunities for error.
And finally, remember the discovery about how code which fit on a page was found to be much less likely to have bugs than code that spanned pages -- humans do better when they see the Gestalt, rather than a window into something bigger.
For all these reasons, saying that the same functionality in Java would be 3x or 10x the size understates the importance of expressiveness in a language.
thadon: I am happy to have people add constructive and relevant comments to my blog, but when I followed your unannotated self-promoting link I was unable to find anything in the "Agenda" related to the focus of my blog post, which is specifically about the business management pros and cons of Scala and not about the technical details of the language.
You are welcome to repost a comment that furthers the discussion here, but if you post a link, please provide some indication in the comment as to why that link is relevant and what is to be found there that bears on the topic at hand.
I m a fresher in IT field.
I m familiar with java only.
I want to know whether I chose Java or Scala for further development..
I m about to start my work at some company.. In which lang I will get better future??
Expecting reply as soon as possible .Cuz I have to sign a bond with some company on this Monday.. :)
Thank U.
IMO, Scala is too "revolutionary" (see the cons) which is interesting but in order to convince business managers and make them WANT to use something else you would need something that's more "evolutionary".
You say that good Scala developers are rare and expensive, but that they are 10 times more productive compared with Java developers. And you say that Scala is some times hard to read (by non experienced developers). But what if you would simply use Python, which is a productive language that is easy to read and learn?
Python/Ruby/Groovy/etc. are indeed simpler languages than Scala and offer similar -- often even greater -- productivity gains than Scala for *writing* code. The fact that they all can take advantage of Java libraries (using JRuby/Jython) is a big help.
But you have to remember that there are significant costs to choosing such a language. They are untyped, which is usually a small loss for small projects, but can be a big loss for big projects. Testing becomes a much bigger burden, and even if you are extraordinarily disciplined about it, you will leave errors to be found in production. Refactoring is harder to do correctly. Performance is significantly worse. In some cases interoperability with Java is not as good.
Sure, there are some projects for which these things do not matter. But if you are talking about a language to take the place of Java in new development generally, they are deal-killers.
Scala appears to be the only contender that offers static typing (somewhat better than Java's, in fact), high interoperability with Java, roughly equal performance, *and* much better usability. In addition, it offers a great many other useful features.
There is certainly a learning curve to writing idiomatic Scala code. But I think the formula of using Scala as a better Java and slowly mixing in functional features is a good one. Furthermore, if you need to do anything concurrent, Scala will give you a significant leg up.
@wariock: Currently there are few jobs in Scala; Java will pay the bills better for the time being. Yes, it is now quite clear that Java is showing its age. What is keeping it going is momentum: existing code, trained developers, etc. Eventually either Scala or another language will reach a level of acceptance that makes it the preferred choice for new development, but that won't be for a while, and in any case you'll still be able to do maintenance work in Java for decades.
i think the previous comment completes the picture, cause it's not only java or scala but jruby,groovy,clojure,etc (although you have eliminated them for some reason)
I agree type system is the major advantage of scala (more than continuations f.e.), *if* you want/need/are-acostumed-to a static type checking.
But the other edge is the complexity of being a master in typing scala to use all its possibilities (type classes,monads, applicatives, etc). You have to add that to the learning curve to write idiomatic scala.
While Accenture currently has a small (but growing) number of Scala qualified people, we are actively working to develop our Scala capabilities in terms of development aids, reusable components, estimating guidelines, and training. For small to medium projects, I believe Scala is right now a great alternative to Java for higher productivity and agility, without compromising on performance and compatibility. For the large, complex business systems we typically build, I see Scala as an important adjunct to Java but not as a replacement (at least in the near term). I see great potential in the use of Scala for building selected portions of large Java applications, for example: high-productivity development of quality-critical complex business logic (statically-typed functional programming), high-performance concurrent processing (actors), architecture components and frameworks in general, domain-specific languages for application configuration/customization, and maybe even user interface development. Thus, a large project can significantly benefit from Scala with a relatively small number of Scala developers working in conjunction with a larger Java team.
Paulo Villela
Accenture Architecture Innovation
Please do not argue with LOCs - don't be so stupid and, as a Scala novice, tell proudly that you do not need to type semicolons with Scala, etc.
This has nothing to do with developer's productivity. Indeed, the redundant syntax monster's you have with Java generics are annoying; whereas those getter- and setter-methods, well, leave them to your IDE.
On the other side: compactness of code is not per se more productive. As anyone with, say, C experiences knows: this was an argument in older days. And then came the Java folks claiming that more comprehensibility of code (for readers!) is gained through more verbosity. And - that's right! To much compactness leads to fewer understandability. Well, and I saw a lot of code in Scala - which is compact, but lacks of clearness.
So, all I want to say: forget LOC as quality argument.
BTW: did anyone of you Scala disciples realize, that Scala designers came back to very well known language featues of C++ - which the Java guys skipped, because they seemed dangerous?
@Nicholas: Static typing or not, on a large project you need real unit testing. Having static typing in no way reduces that. I am part of a large team developing a Common Lisp program that is now about 700KLOC. Dynamic typing has advantages and drawbacks, but its drawbacks are not a significant problem for us.
Followon: But a language with good type inference, such as Haskell has, takes away the major drawbacks of static typing. I don't know Scala well but I gather it has the same advantages, and I think that provides the best of both worlds.
Thanks. This is great. got some additional stuff here as well: http://www.kammerath.co.uk/The-Joys-of-functional-programming-in-Scala.html ... Pretty much interested in how Scala develops.
Post a Comment