Now that I've done a few trivial things with Scala (which I love for "hello world" and contrived applications!) I am left wondering.. part about maturity of the tools to support development, and part about general applicability. Are the toolsets ready? Is Scala appropriate for use on enterprise / business applications? Would "you" use it on a non-trivial project?

Some of my (possibly unfounded) concerns would be:

  • are the IDE and toolsets as rich as what we have to develop .net and java applications (eclipse for Scala seems limited compared to eclipse for java)?
  • are the build / CI / testing toolsets able to effectively deal with Scala?
  • how maintainable is the concise code that can be (encouraged?) written in the language?
  • is it possible to find developers with Scala experience?
  • is there enough critical mass to get help through on-line reference and books that are more than "intro" to the language?

So bottom line - is the ecosystem mature enough to use now, or better off waiting to see how it evolves?

EDIT: let's say "non-trivial" is a multi-year, multi-release, 10-20 developers project.

  • 7
    If you have to ask... :) May 19, 2011 at 1:23
  • There's a lot of space between non-trivial and enterprise. I'm not sure how large a project you are interested in. May 19, 2011 at 1:24
  • Great point @FarmBoy, updated.
    – jayraynet
    May 19, 2011 at 1:39
  • @Scott Witlock: yeah, you are probably correct =)
    – jayraynet
    May 19, 2011 at 1:41
  • Scala aint Pythonic, but Clojure is. Enough said.
    – Job
    May 19, 2011 at 2:56

8 Answers 8


While it is true that Scala has been used in the wild at the Guardian and at Twitter, there is one fundamental concern.

Much of Java's popularity comes from the fact that it is relatively easy to read and maintain. Scala has an problem here as it can be written in many different styles. OO style vs functional style is the obvious split here, but it gets more complicated when you talk about the 3 levels of Scala.

You need to make sure that your team and any potential new hires can all follow the same style, and that the style is simple enough for you to actually be able to hire developers that can be effective (not everyone can hire the top 2%).

Tooling support is also not quite there yet, although I expect this gap to be closed fairly quickly. You can also get support for the full Scala stack from the TypeSafe crowd. I think Scala will carve out its niche, but until the levels are actually built into the language/compiler/whatever, I see a maintenance headache coming down on teams after the initial 1-2 years of excited productivity.

See this related answer for more details.

  • does this problem happen in other multi paradigm languages or is it more specific of Scala?
    – DPM
    Nov 2, 2013 at 21:20
  • 2
    More specific of Scala because crucially some of the added language features weren't seamlessly integrated with some of the other language features, one of the reasons for its "Kitchen Sink" reputation. Nov 3, 2013 at 14:23

Scala is currently used by Twitter, and by The Gaurdian, so it's certainly ready for non-trivial applications.

Scala programmers are going to be very motivated, and likely very good. Choosing a new language is a great way to attract talent.

Of course, Scala programmers will often not have professional Scala experience, and there may be some variety in the idioms that they use. Some may strive for Haskell-like purity, while others may view it as Java with closures. So it will probably take some time to develop consistent coding standards and conventions.

Many Java tools will work well, though IntelliJ Idea will probably be worth the investment over Eclipse.

Overall, it could be a good choice if you have control over the project. If this is part of a large insurance company, you may run into issues if there are architectural guidelines like: 'All projects are to be built by Maven and deployed in WebSphere.' (I have no reason to think this particular rule would be a problem, but a proliferation of such rules could trip you at some point.)

  • What do Twitter do with Scala?
    – Anto
    May 19, 2011 at 6:24
  • 1
    @Anto see for example infoq.com/interviews/kallen-scala-twitter
    – Jesper
    May 19, 2011 at 9:01
  • 10
    I wouldn't trust twitter's engineering decisions as being evidence for maturity & robustness.
    – red-dirt
    May 20, 2011 at 11:31

My impression is, that much of the eco-system that comes with "conventional" languages (as Java) is intended to make up for their clumsiness.

The question is not, how many tools there are for a given language (Scala), but whether the existing tools for that language are better than the existing tools for the reference language (Java). Because 100 mediocre tools won't give you, what one good tool can give you. And a thing you should not forget is, that the language itself is part of those tools.

