
Will Scala ever be enterprise-ready? - cryptos
http://alblue.bandlem.com/2013/08/will-scala-ever-be-enterprise-ready.html
======
adriaanm
Smooth upgrades between major Scala releases is one of our[1] two top
priorities (the other being compiler performance). I disagree that "nothing"
has happened since 2.8 to improve Scala's enterprise readiness (the Scala team
at Typesafe does just that).

Binary compatibility is one (desirable) way of making upgrades smoother (but
certainly no panacea). We haven't reached the point yet where we're willing to
freeze the whole library across major releases, but we're working towards
this. In Scala 2.11.x, we've slimmed down the library (by deprecating more
aggressively and modularizing), so as to reduce the core to something that
we're comfortable enforcing binary compatibility for.

In the mean time, we're working on mitigating the upgrade pain with tooling
and "community outreach". We're working with the developers of core Scala
projects to assist them in cross-building their projects, and we're investing
in tooling to automate this. With every 2.11 milestone we're working to get
the eco-system in shape for the final 2.11.0 release, so that your
dependencies will be available when you upgrade.

We're also working on gaining engineering experience in enforcing full
backwards and forwards binary compatible, albeit only between minor releases
of Scala 2.10.x (enforced with [https://github.com/typesafehub/migration-
manager](https://github.com/typesafehub/migration-manager)). This means code
compiled against Scala 2.10.x is guaranteed to run on a Scala 2.10.y run time
(you're free to pick x -- a different one for each dependency, even -- and y).
Scala 2.10 gets a bugfix release every 3 months, and a lot of the features
we're developing for 2.11 (as modules) will be available for 2.10 as well.

Happy to hear your thoughts and experiences in upgrading! Several of our
clients and other big Scala users have reported successful upgrades from 2.9
to 2.10, though others are still happily running on 2.9. Doesn't that make us
_more_ enterprisey?

[1] I'm the Scala tech lead at Typesafe.

------
ssmoot
> most of these people have not gone through a Scala version switch, or seen
> the pain that it can cause, or extrapolated that out thinking what it will
> do for future releases.

Seriously oversold.

I have been through the 2.9 to 2.10 switch. Anyone's who's used Play over the
past year has also (maybe unknowingly) been through that switch since the Play
plugin was using SBT 0.12.x (and Scala 2.9.x) even if your code was compiled
under Scala 2.10.x.

It was practically painless.

The worst that happens in reality is you have to wait a couple extra months
for someone to release a new build of something you depend on (or heaven
forbid, clone the source and build it yourself).

Contrast that with waiting years between stable releases and new features with
some other popular languages.

I'll take Scala any day. It remind me a lot of the early c# days. And that's a
good thing when it comes to really building up a language and what you can do
with it.

~~~
harryh
I think your feelings on this depend on the size of your codebase/team. For a
smallish project it's no big deal. For something large upgrading can be a
significant effort.

Foursquare is still on 2.9.2. We hope to move to 2.10 fairly soon but it's by
no means painless.

~~~
ssmoot
Fair enough.

But "fairly soon"? 2.10 hasn't even been out a year! Think about that. It's
pretty cool IMO. I mean, Scala's community at-large does in months what takes
Ruby's years. And with _fewer_ breaking changes, with better tooling to help
you make the transition. That's really refreshing.

------
pron
Other than the community and leadership issues mentioned in the article, Scala
will never be enterprise ready because I can't think of a worse language for
the enterprise. Large IT departments working on multi-MLOC codebases need a
solid, clear language. Scala was promising back when it was meant to be "a
better Java". And you know why people liked it? Mostly because it had lambdas
and traits - two features that are in Java 8.

Since then, Scala has become a sort of a testbed for new ideas in compiler
technology. Consider this – it's basically got three complete type systems: an
OO, inheritance based type system, a Haskell-like algebraic type system
(sealed traits and case classes), and a duck-typed type system (structural
types). Each of these type systems has been enough to write good, complex
software, on each own. Scala's got all three, while at the same time missing
on all of their advantages. It doesn't have Haskell's type safety and purity
(or type inference). It doesn't have OO's simple, highly extensible, and just-
powerful-enough type system, because it's so big and complicated, and it
doesn't have duck-typing's care-freedom, because it's so heavy. Oh, and it's
got macros, too, just for the heck of it.

I know some people like it because they have fun writing lisp, Haskell, Java
and JavaScript in the same file and have it compiled by just one compiler.
Yeah, it's a cool compiler. But seriously, it doesn't offer anything
enterprise would want. It doesn't offer safety; it doesn't offer simplicity;
it doesn't offer familiarity. It doesn't even offer much compatibility: it's
much harder to integrate Java with Scala than with Clojure or Groovy, let
alone Kotlin.

And I'm willing to bet that almost all large companies that currently employ
Scala, do it because of its original promise of being a better Java. But if
you're a superset of about 4 language families, than you clearly can't a
better Java.

For those who want that productivity boost while maintaining familiarity and
compatibility, there's Kotlin. And Java 8, of course.

~~~
runT1ME
>And you know why people liked it? Mostly because it had lambdas and traits -
two features that are in Java 8.

I don't think this is the main reason people like it. Java's lambdas are also
inferior to Scala's.

>a Haskell-like algebraic type system (sealed traits and case classes)

What do case classes and traits have to do with _types_?

>It doesn't have Haskell's type safety

How so? Can you explain how you think Scala isn't sound/typesafe?

>It doesn't have OO's simple, highly extensible, and just-powerful-enough type
system

Uhm, can you explain to me an example of a simple OO type system that is 'just
powerful enough'? Because most of the ones I know of are broken, and Scala
easily has the best OO type system. C#, java, Go, etc. are all either missing
generics (lolwut) or completely fucked up variance.

~~~
pron
> How so? Can you explain how you think Scala isn't sound/typesafe?

Because you can do casts, and it's not pure. It doesn't even enforce
immutability. You know what? Forget about enforcing – it doesn't even make
mutability or casts hard. Look, Haskell is certainly not my cup of tea.
Personally, I don't think the effort of thinking about my program twice (once
in terms of logic and once in terms of types) is worth it in most
circumstances, and pure functional languages don't support concurrent data
structures which is what I deal with the most. But I do recognize Haskell's
elegance, and if the elaborate type system is worth it, it's only because it
can enforce many guarantees. I mean, the whole point of Haskell is that it
supposedly makes safer programs. So you pay for the elaborate types (though
some consider it a plus), but you gain safety. With Scala you just pay.

> Uhm, can you explain to me an example of a simple OO type system that is
> 'just powerful enough'?

Sure. C++, Java, C#. Almost all of the world's software is written in C++ or
Java. The question is not which language has "the best type system" (and even
if it were, Scala can't make up its mind because it's got three of them). A
type system is not an end but a means. Practically everyone who deals with
type systems agrees that they come at a cost (and Martin Odersky himself
admitted as much). But the cost hopefully buys you something. It arguably buys
you better design, and it definitely buys you safety. Well, Scala doesn't give
you safety any more than C++ or Java, and as for design, it can't even pick
one type system; a cornerstone of great design is that you have to make hard
choices.

~~~
runT1ME
>pure functional languages don't support concurrent data structures which is
what I deal with the most

This is false, you were misinformed.

>Sure. C++, Java, C#.

C++ Has a good type system, IMO. The other two are _broken_. Literally, you
can write broken code. Scala has a long list of warts, I just don't think
you're listing any of them.

>Well, Scala doesn't give you safety any more than C++ or Java, and as for
design, it can't even pick one type system; a cornerstone of great design is
that you have to make hard choices.

This is just FUD. Are you telling me Java/C#'s type systems enforce more
safety than Scala? Because they don't. They don't get variance right. Do you
know what variance is? You ignored that part of my comment.

~~~
pron
> This is false, you were misinformed.

If I'm wrong, I apologize. I am not familiar with any concurrent data
structures in a pure functional language, but I'd love to learn of any. I have
not encountered a data structure in a functional language that supports more
than one concurrent writer (and I don't mean parallel construction of an
immutable DS - that's trivial – but concurrent mutation, like in a concurrent
B-Tree, concurrent skip-list, or concurrent hash map).

~~~
codygman
I haven't checked anymore than glancing through the slides but it has the
words "concurrent data structures in haskell" at the beginning:

[http://www.scribd.com/doc/28336206/Multicore-programming-
in-...](http://www.scribd.com/doc/28336206/Multicore-programming-in-Haskell)

~~~
pron
You are right! Didn't know about MVars. Got some learnin' to do now...

------
modersky
The blog post and question is somewhat inflammatory (no wonder it gets upvoted
so readily). Scala has been in category "adopt" in Thoughtworks Radar for a
while now.

[http://www.thoughtworks.com/radar](http://www.thoughtworks.com/radar)

It's not only Enterprise ready, but is in production in a large number of
enterprises in many different sectors.

~~~
alblue
It's not inflammatory for the sake of it; the point is I wrote about this four
years ago:

[http://alblue.bandlem.com/2009/10/scala-is-still-not-
enterpr...](http://alblue.bandlem.com/2009/10/scala-is-still-not-enterprise-
ready.html)

and there has been very little change since that 2009 post and the 2013 post
to show any kind of serious movements on these issues. For single teams based
on small projects the ability to up and move all your tools (IDEs, build
train, library dependencies) really isn't a problem; but if you're dealing
with hundreds or thousands of users and tens of thousands of libraries, you
simply can't do an all-in-one upgrade.

And no, 2.10.x and 2.10.y being compatible isn't something to crow about; it
should have been the default. The fact that you can't compile or test code in
Eclipse with the Typesafe developed Scala IDE plugin for anything other than
that exact version is one reason why developers are moving to IntelliJ's Scala
development tools.

Ironically the problem is that the Scala IDE is written in Scala, whereas the
IntelliJ tool is written in Kotlin, and Kotlin doesn't have compatibility
problems (plus, it shells out to the specific compiler instead of Eclipse's
Scala tools which embed their own).

Yes, teams at the Guardian are using Scala - but only in teams of less than
ten people, and where they don't need to share libraries across multiple users
and clients. That still doesn't make it enterprise ready.

Sadly I feel that Rod Johnson's keynote presentation at ScalaDays - which
pointed out the same things as this post, and was the trigger - is being
ignored. Unfortunately Typesafe are also ignoring this advice, and until that
changes we won't see Scala being adopted in large enterprises.

Scala had a chance back in the late 2000s to be the next Java. Now - even with
Java 8 having been delayed so much - it's probably too little, too late.

~~~
eeperson
From the article:

> This self-limiting process means that Scala will never truly die out; at any
> point, there are still more people who are new to Scala than people who have
> been burnt by it, so there’s always a fresh supply of people willing to
> believe that it can’t happen to them. The same is true of smokers, of
> course.

If that's not inflammatory for the sake of it I don't know what is.

> And no, 2.10.x and 2.10.y being compatible isn't something to crow about; it
> should have been the default.

The moving of the of the goalposts isn't helping your case that your not being
inflammatory for the sake of it.

Few people are going to state that Scala doesn't have any problems. However,
if you want to raise issues about the language, at least argue fairly and
don't insult the users and developers of said language in the process.

~~~
alblue
I spent a long time trying to get the issue raised back in 2009.

[http://alblue.bandlem.com/2009/08/modularity-for-
scala.html](http://alblue.bandlem.com/2009/08/modularity-for-scala.html)
[http://alblue.bandlem.com/2009/09/draft-scala-modularity-
req...](http://alblue.bandlem.com/2009/09/draft-scala-modularity-
requirements.html)

Key to both of these was 'real' backward compatibility (i.e. the compatibility
between versions like 2.8 and 2.9, not the patch level compatibility that
exists at the moment).

I'm not moving the goalposts here; the issue is that having 2.8.x compatible
with 2.9.y (or 2.9.x with 2.10.y etc) is a key point where Scala has failed,
and continues to fail.

Until this is fixed, Scala won't be enterprise ready.

Rod's point (from his Scala days keynote) is that in 5 years Scala has a
chance of being 'the' language, but only if it gets the backward compatibility
issues sorted between 2.x and 2.x+1.

My point was I made exactly the same argument almost 5 years ago and nothing
has changed, and since the past is the best predictor of future performance it
is a safe bet that in 5 years time Scala won't have solved that problem, and
thus won't be applicable for large enterprises.

This isn't a rant against users of Scala, it's a critique of the development
plans that doesn't see this is a problem, or is happy to use Scala as an
experimental playground that isn't likely to get widespread usage in
enterprise.

If you can fit all your organisation's development teams in a single
conference room, these problems are never going to apply to you, since you can
just mandate that everyone switches at a particular date. But for
organisations with hundreds or thousands of developers such an all-in-one
switch isn't feasible.

------
ffk
I think this is the wrong question to ask. It's clearly enterprise ready
considering enterprises are actively using it in their _critical_
infrastructure. A better question is "Will scala ever have major release
backwards compatibility as a feature."

This isn't to discredit the author's viewpoint. I strongly agree with many of
the assertions he makes. Backwards compatibility is a major problem.

Back to backwards compatibility (wee, puns), I think a major part of it is not
due to ABI changes. The JVM has very well defined entry and exit points to
deal with this. The problem seems to stem more with the libraries. As long as
the libraries keep changing at a fast rate, the scala cmomunity will never
achieve backwards compatibility at the level this author wants to achieve.
Until typesafe makes a strong commitment to put APIs through a sunsetting
lifecycle with deprecation, it will continue to be a problem.

Fortunately, they have made a commitment to not make breaking changes in minor
releases. E.g. 2.10.0 compiled applications should continue to work with all
release 2.10.* runtimes.

------
dman
As a former lisper I cant but help feel that haskell and scala are the modern
lisps. In 10 years all industrial languages will be undeniably influenced by
these pioneers but the languages itself wont be the next big thing.

~~~
ssmoot
Maybe. But it feels like Functional programming at least is a thing now. I
can't see the next decade's language remaining an imperative bog...

I cringed at seeing the following Ruby today:

    
    
      "error#{'s' if errors.size > 1}"
    

:-)

~~~
codygman
Did you start that paragraph with a "Maybe" on purpose? lol

------
ExpiredLink
Odersky is already working on a Scala successor:
[http://www.infoq.com/presentations/data-types-
issues](http://www.infoq.com/presentations/data-types-issues)

~~~
eeperson
That isn't intended to be a Scala successor. That is intended to be integrated
in future versions of Scala.

~~~
auggierose
lol :-) Sums up what the whole fuss is about.

Scala is a great language. It gives me OO + functional in one great package
that has no equal out there. Couldn't do without it.

------
dxbydt
Will Scala ever be enterprise-ready? I don't know. Will enterprise ever be
Scala-ready ? No.

And I'm not being flippant here.

------
manishsharan
For Scala to gain any traction with the enterprise market, it will need strong
backing from enterprise middleware vendors. If IBM, HP, Oracle , RedHat and
VMWare start shipping IDEs and libraries compatible with Scala and start
pushing Scala over Java, only then would the development managers in large
enterprises would give Scala a fair shake. And that is unlikely to happen as
these vendors have made huge investments in Java that they are not going to
cannibalize.

Until then it Java or C# only for the enterprise s/w development; the silver
lining is that Java 8 is a significant improvement.

On a personal note, as a java programmer I do not find Scala worth the
learning curve. I am into Clojure for my personal/ hobby/ bootstrap
programming because it forces me to think differently about programming and I
enjoy that.

------
saosebastiao
I'd add one thing to the list of requirements before it is enterprise-ready:
faster compile times.

~~~
lmm
You're right, C++ will never be enterprise-ready.

(Scala could indeed really do with faster compiles, but I think that's
actually _less_ of a problem for enterprises than it is for the agile startup
world)

~~~
seanmcdirmid
A lot of money has been invested in infrastructure to deal with C++ slow
compiles and make it more feasible; Google for example has some amazing build
reuse and caching tech. There are many other ways of dealing with slow
compiles vs. just making compiles go faster; e.g. you could make them more
incremental (which is also useful for IDE use).

~~~
lmm
Scala already has some very good incremental compilation tech, built into its
IDE support. For day-to-day coding the compile times aren't an issue (though
they can become one if you like to e.g. make releases frequently).

~~~
bcbrown
Ugh, ever since we added scala to our projects, the compile-time has doubled.
It's certainly an issue to me. It makes it harder to get into flow when I have
to wait several minutes for compilation.

~~~
lmm
For day-to-day coding where you need that flow you should be using an IDE with
incremental compilation. Full compiles are for releases or the like.

------
lmm
Most of the "enterprises" I know are still on Java 6. So clearly the need for
a "big-bang" migration is not enough to turn enterprises off a language.

To talk about minor version numbers is to miss the point, I think. Scala 2.10
brought more new features than java 7, and scala 2.11 will bring more new
features than java 8. It's just happening faster.

~~~
laureny
That's part of the problem: Scala needs fewer features and more focus in other
areas, such as tool support (IDE's mostly) and backward compatibility.

The problem is that Scala's leadership is conflicted: you have Typesafe trying
to turn it into a product and the researchers inside Typesafe more focused on
producing papers for their academic careers, and therefore steering the boat
in a direction that conflicts with pleasing new users.

~~~
eeperson
Why do you think that those doing research inside Typesafe are steering the
language in a direction that is user hostile? From what I have seen the effort
appears to be more focused on simplifying the language in order to make it
easier to use: [http://www.infoq.com/presentations/data-types-
issues](http://www.infoq.com/presentations/data-types-issues)

~~~
laureny
> Why do you think that those doing research inside Typesafe are steering the
> language in a direction that is user hostile?

Macros come to mind. It's a feature that completely circumvented the SIP (and
was later retrofitted into it), which is still heavily controversial inside
scala-internals to the point that we're still not sure whether they will ever
be officially part of scalac and which will probably never be used by more
than a very tiny minority of Scala users.

They took months of work (which could have been put to better use, e.g. IDE
support), mostly done with little transparency and which started generating
papers for conferences before the project was remotely close to a prototype.

This kind of project would never have seen the light of day if the language
was led by a company focused primarily on users and sound engineering.

~~~
modersky
Macros were not done at Typesafe, but by Eugene Burmako, who's a grad student
at EPFL. Grad students do new stuff, and they publish about it, IDE
improvements are typically not their piece of cake (Typesafe does have a very
capable team working on IDEs).

As you imply, macros are labelled experimental, which means that you have to
enable them explicitly. Having experimental features is Scala's way of
reconciling a vibrant open source community with the stability needed for
enterprise use. Needless to say, we do not recommend use of experimental
features in enterprises. They are good for playing around with interesting new
concepts and sometimes they do lead to something which is a win, such as the
beautiful async/await library that will ship in 2.11.

------
jemeshsu
Scala will be enterprise-ready when there are readily available affordable
Scala programmers.

If you can master Scala and write complex Scala codes, most likely enterprise
crud jobs does not interest you.

------
samlavery
Scala is a fine scotch, but at a very young age. It's version 2.10.3,
everything is still changing fairly rapidly. All it needs to be adopted in a
more widespread manner is to improve it's approachability. Even for engineers
who've been programming for years, Scala is hard to grok. The vast deviations
in style don't help.

I'm betting it's going to take over the world in a few years, especially as it
expands it foothold in the Big Data space.

------
wheaties
I think a lot of what people were ruffled about was his remarks about
reinventing the wheel. There are preferred ways of writing code in all
languages, some more extreme than others. However, while Scala is backwards
compatible with Java, it's not always as nice to use a library which is firmly
rooted in Java.

------
_no__
Not until Set is not a Functor

~~~
gclaramunt
To be pedantic, you mean Set to not implement map, right?

------
voidlogic
Enterprise ready is such a useless term because the readiness is dependent on
the particular enterprise asking the question.

For some enterprises Scala or even Go are "enterprise ready", for others, it
will be decades.

------
kailuowang
Scala has the potential to become an enterprise useful language because people
can write a simple script to monitor how many mutable states appears in the
codebase.

------
nonchalance
Does scala follow semantic versioning? It sounds like they should still be in
the 0.x stage if there are enough breaking changes to merit this discussion

~~~
ssmoot
Yes it does. AFAICT it's working well. There are 5 releases in the 2.10.x line
and I haven't had a compatibility issue between any of them.

The deal is (I think) that Scala is a much quicker evolving language than say
Ruby. Ruby 2.0 was rumored to be released the better part of a decade ago
(anyone else remember Pickaxe 1.8, pre-Rails, saying that eventually
parenthesis would no longer be optional in Ruby 2.0?).

Scala has developed new features at a pretty quick pace. By and large this
doesn't mean breaking source compatibility. Most source seems to be forwards
compatible, or require minimal effort.

The reason this comes up at all is because of Package Management. Where Ruby
only needs to worry about a parser compatibility level, Scala has to worry
about binary compatibility in packaging since it lives in Java's packaging
ecosystem. Since Maven doesn't encode a binary version, breaking binary
compatibility (say you added a new default argument to a method signature,
that wouldn't otherwise break source compatibility, or you introduced a new
superclass for a return value) means breaking your packages.

SBT gets around this by encoding the binary version (the Scala minor version)
in the artifact name.

Some day this will all probably get sorted out.

It hasn't been much of a pain point for me personally. Most 3rd party binary
packages are Java packages, which are binary compatible since Java 5(?). For
the few Scala libs you might depend on, you might as likely be using a source
dependency from Github, which means you don't need to worry since you're
compiling it yourself, or most popular packages will have published versions
with a new compiler pretty quickly.

The next time this will be an issue is when Scala 2.11.0 is released. And
AFAIK that should introduce any breaking changes for source code at this
point. So if you want to move to Scala 2.11.0 you either wait for package
authors to cross-compile to it, or you build it yourself as a source
dependency if you have access to the code.

~~~
alblue
Just FYI; semantic versioning is split into three numbers:

major.minor.micro

Changes in .micro are assumed to be interchangeable. Scala does this.

Changes in .minor are assumed to be backwardly compatible, but with new
features added. Scala does not do this, it requires a recompile.

Major versions indicate a completely incompatible change.

If Scala were to follow semantic versioning, it would need to coalesce the
first two versions together and have e.g. 210 and 211 to indicate that they
are not compatible with each other.

~~~
ssmoot
.minor: Scala does this at a Source level IME.

Which depending on your background may mean everything or nothing at all I
guess.

Most Ruby libs would claim to follow semantic versioning. I think it's also
fair to say there are a lot more mis-steps with compatibility on that side of
the fence but I've not seen this argument used there that I can recall.

I mean, to be fair, your argument was "large enterprises". Which, means Java.
And in that regard you're not wrong since binary compatibility there is a
given.

Still... As long as you can clone and build the source (it's not like you're
buying licenses for UI binary libraries built in Scala after all) I fail to
understand why this is a bigger deal than say: String interpolation. Partial
Functions. Function Lifting. Type Inference. Type Classes. Tuples. Pattern
Matching. The list just goes on and on...

The question isn't "Is Scala ready to be the basis for closed source, licensed
libraries" after all? If it were then a "we must maintain a decade of binary
compatibility" might have a point. Otherwise it feels like a really hollow
criticism. I mean, what actual Scala _users_ out there actually want to see
Scala 2.11's features put to death on the altar of binary compatibility?

~~~
alblue
> I mean, to be fair, your argument was "large enterprises". > Which, means
> Java. And in that regard you're not wrong since > binary compatibility there
> is a given.

Exactly, and that's what Scala is up against. Java 8 will allow Java 7
compiled libraries to run without changes, and though there's a world of
difference between Java 8 and Scala, in practice Java 8 gives developers some
new features that they'll find useful and more performant than Scala (parallel
collections, no implicit casting/conversions etc.)

It's also worth noting that 'backwardly compatible' and 'new features' aren't
in conflict with each other. Java has had new features added (invokedynamic at
the JVM, try-with-resources and string switch in the language layer) but
they've still remained binary compatible. The problem is that Scala's approach
to new features is to break binary compatibility between 2.x and 2.x+1
releases.

------
stormcrowsx
Pretty sure its already in enterprises, perhaps the more cutting edge ones but
nonetheless it powers some very large websites.

------
AlexanderDhoore
I wonder how the JVM will compare to .NET in 10 years time.

~~~
adamnemecek
They will both become just compatibility layers implemented on top of node.js.

/s

~~~
_random_
...because single thread is enough for any task!

------
volune
Twitter thinks so...

------
brucefancher
No. Next question.

