
Horses for courses: choosing Scala or Clojure - ColinWright
http://rrees.me/2013/03/19/horses-for-courses-choosing-scala-or-clojure
======
Uchikoma
I like compile time / IDE type checking, so I'm a Scala user.

But Rich Hickey is such an amazing guy, steering Clojure, with pragmatic
solutions catering to developers while Scala often feels like an exercise in
academic language development.

~~~
seanmcdirmid
As long as you are hero worshiping, Martin Odersky is an amazing guy also who
is quite focused on pragmatic Scala. Ya, scala has lots of features and it
does attract more academics, but there is nothing really flimsy ivory tower
about it.

~~~
Uchikoma
After 5yrs of Scala usage, I'm sorry to disagree. Martin might be a very
clever guy, but Scala is not catered towards developers but language
enthusiasts. From my personal point of view, and everyone else might disagree,
it's very slow to compile, has complicated error messages, the API is
implemented to be powerful not towards easiness of use etc.

~~~
seanmcdirmid
I know Martin, I worked for him 5 years ago. He is like a "hacker's hacker"
who deeply understands "programming." Perhaps this doesn't translate very well
into "developing," and Scala is a great language for "programmers."

We can argue about the trade offs he made, I think Scala represents a
reasonable point in the language design space: its not for everyone, but a lot
of people like it a lot; it is probably more popular than Clojure (though
LISP'ers tend to be more vocal in general).

It is definitely not a programming language for language enthusiasts, who tend
to be more picky than programmers and developers and usually have their
personal esoteric favorites.

~~~
Uchikoma
He might be understanding programming, but from an academic background not
from managing large business development projects with issues like compilers,
tool chains, on-boarding of new team members, turn over, business pressure to
cut corners etc. Scala has very different priorities. The top priority of
Scala is "power", language features and the holy grail of marrying FP and OO.
The priority of Clojure is solve problems.

Case in point: The lacking Scala API with a high percentage of method calls
not described, not explained and rarely any descriptions of classes. Second
case in point: In 2013 Scala is still abysmal slow (several seconds for some
classes) when compiling (with SBT compile/JRebel reload or with Play
compile/reload).

PS: Side note: Not to sound arrogant, but for the perception and spread of the
language it is not important what Martin thinks, but in customer development
style what my perception as the CTO of a company thinks that might decide
between Scala and Clojure.

~~~
seanmcdirmid
And you think Eich, Matz, Guido, Gosling, Pike, Ritchie, Wall, Kay, Wadler,
Steele, Gabriel, Anders, Syme, Roberto, Stroustrup all understood the role of
programming language in business development projects, whereas Martin didn't?
All successful programming languages are designed by people passionate about
programming, not software development! The people passionate about software
development give us crap like UML. Maybe there is something special and
different about Rich Hickey's background that he gave you a language that you
prefer, but I'm guess its just a different background driving him to make
different trade offs that suit you better than other trade offs that could
have been made.

Part of the problem you are probably hitting is Scala's attempt to be
statically typed while also being flexible, not really its attempt at marrying
OO and FP; this tends to require lots of advanced typing concepts that many
people are not yet comfortable with, and perhaps they never will be. Dynamic
languages save a lot by pooing away the static type system; but of course
there is then a lot they can't provide. I am a big critique of this also,
we've had our disagreements, but really...at the end of the day it was a
design decision made that is no less valid than other design decisions that
could have been made.

So don't use Scala if it doesn't suit you, this is reasonable, your criticisms
are reasonable, but I don't think it is fair at all to say that the designer
was stupid or somehow misguided. There are more CTOs who are misguided than
successful language designers.

------
jcromartie
I think the major error in this piece is assuming that Clojure is really
geared towards any one type of problem. Instead, Clojure is designed to give
you a set of tools that you can freely combine for the problem at hand. It
achieves this by separating concepts that are commingled in other languages,
like identity, value, and type.

By splitting out those concepts, you get a very solid foundation on which you
can build pretty much any other paradigm.

------
luu
_If you are going to work with concurrency ... I think you definitely want to
be using Clojure._

Is it widely accepted that Clojure is better for concurrency? [1] I haven't
used Clojure much, so I can't comment on their relative merits. But, I've
played with actors in Scala some, and done a bit with STM, and they make
concurrency relatively straightforward. It's plausible that Clojure has a
better concurrency story (and this blog post has inspired me to try it out)
but, concurrency is easy enough in Scala that I don't think of it as a
weakness of the language, the way I would with something like C.

[1] This is not a rhetorical question.

~~~
Skinney
Clojure uses STM and has persistant datastructures by default. This makes it
pretty safe when it comes to concurrency. Clojure also has good support for
paralellism through pmap and reducers. Making something run in paralell is
often just changing the name of a function or importing a diffrent namespace.

I don't know Scala that well, but actors in scala still shares state, and
doesn't give the same level of protection when it comes to changing state.
Actors also introduce some overhead in case you just want to read a single
variable from a datastructure safely. You have to send a command and receive a
message, wheras in clojure you just retrieve the value you want. Actors
however are, to my knowledge, easier to scale across machines as actors
doesn't necessarily have to be in the same process, or even on the same
machine.

~~~
dkhenry
Over the years Scala has adopted some of the concurrency primitives from
clojure, now I think if you compare the two there isn't much of a difference
between them, however when you start to add in third party libraries I think
Scala is actually pulling ahead of clojure. With Akka not only does it do
single node concurrency well it also does multinode concurrency with two or
three extra lines of code.

~~~
Skinney
Well, when you add in third-party libraries, Clojure can use these too.

I wasn't aware Scala had incorporated Clojuires STM, I thought Scala was
married to Actors/Akka?

~~~
dkhenry
Akka has implementations of STM, and a few other niceties from Clojure land.

Also your right Clojure can use Akka just like scala so neither is any better
for it, but scala can call native clojure code too. What I have found Awesome
is that I can work on a scala project or library and hand it off to my co
worker who is a clojure guy and he can incorporate it.

------
moomin
For those of you who don't know of Robert, he works for Guardian, writes a lot
of Scala and is one of founders of the London Clojure group. Indeed, he's
talking about Riemann on Tuesday @ SkillsMatter.

------
jamii
I didn't find that comparison very useful/accurate (having used clojure
heavily for a year or two and scala full-time for the past month). The main
differences I find are:

