
Why we love Scala at Coursera - saeta
http://tech.coursera.org/blog/2014/02/18/why-we-love-scala-at-coursera/
======
mjt0229
It's good to see Scala getting some love after all those "i hate scala" rants
(many of which seemed to be written by people who haven't spent much time with
the language). We're using it at work for essentially all new development.
Although I have complaints, I can't think of another language or environment
that I've used that's been so satisfying and free from overall irritation.

In practice, we don't get code that's unreadable, we don't wait ages for
compilation, and we gain all the functional and typesafe goodness.

~~~
thescrewdriver
We've had the same experience with Scala. It's the most enjoyable language
I've ever coded in. We switched away from Java for most new development a
while back already. The anti-Scala rants are just confusing to us. Most of the
people complaining just seem to be random non-Scala developers recycling other
peoples' criticisms.

~~~
etrain
I hear Java people say "I love scala" a lot. I do not hear people coming from
other environments saying this.

~~~
kasey_junk
I've come from lots of environments, and you're correct, I won't say "I love
Scala". What I will say, is right now, if you are targeting the JVM there
aren't any better alternatives (I believe in strong typing).

Maybe someday Kotlin or Ceylon or Java 9 will be better but for now Scala is
the best choice.

------
sramsay
What is the point of articles like this? I'm not trying to be snarky; I really
am trying to understand why a company would go out of its way to advertise the
technology its using.

Sometimes we see blog posts from devs at companies (often pretty senior) who
write things like "We went with Clojure, and we've been really happy." That's
clearly a geek-to-geek thing. But what is this? I mean, it's also geek-to-
geek, but it's more "official." Users don't care -- they might have no idea
what's even being discussed.

Honestly, it's hard not to read this kind of thing as, "We had a whole bunch
of meetings where we debated what language/technology/platform to use. There
was bitter, acrimonious warfare, but we don't want to be a company that is
about warfare, so we're writing this post that makes the case for why the
people on the side of the angels won the argument."

~~~
NickPollard
For one, it's a good way to attract hires. As they mentioned, Scala developers
are not as common as say, Java developers, so a post like this is a way to
announce to Scala developers looking for work that Coursera is a potential
employer - many people would view being able to use a language they like as a
positive about a job.

~~~
quicksilver03
I see it also as a good way to repel people hating Scala. For example, after
reading this article I'm sure that I won't even try to apply for a job at
Coursera: zero time wasted for both me and them.

------
enjo
_" Refactoring a statically typed language is easier than refactoring an
interpreted one; modifying existing PHP, and even Python, is a difficult chore
that engineers shy away from because modifications are likely to create more
bugs than they fix."_

Over the years I've worked pretty deeply with both static (C++/Java/Scala) and
dynamic languages (Python/Ruby). I simply don't agree.

The biggest thing that contributes to refactorability has nothing to do with
type safety. Instead unit test coverage, by a mile, is the thing that makes
code easy to refactor. In my experience issues of type safety are rare. The
same types of bugs are going to crop up in Scala, Python, Java, or even
Fortran unless you have tests to help you discover those issues.

I've long felt that type safety is largely a solution to a problem that
doesn't really exist. Not in a hugely meaningful way at least. Logic errors
are generally independent of type issues, and as such it is code quality and
unit test coverage, more than any specific language feature, that lead to
highly flexible (and therefore refactorable) code.

~~~
NickPollard
> The biggest thing that contributes to refactorability has nothing to do with
> type safety. Instead unit test coverage, by a mile, is the thing that makes
> code easy to refactor

Type Safety _is_ Unit Test Coverage.

Typing is a statically checked test of correctness of your program.

Languages like C give static typing a bad name. Types are not things like
'float', 'int', 'double'. Types are 'degrees', or 'radians'. Types are 'buy',
or 'sell', 'price' or 'yield'. Types guarantee that your code executes as you
expect, and _prevent you from writing incorrect code in the first place_.

Is it 100% effective? No. But there's a reason that high level statically
typed languages (Scala, Haskell, OCaml) usually work correctly after they
compile.

~~~
brandonbloom
> usually work correctly after they compile

I still don't buy in to this trope.

Q: What is true of every single bug in production?

A: It passed both your type checker and your tests.

~~~
NickPollard
That's a tautology. By that reasoning, don't bother writing any tests, because
all your bugs in production will get past them anyway!

My bugs got past my type-checker, but only 100 of them. You have 1000 because
the 900 my type checker caught, your dynamic language didn't. Then you go and
write unit tests for them, and spend a day writing code that my compiler
generated automatically for me.

