
Why Learn Scala in 2013? - Garbage
http://blog.typesafe.com/why-learn-scala
======
jballanc
When I first encountered Scala, my impression was that _this_ would be Java
2.0. Two plus years later, that's still my impression. What this means to me
is that if you are looking for a new work-a-day language (i.e. the language
that you use to pay the bills; the ones that appear in the Tiobe top 25), then
Scala is probably worth a look.

However, if you are happy with your current working language and are, instead,
looking for a language that will let you grow as a programmer...well, for that
sort of approach I'm not so sure Scala is the best you can do. This is just
anecdotal, but I've noticed a trend where someone does something cool in
Haskell, and then says "oh yeah, and with a few adjustments and given a couple
of caveats, you can do it in Scala like so...". In other words, it seems to me
that more of the innovation is happening in other languages and then its being
brought _back_ into Scala as almost an afterthought.

I have seen some hints that this is changing, and so I definitely won't write-
off Scala. At the same time, there are an _awful_ lot of interesting languages
out there if you're looking to grow as a programmer...

~~~
cageface
I like Scala and didn't personally find it that hard to start using it but I'm
not optimistic about its future as a mainstream alternative to Java. It's just
too big and complex and (apparently) too GC heavy to be useful on what is
quickly becoming one of the most important Java environments (Android).

My money is on Jetbrains' Kotlin as a significant but manageable step forward
from Java. Given its pedigree I expect it to have tooling support that no
other JVM language can match.

<http://kotlin.jetbrains.org/>

~~~
vorg
Part of Kotlin's pedigree are some ex-developers of Groovy, i.e. James
Strachan (Groovy's creator) and Alex Tkachman (creator of Groovy++, the
inspiration for Groovy's static type-checking). They bring a deep knowledge of
implementation pitfalls that can only be gained from doing it wrong the first
time.

Of course, Scala creator Martin Odersky completely rewrote Scala after version
1.0, and even in version 2.x, has considered fixing stuff between point
releases to be more important than backwards compatibility, so Scala similarly
ought to be quite polished by now (version 2.10), in both feature set and
implementation.

~~~
cageface
I didn't know that the Groovy folks were involved in Kotlin. That's great to
hear. I think this team has exactly the right experience to build a potential
Java killer.

------
TeeWEE
I really like Scala. But i have some thoughts on this article:

\- Its not objective: It's from Typesafe. Logically they are not going to
mention the negative sides of Scala

I used Scala myself and I think it is a very good approach to combining
functional, imperative, object oriented and type safety in one language.

But the big downside is complexity: Scala is utterly complex, its has all the
features of java. But it simplifies the object model (everything is an
object), that's a good thing. But the type system? Really complex. Making
compile time errors very difficult to understand.

A shift to functional style programming is happening more and more. But I
think, and hope, there will be a complete paradigma shift from imperative to
completely functional. This should start with universities starting with
lambda calculus and functional languages to 1st year CS students.

Functional programming has the simplest execution model, is one of the best to
reason about, and works very well with current multicore systems. That's why
i'm spending more time on learning Clojure than learning Scala. In the end a
language like lisp is much simpler but the paradigma shift is what makes it a
bit difficult for those imperative programmers like me.

~~~
karterk
I'm not disagreeing about the complexity, but you can choose to use a sane
subset of the language and do away with all the other stuff. Map, filter,
anonymous functions and type inference already puts it way ahead of Java in
terms of productivity. You can absolutely choose to ignore the rest of the
language.

 _In the end a language like lisp is much simpler but the paradigma shift is
what makes it a bit difficult for those imperative programmers like me._

It's not very fair to compare Scala with Clojure - static typing might not be
everyone's cup of tea, but over time, I have come to appreciate it's power
when dealing with certain classes of problems.

~~~
abolibibelot

      I'm not disagreeing about the complexity, but you can choose
      to use a sane subset of the language and do away with all 
      the other stuff. 
    

You're aware that's the classic counter-argument to "C++ is too complex"? Like
with C++, the problem is it will be very hard to agree on what sane subset to
use. There are a lot of things nice about Scala, but I can't help seeing it as
the C++ of FP languages. Moreover, the Haskell envy it exhibits can be
sometimes embarassing.

------
dkhenry
While I don't think _this_ article presents any compelling reasons to learn
scala, you still should. If I had to list my reasons they would be

0\. Of all the "new" languages Scala has the best selection of libraries and I
think is the easiest to become instantly productive in. Languages like Rust
and even to some extent Go are also really exciting and let you do great
things, but the native library support isn't as robust as it is for Scala, and
Rust in particular is still under heavy development and isn't really ready
yet. From a stability standpoint you should be OK with Go, but even it will be
baking in more stuff and changing more then you will see Scala change.

1\. The Productivity Boost Effect. You will find you can solve complex
problems with a few lines of code and a little thinking. I have ported 1K+
lines of C++ to 10 or 20 lines of Scala

2\. Personal Growth. If you are coming from C++ or Java and have done
Imperative programming your whole career then Scala is a _gentle_ introduction
to functional programming. As you start to use the language you might start by
using it as java and only typing half the character ( no type signatures
,semi-colons , or in some places parentheses ) as you do more things and look
for elegant solutions the function patterns will become obvious in their
usefulness and you will start seeing their value first hand.

3\. Awesome Libraries you get access to. I think immediatly of things like
Akka, Twitter Storm , Play2 , and my personal favorite Spark[1]. Not that
there aren't great libraries in other languages and most if not all of those
expose themselves to Java and other languages, but its great using the native
language they were designed for. you can do some great stuff.

4\. Finally its better then spending all day reading and commenting on Hacker
News. :-)

