Is Scala ready for prime time?

Question

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.

Answer 1

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.

Answer 2

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.)

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.)

Answer 7

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.

Answer 8

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.