~~~
brandonbloom
> By that reasoning ...

My reasoning in no way implies that. I simply said that I'm sick of this
argument that "if it compiles, it works!" Nobody who knows what they are
talking about actually believes that, especially not people who design and
build statically typed languages!

------
dmunoz
I enjoyed reading this article, but does anyone who doesn't already understand
what they're saying understand after reading something like:

"Play's reactive core and asynchronous libraries (e.g. WS) integrate
seamlessly with other powerful concurrency primitives in the ecosystem such as
Akka’s actors. Combining for-comprehensions with composable futures makes
asynchronous concurrency look like straightforward synchronous code."

I get the gist, but I had to go and search for what for-comprehensions were.
According to [0], they're a syntactic sugar over map. Then, if I search for
composable futures (I know those words separately, but can only guess about
them used together) I seem to only get results for Akka 2.0. The first result
I click on is for a 167 page book for $23 USD. Maybe that is my fault, as the
first result is actually to Akka documentation, but when I click there there
is no mention of the word composable. The next two links are to slides of a
presentation by the author of the first link I mentioned, and then to a video
of the presentation. The fourth is to an early access of the same book, the
next a blogspam to the video presentation. I gave up here.

For an article that is arguing for scala in comparison to PHP, Python, and Go,
I didn't walk away with anything more than "sounds nice, but is it really?"

Code example would've helped.

[0] [http://tataryn.net/2011/10/whats-in-a-scala-for-
comprehensio...](http://tataryn.net/2011/10/whats-in-a-scala-for-
comprehension/)

Edit: Calling it "an article that is arguing for scala in comparison to PHP,
Python, and Go" is a misrepresentation. It's really just about why they like
scala, but they do do plenty of hand-wavy comparisons with other languages.

Edit 2: Okay, I see the Akka documentation does have a section "Composing
Futures" that I missed.

~~~
saryant
A for-comprehension from our production code:

    
    
      for {
        createResult  <- Graph.createPerson(person) 
        _             <- Search.putAll[Person](createResult \ "updated_nodes")
        _             <- Search.deletePersons(createResult \ "deleted_nodes")
      } yield {
        Created(createResult \ "node")
      }
    

That code asynchronously updates both ElasticSearch and Neo4j. Those functions
all return Scala futures containing JSON values. First the new object is
created in Neo and then the index in ES is updated accordingly. This is in a
controller action in a Play project where it's critical to keep everything
non-blocking. If everything is successful, Play returns a 201 result to the
requestor, otherwise there are error handling functions elsewhere that kick
in.

~~~
NickPollard
Scala derail: You might have an unintentional happens-before relationship in
that example: The deletePersons call will end up being in the flatMap of the
putAll[Person] call, which means it wont be started until the putAll finishes,
when by the looks of it you could do both at once (only the createPerson needs
to happen first).

You might want to do something like this:

    
    
      for {
        createResult  <- Graph.createPerson(person) 
      } yield {
        val a = Search.putAll[Person](createResult \ "updated_nodes")
        val b = Search.deletePersons(createResult \ "deleted_nodes")
        for ( _ <- a; _ <- b ) yield Created(createResult \ "node")
      } 
    

(notice starting the computations outside of the second for-comprehension,
then just waiting for them inside)

~~~
saryant
Good catch. :) Our production code actually does handle the relationship
correctly, I just wanted to simplify in my example.

------
fiatmoney
This is a thing about Scala which gives me pause: it looks like gazing into
the guts of the compiler puts one on a course towards a nervous breakdown.

[http://www.youtube.com/watch?v=TS1lpKBMkgg](http://www.youtube.com/watch?v=TS1lpKBMkgg)

~~~
psuter
Please don't miss the larger point of this talk (and others by the same
speaker); programming languages _in general_ are not what they should be
according to this speaker. If anything, though, he seems to agree that Scala
is a good choice compared to the plausible alternatives:

    
    
        "At the very least, I can endorse Scala relative to the set of existing
         alternatives pretty strongly."
    
        "I judge things compared to what could be, and not what is. [...] It's not
         good enough to be the strongest of the little kids brawling when you could
         be the big kid next door."

~~~
coolsunglasses
Actually Haskell is quite nice and does a better job. Practical too.

~~~
polymatter
I am a great fan of Haskell.