~~~
apl

      > I have ported 1K+ lines of C++ to 10 or 20
      > lines of Scala
    

I'm not doubting your claim, but as a general rule that sounds awfully steep.
Maybe you got lucky (because whatever you wanted to do was a brilliant match
for some standard library function or happened to be tailored to a uniquely
"Scala-y" feature). In most cases of drastic code reductions upon language
switch, however, it's one of two phenomena:

a) Rewrites are usually more succinct simply because you've done the legwork
before; a second solution is almost bound to be more to the point.

b) One wasn't using the initial language properly.

Sure, going from C to Haskell may lead to insanely compressed code, but C++ in
conjunction with its mature standard library, Boost, and the multitude of
libraries available is such an advanced and excessively paradigm-spanning
language that a reduction by not one but _two_ orders of magnitude suggests a
less than perfect first draft.

~~~
dkhenry
It was a combination of reasons. Firstly I wrote it better the second time. I
think almost any time you rewrite something even in the same language you can
do it in less lines. Secondly even with boost and the STL its really hard to
do some things in c++ in a few lines of code. My case was incorporating ASIO
the framework to get it up and running and get its event loop working as well
as the cod to parse the data that was being received. In Scala with Akka it
was an actor with the IOManager and then simple text manipulation and I had
replicated the functionality.

------
virmundi
I've looked at Scala. I think it's really neat. I think it is Perl. And that's
what scares me. You can solve the problem in many ways, each one getting more
functional and abstract. Eventual so abstract that you can't really tell what
going on.

Another issue is the fact that it interacts with the JVM. Short answer, it
seems nice, but if you're functional, you can't really use the 3rd party libs
because you can't be sure they will play well in the functional world. Long
answer is here. [http://talesfromannoyance.blogspot.com/2012/05/why-im-
lookin...](http://talesfromannoyance.blogspot.com/2012/05/why-im-looking-at-
erlang-over-scala.html).

I'll probably double back to Scala at some point, but I think a language off
the JVM is a better option. Or at lease one that is so odd to the JVM that
most people will only look for libs written in that language. For that I
assume Clojure is a better choice.

~~~
CCs
There's no limitation: you can use any 3rd party Java library from Scala. We
do it in production for years, works perfectly.

It's true that Scala DSL is scary. As far I know soon (version 2.10?) you will
have to add a compiler flag to enable some scary stuff. They are useful for
library developers, but not too great for everyday apps.