The declarativeness of a language

  • is inversely proportional to the amount and severeness of the bugs you produce with it, which is why Java is so great at producing bugs and you need a lot of tools to avoid and track them
  • is proportional to your productivity, which is why Java is so extremely verbose and you need a lot of code generators and similar tools

For example, I once read a horrible blog post by a Ruby guy, who argued static typing is pointless, because your tests will cover type safety. This clearly came from someone, who hadn't yet worked with an expressive static type system. Assuming I can represent all type relationships in a language semantics and it's not much work to do (and it isn't, since most modern languages support type inference), I get all this for free.

To push one thought a little more forward: Unit tests ensure, that a unit acts as specified, or to rephrase it, unit test are runnable specifications. However through declarative programming, units themselves are runnable specifications. Again, you get something for free.

What I am trying to say is, that you shouldn't underestimate what language features can do for you. And unless you really try them in the field, you will never understand.

So to come back to the original question: Are the existing tools for Scala better than for Java? Hard to say. Depends on what you want to do. I think we'd all agree the language is significantly better, now the question is, how good an ecosystem you will find in your business area.
For the web, Lift really is a solid option to go with. Don't know about desktop or mobile.


let's say "non-trivial" is a multi-year, multi-release, 10-20 developers project.

That's a lot of risks. The rewards would have to be worth it. In the world of enterprise business apps and mid to large size project, risk taking is usually limited. Or rather there is already enough risk to deal with... Predictability is more important.

I doubt that adoption will work that way.

It's more likely to start as a handful of people working on a part where the risk is contained such as POC, non critical components, testing, or parts where the problem just seems to be addressed much better by Scala than alternatives (maybe if something involves actor for instance) ... Then as tools mature, community grows, know-how grow in the company, then it could expand.


By leveraging the Java runtime, Scala is certainly ready for prime time. If you can deploy a Scala application, once the bytecode is generated, it should always work with that particular version of the Java runtime. The Scala based library will work like any other Java third-party library that you are familiar with.

In terms of IDEs, build tools and everything else, Scala doesn't have the same level of proliferation that Java has. So you don't have many Scala based frameworks or Scala based tools. That has more to say with Java's popularity than it does with Scala's growing popularity. Scala has functional tools include the Scala IDE and sbt, build tool. But they aren't nearly as a sophisticated as some of the other pure Java helper tools out there.


Cherry-picking points from @huynhjl and @FarmBoy:

  • Finding a large enough number of experienced Scala programmers could be difficult.

  • The "best practice" dogma for Scala is still evolving (*).

  • Style guides, conventions, etc are still evolving (*).

  • Tool support is still evolving (*).

Pulling these together, maybe a better question for you to ask (yourself / selves) is whether your organization is ready to use Scala on a "non-trivial" project? Do you have the people who can cope with doing a big project with so many things "still evolving"? Conversely, would it be better to do a smaller project first?

(* In fact, most languages are still evolving in one or more of these respects. The issue here is the rate of change / flux ... and whether your team can cope with it.)

  • 1
    The 'large enough number' of Scala developers will be a lot smaller than the 'large enough number' of Java developers. Jun 2, 2011 at 4:42

David Pollak over at Good Stuff has an excellent blog post entitled Functional Languages will Rule (but not this year) that goes into the nitty gritty of functional languages in general, and Scala in detail that I highly recommend reading to better understand if Scala is ready for prime time.


I never understood the distinction between enterprise and non enterprise programs.

I use the very same programs on work as at home. I wouldn't use a mediocre program in my spare time - why should I?

What is a non-professional program? I have seen poor applications been used, because the user didn't know better, because of compatibility issues, or the user refused to lern something new.

But it's a problem of outdated software, and of goals, the developer had in mind - not of the language, the program was written in. If you start thinking, in which language a program is written, it's already over: fail.

Enterprise-application is a marekting term, which isn't useful for serious discussion.

And which customer knows in which language you've done your job? Sometimes they care, sometimes they don't.

You might have questions which are related to the maturity of a language - but you can't answer the question for all kinds of enterprises and all applications.

  • 1
    Enterprise is much more than a marketing term... It basically means the company we're buying this tool from is going to be around at least as long as we are, and has the resources to back it up. You can substitute open source organization for company above.... In the end, there's a big difference between choosing a language mainly being driven by one person, vs. a small team vs. a huge open source foundation vs. a Fortune 100 tech company.
    – red-dirt
    May 20, 2011 at 11:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.