But the tooling and libraries of the JVM is a significant real-world practical
benefit. Scala can get away with a lot of nasties for that. (In fairness Scala
is very well designed, nastiness is normally all to do with Java
compatibility)

Plus it allows Java programmers to start writing code almost immediately.

~~~
nousernamesleft
And yet the whole first part of his talk was problems with scala that are not
problems in haskell. And many of those problems exist precisely because of
java compatibility, which he acknowledges and says is not a good enough reason
to do things poorly. By his own measure it seems like he should be using
haskell.

------
courtf
All of the praise here for scala can be applied, verbatim, to Java itself.
Some of the concerns are no different than Java (UTF-8), or are actually not a
problem there (intellij IDE vs eclipse).

While the comparison to dynamic languages is valid, this is a rather shallow
discussion of scala itself.

~~~
hythloday
"Combining for-comprehensions with composable futures makes asynchronous
concurrency look like straightforward synchronous code."

I would really enjoy seeing this in Java.

~~~
laureny
I'd like to see the Scala code too. I've played with both and in the end, both
codes are pretty complex, just complex in different ways.

It's a complex problem with a lot of edge cases and tricky error cases that
need to be handled properly, which is where the elegance of the language or
the programming paradigm usually goes down the drain.

I'd like to see a fully functional snippet of code that gracefully handles
errors in both languages.

~~~
hythloday
OK. Something like:

    
    
      val fNotifications: Future[List[Notification]] = // get notifications from the database
      val fPosts: Future[List[Post]] = // get posts from a different database
      
      // If getting notifications fail, log the error and pretend there are no notifications
      val safeNotifications = fNotifications rescue { t: Throwable => log.error(t); Future(Nil) }
    
      // If getting posts fails, log the error and try retrieving stale posts from the cached post server
      val safePosts = fPosts rescue { t: Throwable => 
        log.error(t)
        // If the cached post server fails too, just pretend there are no posts
        cachedPostsDatabase.getForCurrentUser rescue { t: Throwable => log.error(t); Future(Nil) }
      }
    
      val facebookPage: Future[Page] = for {
        notifications: List[Notification] <- safeNotifications
        posts: List[Post] <- safePosts
      } yield {
        // Code here executes when both/all outer futures are ready
        renderFBPage(notifications, posts)
      }
    
      // We can return the future or call more rescues on it or combine it with more futures
    

is a thumbnail sketch of how you'd implement the facebook timeline in Scala if
you were doing so. There are even better abstractions that I've started using
(functional reactive programming specifically) but none of them come with the
standard library, so I thought that was a bit unfair.

------
hawkharris
My favorite quote from the article: "Python probably takes the cake for being
regular. PHP gets cake in the face… Scala is somewhere in-between."

~~~
ChikkaChiChi
If you have complete control over your programmatic infrastructure and you are
getting PHP 'cake in the face' you shouldn't blame PHP. You're just a shitty
programmer.

~~~
hawkharris
I helped develop a PHP application used by about 30,000,000 people. It
consisted of well-organized objects that followed proper design patterns. Our
API was easy to use and understand.

Although PHP was an effective, decent language, it wasn't the best tool for
our project. It lacked certain functional features, brevity and syntactic
sugar that one might find in Python.

The Web is full of emotional, profanity-laden debates pitting one language
against another. I don't think those are interesting or useful. But it is
productive to critique the languages' relative strengths and weakness based on
how they can be applied to a business problem.

Like the engineer from Coursera, I determined that PHP was, indeed, a "cake in
the face," considering my needs and circumstances at the time.

------
_pmf_
> Scala’s compiler is very sophisticated–it runs over 25 phases

Sophisticated is not the first term that comes to mind.

------
flurdy
The quote "I trust my team with this power, but can you?” resonates well with
me and also why I similarly insist on removing restrictions and permissions on
most tools etc. I trust my team. They are smart and reasonable people (whom
are allowed to f-up sometimes).

There is an unrestricted handbrake in every car, that doesn't mean people pull
it unless necessary.

------
wilsonfiifi
It would be interesting to read a similar article from a company that uses
python as their core programming language (Dropbox for instance) to contrast
it with this one. Python might not be as popular as Java but I was under the
impression that it offered a rich enough platform/ecosystem to accommodate for
a wide spectrum of software projects. Concerning the issue of type checking, I
understand that it's great to have a compiler that can take care of that for
you but I'm pretty sure unit-tests and a bit more care also goes a long way
when using a scripting language like Python; besides how hard can it be to
sprinkle a bit of "type(<object>) is" in your code where type checking is
required? (smile)