Also you don't have to use the functional part. I saw plenty of code that
looked like a nicer Java. You get less boilerplate and better performance -
see <http://news.ycombinator.com/item?id=2615096>

Edit: The article you linked says: "... one call to some open source project
that didn't worry enough about threading to even warn the user that the object
is not thread safe." This would fail in any language, including Java.

~~~
virmundi
You're right. But functional adds a whole new layer of "safety". The
functional developer will think, "My code is functional, share nothing,
messaging passing goodness. I'm fine." As but some new developer, keen on
Scala, but not thinking about the older 3rd parties, adds a call from his
functional goodness to the non safe, side effecting code. This will introduce
a subtle, hard to trace bug. As a result, I'm not a big fan of the "it's
compatible with Java" hype around these VM languages.

~~~
donjigweed
> I'm not a big fan of the "it's compatible with Java" hype around these VM
> languages.

The fact is Java interop is a fundamental feature providing great pragmatic
utility as well as an absolute prerequisite for any kind of adoption of these
languages. It's basically the opposite of "hype."

~~~
virmundi
I don't agree. I think that interopt should be at a higher level, like
services. Putting the ability to integrate code not written for your paradigm
is problematic. Pragmatic, but still problematic.

It's a lot like Node.js. Why Javascript? Because it is so self contained that
it is impossible to use code that violates the paradigm because its too new.
When the designer of Node looked at using straight C or another language, the
legacy threat put him off. Same thing here.

~~~
donjigweed
> I don't agree. I think that interopt should be at a higher level, like
> services. Putting the ability to integrate code not written for your
> paradigm is problematic. Pragmatic, but still problematic.

I think if you look at just about any common example of idiomatic Clojure code
you'll find Java interop sprinkled all over the place. People aren't going to
reimplement all those libraries in Clojure, Scala, or whatever other JVM lang
you're targeting. Seamless interop is a prerequisite. I think most Clojurians
feel it yields far more benefit than any problems it might introduce.

------
ddw
Funny, I had already planned on this as a 2013 goal of mine - this blog post
only reinforced it!

Coursera has a Scala course from Odersky that's worth giving a shot:
<https://www.coursera.org/course/progfun>

------
g2e
Can anyone recommend a good book on Scala? Or should the documentation be
enough?

~~~
Garbage
Programming in Scala - <http://www.artima.com/shop/programming_in_scala_2ed>

For more links, visit <http://typesafe.com/resources>