When evaluating language tradeoffs the scala community values power more and
the clojure community values simplicity more.

Scala wants to provide you with the most powerful language possible. Clojure
wants to make it easy for you to mold your own language.

Scala language tooling works at compile-time and analyses the language
statically. Clojure language tooling connects to a running environment and
uses introspection. Scala has much better static checking and clojure has much
better introspection. While both languages have a repl, the clojure community
puts much more emphasis on live, interactive programming.

Clojures syntactic extension mechanisms are much simpler, being based on
sexps. Scalas are powerful (eg can access the lexical environment) but much
more heavy-weight.

Clojure has run-time eval. This makes it possible to do eg domain-specific jit
(eg compiling DSLs -> clojure code -> java bytecode on the fly). Scala has a
run-time interpreter which I haven't used but is reputed to be slow.

I haven't yet explored non-jvm backends for scala but I suspect that clojure
will eventually dominate on that front for two reasons: 1) when clojure-in-
clojure is finished porting clojure to a new platform will be far easier than
scala and 2) clojure was designed from the beginning to be a parasitic
language and delegates many features to the underlying platform.

Scala breaks backwards compatibility much more often than clojure. Whether
this is a pro or con is up for debate. There are lots of small niggling things
in clojure I would like to change but on the other hand maintaining scala code
across compiler updates is a pain in the ass.

Personally, I believe that the number one problem a language needs to address
is managing complexity. The clojure community largely seems to get that and is
driving for simple, orthogonal language features and libraries to an extent
that I've not seen in any other community (eg
[http://blog.getprismatic.com/blog/2012/10/1/prismatics-
graph...](http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph-at-
strange-loop.html)). In addition, the most exciting research I've seen on that
front (eg
[http://www.vpri.org/pdf/tr2011004_steps11.pdf](http://www.vpri.org/pdf/tr2011004_steps11.pdf)
[http://boom.cs.berkeley.edu/](http://boom.cs.berkeley.edu/) ) and most of my
favorite tools rely on powerful introspection and runtime code generation. I
think Yegge describes this better than I can - [http://steve-
yegge.blogspot.co.uk/2007/01/pinocchio-problem....](http://steve-
yegge.blogspot.co.uk/2007/01/pinocchio-problem.html)

~~~
Uchikoma
After 5yrs of Scala usage, "but on the other hand maintaining scala code
across compiler updates is a pain in the ass." this is really a pain,
especially if you come from Java where probably 15yrs old code still runs. I
would no longer go with Scala for a new project but give Clojure a try.

~~~
happy_dino

        Q: What does java.lang.NoSuchMethodError: 
           clojure.lang.RestFn.<init>(I)V mean?
        A: It means you have some code that was AOT
           (ahead-of-time) compiled with a different
           version of Clojure than the one you're
           currently using. If it persists after
           running lein clean then it is a problem
           with your dependencies. Note that for
           your own project that AOT compilation in
           Clojure is much less important than it
           is in other languages. There are a few
           language-level features that must be
           AOT-compiled to work, generally for
           Java interop. If you are not using any
           of these features, you should not
           AOT-compile your project if other
           projects may depend upon it.
    

[https://github.com/technomancy/leiningen/blob/stable/doc/FAQ...](https://github.com/technomancy/leiningen/blob/stable/doc/FAQ.mdhttps://github.com/technomancy/leiningen/blob/stable/doc/FAQ.md)

~~~
jamii
I've never even seen AOT compiled code. If it becomes common (maybe in
proprietary projects?) then I would argee that its important to maintain
binary compatability.

~~~
happy_dino
I just wanted to highlight how bizarre this discussion has become in general
(nothing against you, it seems to be a common theme):

    
    
        “““
        I'm unhappy with Scala's compatibility guarantees,
        therefore I'll pick a language which
    
        a) does not provide any binary compatibility guarantees
           at all,
        b) has no tool to figure out whether incompatible 
           changes have actually happened,
        c) lacks any sort of guidance to figure out if library 
           A is compatible with library B short of downloading
           and executing them together,
        d) provides no clean way to cross-compile libraries 
           against multiple versions.
    
        But hey, let's bash Scala for caring about these issues 
        and deride them for shipping actual, working
        solutions addressing those issues.
        ”””
    