I wonder if vert.x was also considered. I don't see any mention of it in the
article.

~~~
lgieron
I'd say having automatic compile-time checks and vs having to be "extra
careful" \+ necessity for more umit tests is a world of difference.

AFAIK, Google doesn't use dynamic-typed languages for any of its projects
(except where their hand was forced - they inherited the codebase in an
acquisition) and they sure as hell are experienced in large-scale software
development (for small to medium projects, the drawbacks of python etc. aren't
as apparent).

~~~
okaram
I'm not sure what you consider google 'projects'; from what I heard, a lot of
their 'sysadmin' type of scripting is in python (probably moving to go now)

~~~
lgieron
By "projects" I mean code delivering actual software products (like for
example the search, gmail etc.), not some auxiliary admin scripts.

------
donjigweed
Good to see some love for Scala after all the recent rants. Unfortunately, I
think it's going to be short lived. Most shops where Scala would be an option
will soon have a production release of JDK8 available to them, at which point
Scala's tradeoffs really only become acceptable to those who already have
significant investment in the language or who think category theory is a
reasonable companion to an industrial language.

~~~
kasey_junk
JDK8 is a very nice release and I hope it will bring Java a few years ahead,
but there are so many things still missing from Java that every time I shriek.
From big things like no type class support to tiny things like 1 file per
interface/class the Java experience continues to be frustrating in the
extreme.

~~~
donjigweed
Which is why I said "Scala's tradeoffs" would become unacceptable. Java 8 is
basically "close enough" to "The Good Parts" of Scala that most people
probably won't be willing to tolerate all of Scala's warts.

~~~
frowaway001
> Java 8 is basically "close enough" to "The Good Parts" of Scala

Ehh ... not really. And I honestly don't see the gap between Java and Scala
closing. It's widening at a frightening rate.

Java's warts are far worse than Scala's warts. So I'm not seeing why that
should be a point either.

------
ChikkaChiChi
I enjoyed this article because it stated without a whole lot of bias why Scala
was the right tool for the job.

Python could have fulfilled some of the requirements such as the lighter
concurrency; however it would have come at the expense of the ease of
deployment.

I disagree with type safety being integral to refactoring, but each team has
their own culture and this seems to fit theirs well.

------
markbao
From an experience standpoint, isn't the fact that you'd have to teach people
a new language coming in the door detrimental to the use of that language?

Comparing a company that takes in people that have been coding
Ruby/Python/Java/whatever for 5+ years, versus one that takes in people that
don't have Scala experience but teaches them on the job, wouldn't the former
move faster and generally have more experience, making it better to hire from
a large pool of experienced people (in a popular language) than a small pool
(in a more niche language)?

This, of course, assumes (rightfully, I think) that the "carryover" effects of
programming experience aren't substantial enough to claim that 1 month of
Scala experience is better than 3 years of Ruby experience, and nor is the
"advantage" that Scala gives over these more popular languages (real or
imagined).

I love Coursera and all, but I'm curious what people think about this.

~~~
NickPollard
Teaching someone a programming language (e.g. Scala) is not equivalent to
teaching someone to program.

If you take someone who has 5 years Ruby/Python/Java experience, and then
spend a month teaching them Scala, they don't miraculously forget everything
they know about functions, algorithms, data structures, encapsulation,
interfaces, problem-solving, maths, etc.

I started my current job (at a Financial Institution where I write 99% Scala)
with no Scala knowledge, but good programming fundamentals and experience with
functional programming. A month later, I was a competent Scala programmer.

This isn't unique to Scala - if you have a language you like, which you think
offers advantages over the competition, then it is worth training people to
use it and then using it.

~~~
markbao
That makes sense. This is the kind of "carryover" effect that I talk about in
the parent comment, so maybe I'm wrong in that there isn't a lot of carryover
where in actuality there is.

I just doubt that learning a new language automatically gets you up to
anywhere near 50% competency as someone who has been using it for 5+ years
(would you agree with that?), and the ability to hire people who can apply
that full level of competency (i.e. how big the hiring pool is) is important
in deciding what language to use.

------
hit8run
I've used them all: PHP, Ruby, Java, Scala, Node and Python. I'll stick to
Python because the syntax is awesome and it's easy to read. Scala looks so
weird to me. If I was really dependent on the JVM (which is indeed a great
environment) I would honestly just stick to Java and enjoy the superior IDE
support compared to scala.