~~~
gtani
besides staircase book (the one from Artima.com:

the other good starter book: <http://horstmann.com/scala/>

detailed looks, all angles: <http://www.manning.com/suereth/>

------
mcartyem
Can anyone explain in less than ten words why one should learn Scala in 2013?

~~~
CCs
Foursquare, Twitter, LinkedIn, Netflix, Box.com, Nest.com, CloudPhysics,
Quora, Simple, Klout

More than 10: [http://www.quora.com/Startups/What-startups-or-tech-
companie...](http://www.quora.com/Startups/What-startups-or-tech-companies-
are-using-Scala)

~~~
mcartyem
Are you suggesting that the metric of how powerful a programming language is
is the quantity of companies using it?

~~~
CCs
He was asking: why should he learn Scala?

Getting hired by any of these companies can be a good enough reason for some.

------
ww520
I haven't looked at Scala lately. Has the compile speed of Scala improved? Is
it comparable to Javac now?

~~~
CCs
The new SBT is a lot smarter now, my incremental builds are pretty fast.

Speed-up is part of the roadmap: <http://blog.typesafe.com/getting-down-to-
work>

~~~
ryanpers
It's too bad sbt isn't actually simple and is generally a disaster.

I did scala in IntelliJ. The lack of tooling reduces the value a lot. I almost
prefer plain java over the sheer simplicity it has comparatively...

~~~
eeperson
Why do you feel that sbt isn't simple/a disaster? I actually think it is the
nicest of the build tools on JVM. I can set up basic projects with no
configuration. Also, its triggered build feature[1] combined with its
interactive console is a killer feature set that I think all build tools
should have.

[1] <http://www.scala-sbt.org/release/docs/Howto/triggered.html>

~~~
pkolaczk
It is extremely inconsistent. The config file is a list of Scala expressions,
however it is not a valid Scala code as a whole. And when you want
subprojects, then suddenly the config file is not able to do that, you need to
setup another directory with a totally different style of config to do that.
On the other hand the interactive console is a killer feature, agreed.

~~~
eeperson
I don't really think it is inconsistent. Sbt has two methods for configuring
your projects. You can use a limited configuration file that has less boiler
plate but also doesn't allow you to configure as much. The alternative is that
you can use the full configuration that has more boilerplate but lets you
configure everything. The reason I don't think this is inconsistent because
the full configuration is a strict superset of of the limited configuration,
both syntactically and semantically (with the exception that expressions need
to be added to sequences instead of separated by blank lines).

~~~
ryanpers
Question, doesn't the full configuration require you to put your config stuff
in multiple files? A lot of files?

The sbt 'directory of configuration' was always a bummer for me. The single
pom.xml is a nice mechanism. Also maven has good CI compatibility.

The way I think of it is that maven has a good way of specifying a build. The
mvn command is the slow, but complete, way of building. The normal development
lifecycle is to load your maven model into an IDE then go from there, using
IntelliJ's incremental build support, etc.

SBT in other words, solves a problem I don't have.

The other major problem is last year, SBT was a fucking train wreck between
0.7, 0.8, 0.9 and 0.10. Now that we are a YEAR out from that yeah sure maybe
it's a lot better. I'd give it another year before I'd seriously try it again.

In the mean time, I am more interested in kotlin for sane static typed JVM
languages, and clojure for real functional sauce. Scala is too slow for me :-/

~~~
eeperson
SBT actually only requires 2 configuration files (even for multi-project
builds). One for SBT plugins and one for everything else. You can use more
files for organizational purposes but they are not necessary.

I actually like 'directory of configuration'. The SBT build configuration is
actually an SBT project itself. So you can use a lot of the same tools to
trouble shoot the build configuration that you would use to troubleshoot the
build itself. Also, this means that in some cases (such as multi-project
builds) you can use much fewer files.

I'm not sure about CI compatibility. I know that Jenkins/Hudson have SBT
support but I have never tried to use it.

I actually think that way that most IDEs interact with maven builds is less
complete than what you have with SBT. For example, frequently you need specify
your build configuration again if you want your IDE to do incremental
compilation or to run individual tests. This can be very painful if your build
contains anything out of the ordinary. With SBT you just attach a remote
debugger to a long running SBT process and then let SBT due all of the
building and running. It takes care of the automatic incremental compilation
and lets you run individual tests (which, unlike most IDEs, it can be
configured to run tests automatically and it can probably run them much
faster).

I can certainly understand if the previous 0.7 to 0.10 jump made you nervous
about SBT. However, I think that SBT has matured a lot in the year and a half
since then. I think it has finally reached a stability point where it is ready
for general use. In particular I think the 0.12.x series is where this finally
occurred. It has now has a steady release process and has fixed issues that
SBT (along with Scala the language) had, in the past, with binary
compatibility.

EDIT: lost a bunch of text in the submit, had to retype

------
charlieflowers
Anybody have any knowledge of how job prospects compare between Scala, Clojure
and Haskell?

The article seems to imply Scala jobs are taking off (19 pages). Are Scala
jobs really outpacing Clojure and Haskell?

~~~
arikrak
Scala seem to have much more job results on every site than Clojure and
Haskell: <http://www.simplyhired.com/a/jobs/list/q-scala+developer>. See also
Dice.com. To see startup jobs, check Startuply or Angel.co:
<http://www.startuply.com/#/scala%20developer/1>

(To get more accurate results, you should search in-title or by tagged skill.)

------
karthikeleven
Java 8 (coming out in 2013) is going to be sprinkled with functional
programming features....

~~~
pohl
...with emphasis on the sprinkled. No partial function application, for
example.

------
ishbits
Its Scala or Go in 2013 for me...