Scala guarantees:

    
    
        - Source compatibility between major versions
        - Source and binary compatibility (both backward and 
          forward) for all minor and update releases of that 
          major version
    

People will have a hard time to find another modern language which gives them
these guarantees.

Hypocrisy and cognitive dissonance FTW, I guess.

~~~
jamii
I was not 'bashing' scala. I discussed the tradeoff between removing old cruft
from the language and breaking old crufty code. I was careful throughout that
entire comment to only discuss differences between the languages and
communites and not make or imply any value judgement. I'm trying to provide
useful information for people deciding between scala and clojure, not start a
fight.

With regards to binary compatibility, what I think you are missing is that
clojure libraries are almost always distributed as source code. The clojure
compiler is fast enough to just compile everything at runtime (during
development at least) and clojure has not broken source / api compatibility
since the first major version. Where AOT compilation is useful is:

a) Improving _application_ startup time

b) Shipping libraries which generate java classes at compile-time (usually to

c) Shipping proprietary libraries without source code

I would definitely like to see the community figure out binary compatibility
between libraries to improve cases b and c but it's really not a pressing
concern.

EDIT: On AOT compilation
[http://dev.clojure.org/pages/viewpage.action?pageId=1572898](http://dev.clojure.org/pages/viewpage.action?pageId=1572898)

~~~
happy_dino
Fair enough, as mentioned, it was not targeted at you. Sorry if I didn't make
that clear enough. I was mainly summarizing my impression of the (sad) current
standard of debate in interested circles.

------
moomin
Whilst I understand that you can have good reasons for want to integrate to
the libraries he mentions, I can't help feeling that Hibernate is a library
that solves a problem caused by the type system, so just using a dynamic
language and forgetting Hibernate strikes me as a good approach. Indeed, all
the libraries listed look avoidable.

~~~
pjmlp
> Indeed, all the libraries listed look avoidable.

Not on an enterprise context, like it or not, most consulting projects on the
enterprise world require interaction with them.

~~~
gngeal
Is that the IT equivalent of legally requiring a man with a red flag to run
sixty yards ahead of the car?

------
talloaktrees
what is meant by "multi-core concurrency"? Isn't that just paralellism?

~~~
Skinney
Paralellism is about using multiple cores to speed up a certain operation.
Cuncurrency is about doing many things at once.

Multi-core concurrency means that your concurrent operations can happen at the
same time and thus corrupt shared state.

~~~
gngeal
I think the notion of operation serializability is important in this context.
From what I understand, in the broadest possible strokes, "concurrency" means
"it doesn't matter in what order the sequence of operations happens and how
their execution is reshuffled as long as the dependency invariants are
maintained".

------
zerr
When it comes to more or less large and real world systems - I really can't
imagine how one can work with dynamically typed languages.

~~~
Skinney
Why? Static languages ensure type safety (which are uncovered in unit tests
anyway) and to ensure this type safety, they need more information from you,
the developer. Clojure allows you to write less code which, depending on who
you talk to, equals faster development time.

Static languages are also usually faster, so I guess the tradeoff stands
between raw performance and code size.

There are numerous succesfull projects using dynamic languages. Github, as far
as I know, uses Ruby.

~~~
zerr
Yes, but when it comes to reading/understanding and refactoring/modifying code
- this is where things get complicated.

~~~
Skinney
Never really had any problems reading/understanding dynamic code, actually I
(and this is highly subjective) think it's easier to read dynamic code because
you don't need to read a lot of extra code written to satisfy a compiler.

I agree completely when it comes to refactoring/modifying code though. This
can become cumbersome, especially if you don't have unit tests.

~~~
zerr
Well, what you call an extra code to help to satisfy a compile, I call a part
of a documentation which helps understanding the code, in addition with some
static integrity checking :)

~~~
Skinney
I understand the argument. In my experience though, documentation and/or tests
usually always makes type info redundant. But I'm well aware that people have
different views on this. Each to his own.

------
happy_dino
I'm no Clojure expert, but listening to the Scala parts was like “Ok, I might
disagree, but one can claim that ... WOW, that's factually wrong ... _nod_ ...
this is pretty misleading the way it is described ... ok, this sounds
reasonable ... no, that's just wrong”.

Can a Clojure expert comment on whether the Clojure part is as
wrong/inaccurate as the Scala part?