------
nnq
> Refactoring a statically typed language is easier than refactoring an
> interpreted one

Compiled vs interpreted is very different than dynamically typed vs statically
type! Yes, I can't name any statically typed language that is interpreted (or
that has an interpreter actually used in production, to be more exact), but
we're still talking about different things.

I guess this is some kind o "semantic typo", but... really? Am I supposed to
trust the opinion of whoever wrote this?!

------
CmonDev
"Refactoring a statically typed language is easier than refactoring an
interpreted one ... even Python is a difficult chore that engineers shy away
from because modifications are likely to create more bugs than they fix."

Well said, I think refactoring being "fun" is more important then coding being
"fun" for projects that are not a piece of throw-away code (unlike data
analysis for example).

------
abalone
Weird, why say all that about how it's better than Python/PHP/etc but then not
say why they chose it over Java?

~~~
lmm
I suspect most of their target audience has a dim view of Java. Also, scala's
official website has the advantages over Java.

(If you're asking what Scala's advantages over Java are: less verbose to read
(general lack of syntactic noise, case classes, UAP),
covariance/contravariance for generics, code that's much more explicit about
mutability (thanks to val/var), pattern matching, more flexible syntax
(particularly for/yield as used with e.g. futures), more powerful/flexible
type system (e.g. the typeclass pattern))

~~~
abalone
But one of the Scala drawbacks they cite is "arcane syntax". Another one is
all the "advanced features" than can "weave a tangled web of code
undecipherable to even its authors".

That's very much against the usual alleged benefits of Scala vs. Java that
you've listed.

That's why I was very interested in the article, a "real world" take on Scala
that really felt doctrine-free.. but found it odd that they didn't mention
anything about Java. Java would seem at first blush to solve all of the
concerns they listed: compile time, arcane syntax, counterproductive advanced
features, primitive IDE support, training needs. While at the same time
preserving most of the benefits: type safety, concurrency with Play/Akka, JVM
ecosystem.

So it was just a little weird to not mention the elephant in the room.

------
brown9-2
The quote about refactoring ease in Scala is interesting, since I imagine the
experience would be the same in plain old Java - refactoring in any statically
typed language is much easier when you are comparing to PHP, Python and
Javascript.

~~~
kasey_junk
In fact it is a little dishonest. Refactoring in Scala is considerably worse
than refactoring in Java due to the complexity of the language.

~~~
brown9-2
True, I'm curious what (if any) IDE the quote-author is using for refactoring.
Or perhaps they are just referring to the simplicity of something like being
able to rename/edit a method signature and have the compiler catch all the
references to the old name immediately.

------
namelezz
Anyone knows when Functional Programming and Reactive Programming classes are
reopen?

~~~
nkvoll
No, they haven't released any new information about them yet.

------
jsmith0295
I think they really love it because they have plenty of time to take courses
online while they wait for their Scala code to build.

------
bleh_
I didn't know ascii architect was a job.

------
noelwelsh
I think this is a nicely balanced article. Good to the see the pros and cons
clearly laid out.

------
mentaat
the whole "live reload" capability of play is a gimmick because in real life
making a code change in a medium to large project is like watching grass grow
- every change you make takes minutes to compile and reload.

~~~
atto
How large? We have well over 100k lines of code (Scala), and it's not a
serious issue. The sbt 0.13 incremental compiler is _much_ better than 0.12's.
Also, using sbt multi-projects helps quite a bit (even when running all at
once).

~~~
mentaat
much smaller - around 25k+. i gave up after becoming frustrated by the
atrociously compile times. haven't used sbt .13 though but i don't expect it
to solve miracles given how inherently complex the scala compiler code is.
according to paul phillips, core scala committer, there are large portions of
the compiler code that nobody touches because nobody understands it. and as
per him this along with bunch of other limitations guarantees that you won't
see huge gains in compile times unless they rewrite the whole compiler...

~~~
frowaway001
> there are large portions of the compiler code that nobody touches because
> nobody understands it

Could you link to one of those "large portions"?

> and as per him this along with bunch of other limitations guarantees that
> you won't see huge gains in compile times unless they rewrite the whole
> compiler...

You mean like [https://groups.google.com/forum/#!topic/scala-
internals/6HL6...](https://groups.google.com/forum/#!topic/scala-
internals/6HL6lVLI3bQ) ?

~~~
virtualwhys
Nice find! Didn't know they were so far along with Dotty.

Will be interesting to see how a potential merge works out (assume Scala 2.13
at the earliest).

