
Scala – 1 Star – Would Not Program Again - jms_
http://overwatering.org/blog/2013/12/scala-1-star-would-not-program-again/
======
NickPollard
I started learning Scala almost a year ago at my latest job - we use it for
production systems at a large multinational investment bank.

Coming to Scala from experience including C, Java and Haskell, I intially
found Scala quite difficult. It is true that there are some things in Scala
that are not obvious to newcomers, and that are difficult to discover for
yourself - such as the use of Implicits, and the strange precedence and
binding rules for operator syntax.

That said, it doesn't take long to learn, and once you do, it all makes sense.
There are other great languages out there (I'd say Haskell is one), but
compared to for example Java, or one of the dynamically typed languages, Scala
is superb.

Types, whilst not having the full H-M inference, are brilliant. That the
author complains about having types rather than a simple map for keys shows a
misunderstanding of what they are there for - the idea is to allow the
compiler to prove at run-time what is valid code and what isn't. He comments
that tests run too slowly in Scala (they don't - for our production systems
building in SBT, a typical test run is significantly less than 10 seconds) but
a lot of the time I don't even need to go that far - my IDE already highlights
errors in the code as I type, where I have passed in incorrect or insufficient
data.

Also, the author makes a strange comment that H-M 'enabled' Monads, and the
comment is written in a way that implies that Scala does not have Monads. This
is incorrect. Scala has monads, and the Scalaz library has huge support for
Monadic programming. We use Monads and Applicative Functors (a close relative)
daily to build high level abstractions, and we couldn't live without them. In
Scala we say flatMap rather than bind (or >>=), but we mean the same thing.
Although thanks to the same flexible method naming that the author complains
about, you can in fact say >>= if you wish.

If you've only got a couple of days to use a language, and you're using it for
a tiny project, then Scala is not for you. If want to learn a language that
can make you vastly more productive whilst at the same time making your code
safer and more robust, Scala is a very effective candidate. It's not the only
candidate, but you should at least consider it.

~~~
saryant
I'll echo all of this (minus scalaz, we don't use that).

I'll give an example of the power of Scala's type system. When I first
convinced one of our founders to give Scala a try, he used it to write the
first pass of our analytics service. He'd never written Scala before but once
it compiled, it ran _correctly_ on the first try, that's the power of its type
system.

~~~
randomdata
Having never used Scala before, does its type system provide details about
errors that other languages do not? Watching a compile fail because of an
incorrect type is not something I have run into very often, if ever, in other
languages that provide similar type systems.

I mean mistakes can happen and if the type system can catch it for free, so to
speak, that is great. I'm not about to argue that it is completely useless.
But in terms of probabilities of what kind of bugs might be introduced, type
errors seem to be on the low end.

To infer that Scala's type system is powerful enough to catch the more common
types of mistakes programmers make, that is quite an impressive claim. I am
curious to know more.

~~~
jacobgreenleaf
In Haskell, and I assume Scala, you can name types of the same form, so I
might say a TimeSeries is a list of floating point values. If I use that data
type, you can't accidentally pass a different kind of list of floating points
even though they're the same type.

~~~
p4lindromica
Yes, you can do this in scala with type aliases

~~~
lmm
Type aliases don't solve that problem. You need to use something like
Shapeless' newtype.

------
gfodor
Several years ago I picked up Odersky's book. I got a few hundred pages in,
considered the types of problems I had encountered in my career so far, and
decided life is too short to be spending my time learning some hyper-complex
programming language that seemed, like C++, to seem unable to say "no" to
introducing complexity where it would provide minimal upside in Getting Shit
Done.

Instead, I learned Clojure. I use Ruby, the epitome of comfortable languages,
for most things, and when the hard problems come up, I use clojure. My next
major scientific computing problem, rare as they are, will be in Julia instead
of Matlab for prototyping and java for production. Scala seems to be the hard
language for easy problems. No thanks.

~~~
voyou
Scala reminds me of C++ too, but it's impressive that, in a mere 10 years,
Scala has achieved all the multi-paradigm incoherence it took C++ 30 years and
tortuous backwards compatibility constraints to attain.

Actually, I spent some time over the weekend trying to get familiar with Scala
by using it to solve some Project Euler problems, and it was pretty
entertaining. Still, the language's bias towards there being more than one way
to do anything does worry me; it does seem that the kind of mutually
incomprehensible code bases the OP talks about are likely. I would assume
that, like C++, you need a strong style guide for a Scala project laying down
which parts of the language you are going to use. Does anyone have any
recommendations for guides on writing comprehensible, maintainable Scala?

~~~
pkolaczk
Multi-paradigm incoherence? There is a huge difference between throwing
multiple features/paradigms into one language (as C++ does) and _integrating_
them so that they are orthogonal and don't get into your way (as Scala does).
The integration part is the hardest thing and Scala designers did the great
job there, assuming the constraints that were given.

Scala does have some rough edges but they are not the kind of C++ ones, and
even the complexity of the most powerful features (implicits) is very
controllable.

Seriously - which features would you like to remove from Scala? I'm really
curious because I don't find any redundant ones. All are pretty complementary
and very useful.

~~~
kasey_junk
I'm not sure I'd remove any, but there is a huge incoherence in what is and is
not "idiomatic" scala.

The most obvious example that comes to mind is whether you should use mix in
traits or type classes for api design. Another one is the "magic-ness" of
map/flatmap/filter for for comprehensions but no way to extend that for
Functor/Monad/Monoid type classes.

Finally, the Scala community is a huge advocate of Algebraic Data Types yet
don't support Disjoint types making any sufficiently complex system cumbersome
to model as an ADT.

------
runT1ME
I'm always interested to see intelligent criticisms of one of my choice
languages. Let's take a look at what he has to say:

 _Slow build times complaint_

> It is essentially impossible to practice TDD in Scala simply due to the time
> it takes to compile.

Hrmm, that's interesting, because it sure seems like other people are able to
do this. I agree, the slow build times are annoying, but let's not exaggerate.

 _SBT critiques_

>That punctuation-strewn build system I was forced to use was just taking
advantage of Scala’s ridiculously flexible syntax.

Yeah, I get it, everyone makes fun of SBT's syntax.

 _Language is complicated_

This is where it just kind of descends into whining about how 'hard' the
language is. He claims javascript is a "simple" language. Does he just not
count the weird edge cases when thinking about complexity?

 _Type inference complaint_

> And this is the real death knell for Scala. Hindley-Milner Type Inference is
> a fantastic thing.... It’s enabled monads, which you want to be able to
> understand and then use in a type-free language.

WAT. I don't think those words mean what you think they mean.

>In my mind, Hindley-Milner was always the promise and the pay-off for
Scala...I know this is the fault of the JVM’s use of type erasure. I don’t
care.

O REALLY? Go on...

Maybe if this guy had cared enough to do a five second google he'd realize
that Scala doesn't use hindley-milner type inference.

Bottom line is, I think I have a good understanding of the type of programmer
this guy is, and it's exemplified nicely in this quote right here:

>Sure, with another couple hours we would have been able to figure it out…
[but] We ended up copying and pasting the same four lines into all our
endpoints. A dark moment.

For an intelligent critique of the scala langauge see here:

[http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...](http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu)

~~~
asdasf
>Maybe if this guy had cared enough to do a five second google he'd realize
that Scala doesn't use hindley-milner type inference.

That's his point. Scala doesn't use HM and it needs to. He says the reason it
doesn't is because of the JVM, which seems misguided.

~~~
quatrevingts
He states that H-M is not used because of the lack of reified generics, which
is completely irrelevant. (Hint: type systems perform analysis at compile
time; "reified generics" means having type arguments available at run-time.)
H-M is not used because it is not compatible with subtyping or method
overloading, which are both critical for Java interop. There is no particular
reason that Scala needs to use exactly the H-M system.

------
weddpros
I like Scala. It's a JVM language, it's extremely powerful, but maybe it's too
powerful for us mere mortals.

Eclipse allows very fast compilation times, but when I tried sbt, I gave up
because I CAN'T wait for compilation: we're in 2013, I'm using a quad core at
3.4GHz, 12GB of RAM and SSD, so I'm not ready to wait. Eclipse allows fast
incremental compilation.

Scala's type system is very rich. I don't know if there exists any type that
can't be expressed in Scala. Since I don't know if such a type exists, I don't
miss it. But that's probably too much, and in the end, idiomatic Scala
emerges: some libraries use the type system in an idiomatic way. It's working,
but understanding method signatures turns into a nightmare. Then you must
learn the arcane of Scala to understand how the library works.

However, if YOUR Scala is simple enough, then the language can be cool, cooler
than Java, and productive. Can be mixed with Java, runs fine for J2EE...

~~~
chrismonsanto
> I don't know if there exists any type that can't be expressed in Scala.

Scala has a very rich type system, but let us not get ahead of ourselves--
Scala, being non-dependently typed, cannot type many useful programs.

For an example of a useful dependent type, consider giving division the type
Number -> {x : Number | x != 0} -> Number. Giving division the type Number ->
Number -> Number is similar to how older Javas would type List<String> as List
and require all get operations to cast from Object--in both cases, the type
system is unable to guarantee that your program won't crash.

If you want a glimpse of the state of the art of programming with dependent
types, try Agda[0].

[0]:
[http://wiki.portal.chalmers.se/agda/pmwiki.php](http://wiki.portal.chalmers.se/agda/pmwiki.php)

~~~
TylerE
How does that actually work? Does that "type" basically compile down to an
added n != 0 check at runtime, or is there more sophisticated dataflow
analysis/theorem proving going on?

~~~
chrismonsanto
It depends. In the most general case, you have to prove that the program you
have given has the type you have asserted. This is similar to proving a
mathematical theorem. Generally, the computer will assist you in this endeavor
--for example, if you want to prove that A implies B, and A and B are linear
inequalities, this can be solved automatically.

~~~
Locke1689
_Generally, the computer will assist you in this endeavor_

Kinda. Let's be honest: in production this often turns into a pain in the ass.
There's some value in dependent typing, but providing evidence that
concatenating UTF-8 strings is associative is not one of them.

~~~
bootily
That is hilarious. And I also hope your joking.

~~~
chrismonsanto
That user is not joking, but note that you generally prove that string
concatenation is associative _once_ , not every time.

------
Ygg2
What is my biggest gripe theoretical gripe about Scala is that Trait order is
important! Because traits can override common function. A class that is e.g.
Ball with traits Shiny and Red is NOT the same as e.g. Ball with traits Red
and Shiny. Why? Why complicate testing to a point where you need not only test
traits for correct behavior, and not just composing of Traits, but even the
order in which they are composed? Why?! Why complicate it so much?

Note: It's been a while since I've seen traits, this might have changed for
better.

To me Scala is essentially if Java, Haskell and C++ went to a wizard to have a
child. The result is a magical mess. I seriously think that Scala has at least
twice as many concepts as C++ and same if not greater number of really weird
edge cases. I don't want to keep Scala in my mind, no more than I want to keep
Necromicon.

~~~
pkolaczk
As long as your traits are independent, the order does not matter. Anyway, how
do you imagine this could be done better? For order to not matter, the
linearization could not be possible and we'd end up with something much more
complex and ugly like multiple inheritance in C++ with all the diamond
inheritance problems, etc.

~~~
Ygg2
Don't have an answer right this minute, but I think eschewing/forbidding
variables in trait would prevent the most obvious such collisions.

If you can't override variables, you can't silently change the structure to
depend on trait order. You'd have to explicitly state order.

PS. Of course if you have several same signature methods that call super,
which is generated depending on order, same problem persist. So, forbidding
variables and calling super elements should deal with most "magical"
interactions.

~~~
pkolaczk
If you can't call super nor use variables then this takes quite a lot of power
from traits. IMHO being able to stack many traits one on another is a nice
pattern.

~~~
Ygg2
Yeah, you trade power for easier testing and unforseen side-effects for
determinism. IMO it's worth it.

------
eranation
I tried learning Clojure, I really did, and I have to agree, the syntax is
simpler, but I can't really read Clojure or code in Clojure the way I do in
Scala, I don't know why. Whenever I read articles about Scala, I keep finding
it amusing, prehaps this is because I had experience with Java, but for me
Scala is a life saver, can't go back to Java after this. And I won't go back
to Ruby, Python or JavaScript. So I can't really understand what these
articles try to achieve, it's like the "don't buy bitcoin" articles, not sure
what is the goal. If you don't like Scala, thanks for sharing, but I don't see
how it affects me, I will still continue using it as my go to language until I
find something better (there are contenders, Kotlin, Ceylon, Dart, TypeScript,
and my favorite now - Nimrod, but there is still a big gap for me to fully
switch)

So for someone like me who wants a statically typed language (there goes Ruby,
Python JavaScript, Clojure), who thinks Haskell is too academic to be really
productive (I have to think too much to get things done with it) and who don't
get what is all the rage about Go (perhaps because I'm not a system
programmer, in any case I still don't get it, sorry) This leaves me with no
other options (except C#, which I would probably use if it was really
portable)

Scala is not perfect, but I feel more productive with it than with any other
language, if anyone who never used Scala will decide not to even try it
because of this article, I wish them luck, but I doubt this will be the case.
for those who use it, they will still continue.

So I really don't think I understand what is the point of such an article. Try
the language for yourself, if you like it use it, if not, and you have a
choice, don't.

p.s. for all those poor bastards who are forced to use Java at work, Scala is
by far a gift from the Gods, so it helps to keep things in proportions, one
man's source for a rant article, is other's source of means to finish work at
5pm and go back to the SO and kids. (they would go back at 1pm but their Sun
Certified Java EE team lead brain will explode if they will use Clojure, with
Scala your EJBs or Spring code can still look recognizable, perhaps a bit more
pretty) p.s. did I forgot to say I love Scala?

~~~
jaxytee
This times 1000. I have been using Scala for the past 3 months in a play
framework app that serves json. Today I had to write some quick Java for an
Android client, and was quickly reminded how much freedom Scala's
expressiveness gives you vs Java old cruft.

I mistakenly wrote a Java anonymous inner class that called a closed over
variable from the outer scope like one would do with Scala closures. Of course
the Java compiler threw an error because I didn't mark the variable as final.

When programing in Scala, one never has to deal with such low level rigidness.
It just let's you get shit done.

~~~
saryant
Well, be careful with those closures. Scala's compiler won't (yet) throw an
error if you close over a variable from the outer scope while operating on a
Future.

The Scala team does have a plan to fix this though. Of course, if you aren't
operating asynchronously or you're only closing over immutable values it
doesn't matter anyways.

------
JulianMorrison
Problem: author is pining for Go, and doesn't know it.

Solution: author should abandon the JVM ecosystem and use Go.

\- Fast compiles.

\- Ultra simple, non extensible syntax, yet not verbose in practise.

\- The code you see is 100% of the code.

\- A culture of implementing the simple algorithm.

\- Stable, with version compatibility guarantees.

\- Nobody is trying to make the types jump through hoops, so the type
inference works.

~~~
cryptos
I tried Go for the same reasons. It looked to me like a statically typed Java,
but in practice it was not the best experience. The Code is not more
expressive than Java, but you lose all the good libs and tools from Java. Most
annoying was the in ability to create concise mocks, because you cannot
implement interfaces at runtime with Go.

~~~
cryptos
I wanted to say: "it looked to me like a statically typed _Python_ "

------
virtualwhys
Scala after 2 weeks = 1 star Scala after 2 months = 3 star Scala after 6
months = 5 star

Show me a statically typed language on the JVM that trumps Scala -- it doesn't
exist.

Show me an ecosystem in that statically JVM based language that trumps that of
Scala (Akka, Play, Slick, sqltyped, Squeryl, Spray, Scalatra, Lift, Blue Eyes,
Unfiltered, etc., etc.)

Yes, compile times are a hassle (for deployment that is, incremental
compilation combined with sub projects are plenty fast, usually around 1-3
seconds, it's a non-issue).

Yes, IDE support is nowhere near that of Java's, but it has improved immensely
during the past 2 years. Either IntelliJ or Eclipse + ScalaIDE do the trick,
am happy on the latter here.

There are only two kinds of languages: the ones people complain about and the
ones nobody uses \--Bjarne Stroustrup

~~~
asdasf
I had the opposite experience. I went into scala very optimistic, and
initially would have rated it 4 star to stick with your rating approach. But
after a month it was down to 3, then another month it was down to 2 and we
were investigating alternatives.

------
lemmsjid
I'd say a lot of the critiques are fair but quite exaggerated. I work on a
large Scala codebase and yes, the compile times for a fresh start across the
codebase are very long, but TDD-type loops are very short, because you're
generally waiting for two files (your test target and your test code). Still,
the compiler performance in Scala is perhaps my chief criticism, though hardly
a show-stopper. As codebases in any language grow, you tend to have increasing
challenges in the time it takes to fire up your environment.

The critique about excessive and opaque operator use in libraries is fair,
though I think it actually exposes an interesting philosophical issue. Scala
is unabashedly written to be a flexible language. This is in opposition to
Java, which was written to be a very strict language in terms of
expressiveness on the part of the developer (it's perhaps the most strict of
the languages I've worked with, hence it being my example). I personally think
a lot of criticisms leveled against Java's verbosity and inflexibility are
unfair, by virtue of the following: Many incredibly successful and complex
open source projects are written in Java. While you could say this stems from
Java's enormous popularity, one interesting property of huge Java open-source
projects is that I can usually crack open the code and quickly get a sense of
how I could contribute to the system without breaking it. While other
languages often do a better job of giving me a sense of how the system works,
I generally have much trouble with extensibility unless it's Java. This I
believe is because Java was designed from the ground up with the goal of
limiting individual developer expressivity in favor of imagining large
development teams with limited cross communication.

So--I am far less anti-Java than most. But I am a big fan of Scala. Unlike
Java, Scala was written to maximize developer expressivity. While writing Java
can feel like putting together a legal contract, writing Scala can feel like
creating a poem. I'm not making a value judgement in either direction there--I
feel that poetry is a good metaphor, because things in Scala tend to fall
apart in the reading department. One of the easiest things to do in poetry is
to lose the reader--a great poet can put an incredibly complicated
multilayered concept onto a small amount of paper--and require a graduate-
level understanding from the reader to understand it. Similarly, one can very
easily make Scala into an exercise in unpacking

So isn't that a bad thing? Why am I a Scala fan? Going back to my initial
praise of Java--Java is so simple and predictable that it's really easy to see
how the plumbing works. But because the plumbing must be laid out so
meticulously and in every situation, it is often hard to see how things work
at a high level. You can't see an architectural sketch in Java, you can only
see endless classes in endlessly nested subdirectories. This is a very low
level of abstraction, and helps the layperson (such as someone approaching a
new open source project) build up an understanding from the base elements. But
what's lacking is the high level abstraction.

Outside of programming languages, almost every knowledge discipline has a high
level abstraction language--sometimes multiple languages. Usually the
abstraction language is opaque to newcomers, and frustratingly so. Examples
are the mathematical notations of various disciplines, the jargon-laden meta-
language of historical theory/literary criticism, and what is popularly known
as 'legalese'. But even less high falutin' fields have similar languages--
listening to sports fans talking about what's happening can be quite
mystifying to me, given all of the shorthand they're using. Similarly people
talking about pop culture in areas I'm not familiar with.

These ubiquitous high level languages usually share two important facets:
first, in a few lines of text/speech, you can pack in many books' worth of
concepts. Second, unless someone has read those books, they will have no idea
what you're talking about (or in the case of pop culture jargon, having spent
the requisite hundreds of hours watching movies). Scala is trying to provide a
language that can express the low level plumbing as Java can, but also that
can express the high level meta-language. In doing so, it opens itself to the
same type of criticism that mathematical notation can receive--opacity.

The pitfall, then, of Scala library developers is to create a high level meta-
language (a DSL), that doesn't have industry acceptance. This is tantamount to
mathematicians who create their own notation to establish proofs--such proofs
can be completely unreadable to their colleagues. But this isn't a criticism
that should be leveled at the idea of notation period--it's a matter of people
learning to accept useful obfuscation (where jargon can reduce textual size
and increase understanding) and reject useless obfuscation (inventing your own
dialect of shorthand and forcing your readers to learn non-transferrable
knowledge to understand what you wrote).

Because they are working with such a flexible language, and one that is
targeted at building high abstraction languages, Scala library developers need
to think of their audience--terseness by itself is not useful, unless you're
writing throwaway code. If you're going to unleash a DSL on your reader, make
sure it's in a real dialogue with the reader's expected level of knowledge
with regards to how such a DSL should be structured in terms of what the
symbols should mean and how they fit together.

I don't know how the Scala story will end, but I do believe that it is one of
the few languages that reaches for an expressivity goal that needs to be
achieved by at least some future language. Its reaching opens it to much
criticism, and rightfully so, but I appreciate it for its ambition.

~~~
MetaCosm
Great comment. I agree with nearly everything you said, but where I end up is
the polar opposite. I can't stand Scala for all the reasons you mentioned.

The poetry thing is really dead on -- when Larry Wall spoke of Perl -- he said
he explicitly wanted you to be able to write poetry with it. This led to the
write once, read never reputation of Perl... that Scala is quickly stealing.

Scala is on my "will not work with" list of languages/technologies -- which is
generally limited to old languages/tools that I have experience with (like
Progress 4GL, Mumps, etc), but don't want to touch. It is a maintainability
blackhole and generally horrible (to me) to work with, despite being fairly
comfortable with the core (1400 or so hours billed).

~~~
kvtrew76557
I've developed and maintained multiple large systems in a team using various
languages. I would _much_ rather maintain a system written in Scala than
either Java or various scripting languages we've used and the view is shared
by the whole team. It's far less verbose than Java and very maintainable
compared to other very large systems written in scripting languages.

~~~
MetaCosm
We simply disagree on this. I would rather use almost anything else except the
random DSL wasteland that is Scala. Even Ruby or Python (with the horrible
GILs) is preferable.

The groups I worked with made different determinations than your team, but if
you guys love it, enjoy. Seriously, if you find a technology your whole team
loves, you are KILLING it.

Both companies I worked with have since dropped Scala (after literally
hundreds of thousands of dollars spent on the attempts) entirely internally
due to maintenance and talent acquisition issues.

~~~
trailfox
_I would rather use almost anything else except the random DSL wasteland that
is Scala_

In my experience very little Scala code uses DSLs. Learning Scala isn't that
tricky for anyone who knows Java, which is a pretty big pool.

~~~
pivo
That was not my experience with Scala. Every library we used had its own DSL
and that made the code really hard to read. Maybe things are different now,
but I'll bet that was a lot of people's first experience with Scala. It's what
turned me off to the language, even though I did like using the standard Scala
library quite a bit.

Edit: It was two years ago so other than Lift and some SQL DSL I don't recall
which libraries we were using. I do recall wishing I hadn't taken that job.

~~~
nimbix
My "favorite" part of Scala was half a dosen DB libraries each re-implementing
SQL as a DSL.

~~~
trailfox
C# does that too. It's called LINQ and it's very popular.

~~~
nimbix
Are there a number of slightly different and incomplete variants of LINQ, like
there are SQL DSLs in Scala? Because if not, then LINQ is "the right way" of
doing this kind of thing. And if I remember correctly, LINQ is also useful
outside of the DB domain, for things like filtering arrays and so forth.

I once read an article about how Java programmers can hold a conversation on
the topic of upsides and downsides of multiple dependency injection containers
while C# programmers only have one available and have nothing to say on this
topic. That article concluded that having one "good enough" solution can often
be better than having multiple slightly different and incomplete ones, even if
each has its own strenghts, and I'd say the same is true when it comes to the
C# LINQ vs. Scala SQL DSLs.

~~~
trailfox
C# has various options (see: [http://stackoverflow.com/questions/671231/linq-
nhibernate-al...](http://stackoverflow.com/questions/671231/linq-nhibernate-
alternatives-equivalents))

The Scala equivalent is called Slick, and it's the only SQL DSL that
approaching anything near widespread use. I fail to see how incomplete
projects on GitHub which happen to be written in Scala are relevent to this
discussion.

------
kvtrew76557
Overall this is a very weak and one-sided blog post. Even a simple search
would have answered his questions about why Scala doesn't use Hindley Milner
type inference:

[http://www.scala-lang.org/old/node/4654](http://www.scala-
lang.org/old/node/4654)

How this post got voted up to the front page really makes me wonder. "Clojure
programmer gives Scala 1 star", what next "Ruby programmer gives Python 1
star"?

------
dham
Scala can be summed up in one issue.

[http://play.lighthouseapp.com/projects/82401/tickets/98](http://play.lighthouseapp.com/projects/82401/tickets/98)

I loved Play 1.x(early adopter also) but I have since moved on. I gave Play 2
a solid chance. Scala programmers seem to turn everything into some kind of
academic paper.

~~~
eropple
I've been a critic of Play 2 on a number of occasions on HN but I don't
understand the complaint. What is causing you to create URLs with trailing
slashes?

~~~
dham
What is causing you to create URLs without trailing slashes? 99% of all web
frameworks allow for optional trailing slash. Go to any website. A url with or
without a trailing slash typically works, it either redirects to no trailing
slash or just renders the same page.

~~~
eropple
What is causing me to create URLs without trailing slashes is the proper use
of Play's route-to-URL mapping system. I don't emit trailing slashes because
Play doesn't.

------
f7t7ft7
> The workflow I ended up with was to write a function without any type
> annotations. Ignore all the red lines of the IDE’s confusion. Compile the
> code. In the output look for a warning about (Long => Int) return value
> being ignored in a function returning Unit. Copy (Long => Int) into my code
> as the return type annotation of my function. Compile again.

That sounds like the most stupid way you could do things.

------
sandGorgon
Question - the job/hiring post on hen for November has many positions for
clojure and one definitively for Scala. Here, I see references to investment
banks using scala.

Has scala become a readable alternative to java, while most of the future
focus is on clojure? Does anyone know how real life performance compares
between both.

From my viewpoint, scala is in use at several banks and Twitter - clojure
doesn't really have a big name advocate behind it. From a startup standpoint,
isn't talent/hiring an issue?

~~~
korny
There are some big places using clojure - the Daily Mail uses clojure heavily
for it's website, as do SoundCloud; also, like Scala, it's used internally at
some financial institutions - CitiBank have some clojure, and we've been using
clojure at IOOF (an Australian superannuation company).

Performance is probably the last thing you need to care about when choosing a
programming language for most businesses - unless you are doing hard-core
analytics or handling huge scale, you just won't hit the sort of performance
problems that are solved by a faster programming language (as opposed to a
faster algorithm or architecture).

It really frustrates me that people _still_ put such weight on low level
performance. In 1997 I had people saying "don't use Java, it's performance is
far worse than C++". It was mostly untrue for business problems then - and
computers are many orders of magnitude faster now.

~~~
puredanger
Some other examples are Prismatic, Runa (recently bought by Staples), Climate
Corporation (recently bought by Monsanto), Twitter (via acquisition of
Backtype), etc. And there are a number of other big name companies very
quietly using it to just get stuff done.

------
mikkelewis
I think Scala is great as long as you stay on the road and not end up in the
deep depths of academic hell (i.e.
[http://blogs.atlassian.com/2013/01/covariance-and-
contravari...](http://blogs.atlassian.com/2013/01/covariance-and-
contravariance-in-scala/)).

I should say one thing however:

I'm using Scala because of Akka. An extremely powerful library that does a
good job of hiding the complexities while still allowing you to be flexible.

~~~
bcoates
That's a gratuitously category-theoretic explanation, all you need to explain
covariance and contravariance is is-a.

An immutable List of Foos is a List of Bars if a Foo is a Bar. A function
taking X and returning Y is a function taking A and returning B if A is a X
and Y is a B.

It's just answering the question "Can I use type relationships to guarantee
that I will have no run-time conversion failures?"

~~~
evincarofautumn
T is covariant (positive) if A ≤: B ⇒ T<A> ≤: T<B>. T is contravariant
(negative) if A ≤: B ⇒ T<B> ≤: T<A> (i.e., the other way around). Pretty
simple stuff.

~~~
pkolaczk
It is easy to remember if you think of it:

\+ (covariant): the type can be cast to some _broader_ (more general) type

\- (contravariant): the type can be cast to some _narrower_ (more concrete)
type

------
pkolaczk
I agree partially with the critiques.

The things I don't like in Scala:

1\. Compile times. It _is_ a problem for big projects. SBT / FSC helps quite a
lot, but IMHO it is still not enough. I hope they get them much better in
Scala 2.11. Also performance and correctness of the IDE plugin typechecking
could be better, so I don't have to compile that often.

2\. Lack of backwards binary compatibility. Source compatibility is ok, but
selecting the right version of all the libraries is pretty painful, especially
if the authors of the library didn't make the packages (yet) or they haven't
been deployed to maven repo, etc.

3\. That some elegant code constructs come with sometimes huge runtime
performance penalty. It got much better recently (e.g. for loops are as fast
as while loops now in Scala 2.10), but I feel it could be better. Again - hope
Scala 2.11 addresses those concerns at least partially.

The things I don't agree with the OP:

1\. Documentation - it is awesome.

2\. Syntax flexibility - many times DSL is a better way of expressing things
than just a bunch of methods, and easier to learn.

3\. Tooling - good enough now, and improving fast.

4\. Type inference - I consider it good enough, albeit not perfect. And types
in method signatures add a lot to code readability.

There may be some languages that have better IDE support, faster compile
times, better type inference, richer type system etc. But none of them
supports full feature set of Scala, particularly all the available libraries.
So IMHO taking every single feature out from Scala and comparing it let's say
to Haskell or ML is ridiculous.

------
donjigweed
Yegge said it best 5 years ago. [1]

"The... the the the... the language spec... oh, my god. I've gotta blog about
this. It's, like, ninety percent [about the type system]. It's the biggest
type system you've ever seen in your life, by 5x. Not by an order of
magnitude, but man! There are type types, and type type types; there's
complexity...

They have this concept called complexity complexity<T> Meaning it's not just
complexity; it's not just complexity-complexity: it's parameterized
complexity-complexity. (mild laughter) OK? Whoo! I mean, this thing has types
on its types on its types. It's gnarly.

I've got this Ph.D. languages intern whose a big Haskell fan, and
[surprisingly] a big Scheme fan, and an ML fan. [But especially Haskell.] He
knows functional programming, he knows type systems. I mean, he's an expert.

He looked at Scala yesterday, and he told me: "I'm finding this rather
intimidating.""

[1] [http://steve-yegge.blogspot.com/2008/06/rhinos-and-
tigers.ht...](http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html)

------
fat0wl
I've been using Scala just to learn Play framework (I know I could use Java
but I thought I'd be adventurous).

I think in truth, though, if there were a web framework in Clojure as well
received as Play I would be bounding down that path instead. Clojure seems to
be where a lot of the JVM interested is heading yet we're not there yet for
some reason.

~~~
jadyoyster
I've been wondering - having never used a web framework except for some RoR -
what people miss in the idiomatic Clojure way of doing web (composing
libraries like Ring, Compojure, Enlive etc). Care to share?

~~~
danneu
I was a full-time Rails developer until a crescendo of disillusionment finally
cajoled me to learn Clojure.

I don't really know that I miss anything. The things I might've thought I'd
miss are the things that ended up souring the taste of Rails.

Having to come up with my own abstractions or recreate familiar conventions or
set up a database were areas where I had to cut my teeth, but I also had to
cut my teeth on Rails when I was learning it.

Rather than missing anything from Rails, I find myself using Rails'
conventions as a loose model and then simplifying it. For example, my
"templates" are now just functions that render html. My "layouts" are just
functions that get applied to templates. I don't need to read Rails' template
rendering guide to come up with a hack. Instead, modifying my templating
system is trivial and obvious.

~~~
nikatwork
Thank you for this comment. I'm starting a hobby webapp project and wanted to
try Clojure but was probably going to choose RoR out of fear. Now I'll use
Clojure :)

Would be interesting to see a blog post demo'ing your workflow.

~~~
adambard
Not the parent, but I went through a phase of blogging about Clojure earlier
this year: [http://adambard.com/blog/Getting-started-with-Clojure-web-
ap...](http://adambard.com/blog/Getting-started-with-Clojure-web-apps/)

------
wiradikusuma
To be honest with you, I use Scala as a better Java. Which means I still code
imperatively (and use null instead of None) but with less noise (semi colons
etc).

But, esp when working with collections, I take advantage of Scala's features.
It's not perfect, but it works wonderfully. I can always revisit/refactor my
code again later.

~~~
ffk
Using null instead of None means you are more at risk of hitting a NPE.

Here are a couple examples:

myVar match {

    
    
      case Some(val) => doSomething(val)
    
      case None => handleNone()
    

}

myVar.getOrElse("else")

In both of these cases, we eliminated the possibility of a NPE through the use
of a language feature. :)

(edited for formatting)

~~~
EdwardDiego
> Using null instead of None means you are more at risk of hitting a NPE.

I think he's aware of that - he said he's using Scala as a better Java, what
would Java be without the odd NPE?

------
eklavya
I am seeing just too much criticism for Scala and the coherent theme seems to
be - "I didn't take time to understand the language well and then my pride got
hurt as I couldn't understand it's constructs. So Scala is shit and too
complex."

I am not from CS background, but I took time to learn it and by far it's THE
most natural and expressive language I have found AND I don't even know what
functional programming and the theory is, all I know I learned through Scala.

Please guys, let's not project our laziness as a fault of Scala.

------
auggierose
The Scala code I write looks very similar to the Clojure code I write. But has
the advantage of (optional) static type checks.

What I care about is that a language lets me express easily the concepts that
are in my head. Scala does that and because of its type systems makes it even
possible to document these concepts in a mechanically verifiable way (only up
to a certain extent, of course).

------
edem
I feel you. I tried Scala out and after several days I just uninstalled
everything from my computer which was related to Scala. The main reason is
that it feels like some extremely baroque java without any sensible syntax. It
looks like the C sytax but in fact it is not. Return types are sometimes
explicit sometimes implicit. If you try to learn Scala you have to forget
anything you know and learn the over-engineered ways of Scala. And in the end
you don't get anything back which is not accessible in other languaes in a
significantly easier way. You want functional style and easy concurrency? Go
clojure. You want scalability for your webapp with 999999999 visitors per day?
Go node. You want scientific calculations with good library support? Go
python. You want a sensible type system and monads? Go Haskell. Scala just
does not have much to offer in exchange for the terrible pile of contraptions
it forces you to use.

------
chrismorgan
The section on HTTP headers and typing is a little concerning to me. I've been
making rust-http recently and (before I was aware of Spray) I felt strongly
about the typing. So, I'd like to discuss this. Am I wrong after all? Here
clearly is someone that disagrees with me. I think I should probably write up
a long blog post on the topic explaining my reasoning and so forth.

rust-http is, at present at least, rejecting the standard practice of stringly
typed headers and is using strongly typed headers.

> ... and even types for every ‘known’ HTTP header.

> The known HTTP header part was particularly ridiculous. HTTP headers are
> _defined_ as simple key/value pairs. You’re supposed to be allowed to add
> arbitrary headers. You’re not supposed to be constrained by the framework
> you’re using not having any support for CORS yet.

He has taken a strong position against this strong typing; I take a similarly
strong position _for_ such strong typing.

Yes, HTTP headers are defined as simple key/value pairs. But headers are _not_
text; they are _data_. XML is defined as text. Should we use regular
expressions to work with it? (True, it also has the DOM defined. But HTTP
headers _also_ have a grammar defined—it just happens to include the
admissibility of extension headers.)

HTTP is a serialisation format for messages; messages made up of computer-
readable data, not text.

I wrote a handful of paragraphs about this subject at
[https://github.com/chris-morgan/rust-http/issues/1](https://github.com/chris-
morgan/rust-http/issues/1) where using a map instead of typed headers was
suggested.

As I also note there, I would not attempt such a scheme in a language like
Python (my primary language for some years) because its type system is not
well adjusted to something like this; I am certain it would cause many
problems and feel it likely it would cause more than it solved. But in a
language with a solid type system capable of expressing these things, taking
advantage of it should lead to a faster, more correct program.

In the end, I believe strongly typed headers are a good thing to have (it will
actually make most code distinctly nicer—e.g. ``response.headers.date =
Some(now())`` instead of ``response.headers.set("Date",
now().to_http_header())``). The implementation of the scheme in rust-http is
certainly not perfect yet; I'm not happy with it at present; I'm expecting to
turn the extension headers into a trait object, and I've even considered crazy
ideas like allowing users of the library to make their own header collection
(request.headers and response.headers) types—that would allow custom headers
to be made first-class citizens but could lead to compatibility problems.

Still, I don't want to make something that I believe should be the best HTTP
library around and find that people hate to use it. What do you think about
this header matter?

~~~
EpicEng
But what practical problem is such a scheme actually solving? If I write

    
    
        response["headre"] = ...
    

I have a bug, sure, but an obvious bug that will be fixed very quickly. With
this type system I am now limited in an annoying way. I don't get it.

~~~
pcwalton
> I have a bug, sure, but an obvious bug that will be fixed very quickly.

People say the same thing about null pointer exceptions, but null pointer
exceptions are a huge problem in practice. Every bug is "obvious" in
retrospect.

~~~
EpicEng
No, this is not the same as a null pointer. Null pointers are typically much
more sneaky, this line means the header will not be written and the error is
right in your face.

I do understand the desire to prevent these sorts of errors at the language
level, but not at the cost of functionality. I don't agree with this one, but
I do (for example) appreciate libraries such as the STL which (hopefully)
prevent that pointer issue you brought up (and more). The STL doesn't (often)
force me to work around silly limitations though.

Does this library provide for creating arbitrary headers in some other
fashion? If not, why?

------
cryptos
Method names like ~, %, %% or #> are terrible in Scala! This should be
generally banned as bad practice. There are too many developers creating
obscure and unreadable code with such method names.

I even thought to create readable adapters for common APIs like SBT API.

------
tobyjsullivan
If anybody really wants to learn Scala, I'd recommend starting with the video
lectures on Coursera for the course Functional Programming in Scala.

------
dgeorgiev
A disagreeing comment wrt OP. Hope it is useful to some.

On the library criticism ... Well, pick better libraries, use java libraries,
or roll your own. You have twice the choice you have in java. Is that bad, or
good?

Yes, there is immature stuff. Well for the lawyer rate you are charging,
should be able to separate that from the good bunch?

The complexity - In my experience, learning curve is gradual in that you can
pick new features when you need them. You can pretty much get by writing
javesque scala with a bit of closures in the begining. Then take mixins, then
take the hardcore stuff when you feel comfortable.

About the build system - here I was surprised. You seem pragmatic, why use it?
To me SBT is totally useless because it solves nothing existing tools do not
solve. The Scala support in Maven is perfect, and i feel so productive and
mature in it these days, I would never trade unless there is a very strong
selling point (meaning more free time for me to drink beer, whatever) If you
don't like Maven, code in Ant. But using a build tool which is a general-
purpose language? I agree with you. Baaaaad idea

------
geoka9
Having used Scala for over a year, I can say it is a mixed blessing for me.

On the one hand it's an improvement over the verbosity and rigidity of Java.
And often it is fun to write in (lots of clever tricks you can use and feel
good about... until you have to come back to the code several months later).

On the other hand, I absolutely hate to dig into Scala code written by others.
To me it feels like C++ all over again. There are so many concepts in the
language that more often than not you find your knowledge of the language
lacking, and have to put the task at hand on hold to brush up on your Scala
skills. If there are more than a couple of (Scala loving) codevelopers on the
project, you end up spending more time learning about the language than
actually using it.

So, to sum it up: I would use Scala if I absolutely had to use JVM and I had
control over the the subset of the language used in the codebase. Otherwise,
I'd pick something else. Thankfully, there are saner alternatives to JVM these
days when it comes to high level/static typing/high performance (e.g. Go).

------
virtualwhys
Agreed, SBT plain sucks _without IDE support_ to guide you. If you have IDE
support for your /project/*.scala SBT file(s) then the various symbols and
conventions make sense as you can click through to _discover_ the library --
huge difference between that and blindly typing away in a text editor; the
latter is a recipe for insanity ;-)

------
nimbix
They say that for a successful c++ project you need to first define which
parts of the language you're not allowed to use. For Scala projects it's even
more so. And you can only hope that all the libraries you'll be using provide
some sane method names that map to all the insane operators they invented to
do the same thing.

~~~
hopp_check
To this point, I've heard "Scala is the C++ of Java."

------
phazmatis
My problems with Scala:

1) src/main/scala/com/thingy/actualthingy _JUST_ to get to the root of your
code. 2) Recompiling/restarting is slow because liftweb and other frameworks
are overly complex. 3) I'm 90% sure it would be possible to create a PRY-like
debugging tool that runs your code in interpreted mode and drops you into the
REPL at a certain point in your code. And yet, it'll never get built because
Scala hackers are stuck in the halcyon java days of 1998. 4) Variable names
first, types second = okay, now you're just being different for the sake of
being different.

That said, it seems like if you use scala as a more concise java with some
handy functional syntax thrown in, you can make something that isn't terrible
for future maintainers.

~~~
saryant
1) You don't have to do that, Scala doesn't enforce the folder/package
hierarchy that Java does. Moreover, you can use any folder hierarchy you want.

2) Compiling Scala is slower than Java (sometimes much slower) but that's not
the frameworks' fault. scalac is just slow, though getting better.

3) This does exist. In fact, it's built into the language. You can also use
"sbt console" to load a REPL with your entire project in the classpath.

4) As the other reply said, type annotations aren't required. In that light,
Scala's syntax for type annotations makes sense.

------
thomasfl
I thought HyperTalk was killed by Apple, but a quick search reveals several
open source implementations of the programming language. It has been the
easiest programming language to learn in my experience.

------
leokun
> This issue reached its pinnacle for us when we were unable to figure out how
> to replicate the magic response composition syntax used by Spray to abstract
> away the addition of CORS headers to HTTP responses.

I'd just put any kind of application, whether built in Scala, node.js or Go or
ruby on rails behind a nginx proxy and use that for setting the headers. That
simplifies a lot of things. I hope your HTTP headers aren't really so dynamic
that you need to build software that changes them so much, especially not for
a RESTful application.

~~~
nl
Say you are building a redistributable app with Javascript clients. People
will deploy in behind Ngnix, Apache, IISm ad sometimes with nothing at all.

The _last_ thing you want is to make the deployment harder.

------
jongraehl
Horribly misinformed. Author didn't learn basics of the language - "val" vs
"def" is very fundamental - constant vs. function. Scala does not use Hindley-
Milner.

Legit issues: compile time (of course), library docs (maybe), bad HTTP header
API (maybe), tooling (maybe). I thought the automatically generated (doxygen
style) library docs were fine when I was playing with Scala two years ago.

------
gesman
Scala looks sexy, sort of like weird haircut.

But once haircut fascination is over - people expect you to do mundane tasks,
like cook food or take out the garbage. Or they won't pay you.

And then you realize that when Scala cannot do what you want - you can always
revert to Java.

And then you realize that you don't really need Scala-ing if you can do the
same stuff in Java or any other strongly typed language.

~~~
lmm
>And then you realize that you don't really need Scala-ing if you can do the
same stuff in Java or any other strongly typed language.

That's the turing completeness fallacy. Why not just write everything in C?
And java's types are inadequate for doing really generic methods - how would
you go about writing scalaz's "sequence" in java?

------
CmonDev
"My theory is that it was designed to experiment with advanced type and
language features first, and only secondly became a language intended to be
widely used." \- I have same feeling about F# sometimes - OCAML is cool but
too academic to be approachable.

~~~
asdasf
>OCAML is cool but too academic to be approachable.

Can you give an example of what you mean? I used ocaml for a few years, and
never encountered anything I would consider academic at all, much less
unapproachable.

------
knodi
This is my view on scala as well. I used it for one project and will not be
using it again.

------
AKarimi
It's a little late to talk about Scala like that. There are very nice
improvements on each of those topics you complain about. Of course still there
are many works to do but for now there is no other language with such
potential IMO.

------
dkhenry
So I am curious what npm gives you that sbt doesn't. I have heard it a few
times how much better npm is but i haven't seen anything it does that sbt
doesn't

------
taude
As someone looking into learning a different JVM language, and who has started
reading Scala in Action, I find this article and thread very useful.

------
kul_
If nothing, at least i completely agree with complete disregard to
compatibility point. Be it Scala itself or driving frameworks like Play.

------
andrewcooke
_something weird with attaching anonymous functions to method calls_

that's still a thing? i thought i was just being dumb back in the day.

------
joostdevries
Programming languages are very much a matter of de gustibus. So I respect the
writers experiences. But I have a slightly different perspective.

Let me first say where I'm coming from. I like: a static typing. b support for
FP and OO c targeted for JVM.

Compile times It is my experience that compile times are not that bad if you
use the support by SBT for continuous compile-deploy-test. Have a look at
Typesafe Activator to get a feel what they're moving towards.

Libraries and community I do agree that some frameworks, like Spray f.i., tend
to overdo the concise DSL aspect. This seems to be especially prevalent with
Scala developers coming from the academic world of monads. Or with a strong
tendency to show of how clever they are to the detriment of usability. Scalaz
had a strong similar tendency. I have noticed that frameworks like SBT and
Scalaz are de-emphasising unpronouncable ungoogleable unintuitive operators.
So far I have hope that the Scalaz community will veer away from this. To a
certain degree every language community develops a culture about good vs bad
code. Twitters Effective Scala guidelines are a wonderful contribution.

Magic syntax I've been using the Play framework for webapplications. And in my
experience that is largely a pragmatic tool where I can just get things done.
My main criticism would be that sometimes new features seem to be not very
well tested. F.i. multi project support did not really work for quite a few
versions. That shouldn't take up much time. I hope they address that.

Type inference Coming from Java I like Scalas type inference. Although the
compiler feedback can sometimes still be challenging. There has been great
work in compiler messages giving advice on how to fix mistakes. F.i. the well
known mistake of forgetting the = between a function declaration and
implementation. But there are still hairy situations. If you've ever had the
infinite recursion type error (being addressed in newer version of the
language) you know what I mean. Or using the json parser combinators in the
Play framework with classes with one attribute f.i.

Other issues he mentions: \- build tools. This has significantly improved
since Typesafe started. I'd say that before that Scala wasn't suitable for non
academic use. There are still improvements to be made like speed, usability of
SBT, maturity of the Eclipse based Scala IDE... \- repetition of case classes.
I have no idea what is meant with that. I think that writing a model of your
domain in scala is a truy joy compared to java. And pattern matching and
standard marshalling/unmarshalling to json etc is great. \- the language being
inaccessible and experimental. This is not my experience at all. Like any
language it takes learning. But if you're looking for a language that supports
both FP and OO I find it very coherent and well thought out. I'd say beautiful
even. For me the coursera courses on FP with Scala and Reactive programming
with Scala have been the critical power boosts in becoming proficient enough
to make the transition from hobby interest language to professional everyday
tool. \- 'if you want true strong type systems use Haskell'. To me the
'impurity' of FP in Scala is it's strong suit. On the one hand for getting
stuff done and on the other for using the vast ecosystem of JVM libraries and
frameworks. Also I think that the writer will encounter quite a few
inscrutable operators and overwrought type systems (like his complaint about
Spray) in the world of Haskell.

To finish up I'd like to state what I like about Scala: \- FP in the real
world of web applications and mutable state. Accessibility to colleagues who
come from OO & Java \- Well thought out coherent language. Especially in
combination with the Coursera courses I have just become a better programmer
and system engineer. \- Good interoperability with Java frameworks etc \- good
support for horizontal scaling, near realtime processing, non-blocking
processing etc ie reactive programming.

Some things I have mixed feelings about: \- reinventing the whole Java stack.
It is true that f.i. non-blocking support has a pervasive 'disruptive'
influence. But for me there's great value in mature well know libraries,
server, frameworks that just work. \- sometimes there are very common use
cases that need quite a bit of research. F.i. it's not easy to find out what
the 'canonical' way of processing xml is. \- stability and documentation

MMDV (=My Mileage Did Vary)

------
elchief
Just shut up and use Java. It's fine.

~~~
smegel
And with Groovy as a scripting layer, it's more than fine. Quite good in fact.

~~~
Keyframe
Is Grails as good as they say it is?

~~~
fat0wl
I think it may be but I came to the Java ecosystem to escape RoR.... it seems
we should be able to do better than emulating Rails minus the existing gem
community, no?

I have much more faith in the JVM but would like to see it provide a step
_beyond_ Rails rather than catching up. Play is nice because it is trying to
accomplish this with Akka, though yes I see there are other issues. As
mentioned in another comment, I'm kindof just wishing there was a cool Clojure
framework. Maybe I will try one even there is not so much of a consensus as
there are around these other emerging JVM frameworks...

~~~
adambard
Clojure doesn't tend to do frameworks on the scale of Rails; all the
components exist, but the price for your application only including the parts
you use is that you're more or less expected to write the glue code between
them.

Think Sinatra instead of Rails.

~~~
fat0wl
i suspected this may be more the case, thank you for confirming. and this has
made me nervous, since i don't find sinatra to be all that powerful.

buuuut as retrogradeorbit points out.... the clojure macro system is powerful,
so maybe it lends itself better to this type of setup

------
CmonDev
"serious JavaScript development" \- best oxymoron I have seen in a while!

------
vpatryshev
So, you switched to which language exactly? Sure we can follow a good example.

------
tehwalrus
This is wonderfully written, thank you.

------
ARussell
I think that many of these criticisms, while perhaps valid in some ways, are
unfair. Why single out Scala, when other, more popular languages have these
same issues? The intent of this post seems to be to discourage using Scala on
any project again, but it is difficult for me to discern the proposed
alternative. Is it Haskell? A fine language, but seems to lack the tools that
even Scala has, and it's not on the JVM. Is it JavaScript? Java? I'm not sure
which comparisons to make. So to address each point:

The compile times criticism is probably one of the more valid ones. Was
incremental compilation enabled in Gradle, though? It was only specified that
daemon mode was used.

The libraries and community criticism, I think, is completely unfair. There
are lemons in every community. Part of getting to know an ecosystem is
learning the parts you don't like. For example, I don't think that anyone
should attack the entire Java ecosystem simply because Java EE with its EJBs
exists, or because Struts exists, or WebSphere.

Is the magic syntax criticism specific to Spray and SBT? But I thought that
Gradle was the build system, and that's in Groovy. I'm a bit confused, here.
Again I think this is about picking libraries you find readable, and again I
think it is not fair to judge an entire ecosystem because of one or two bad
library choices.

The HTTP header criticism...is this about Spray again?

Not using Scala because it doesn't have Hindley-Milner type inference is not
fair, either. This seems like an unusual standard for which to hold any
language, really. Is it only ML languages like Haskell that have this?

Really I'm not sure why any or all of these would make Scala an inaccessible
language, or even what inaccessible means in this context. Is it simply that
Scala has too many language features? So should we all go back to BASIC? Or is
Java the answer? But wait, Java is adding more language features, too! Where
do we draw the line? In the Java world, there are so many libraries that
provide the functionality that Scala has baked in. Are using third-party
libraries such as Guava, Project Lombok, and LambdaJ really preferable to
using Scala?

I definitely agree that you can make code unreadable by using too many
language features or libraries, but it should be agreed upon what the best
practices are for a project between its developers. For instance, on a Java
project, everyone might be using JUnit and Mockito for unit testing. Then one
day, a single developer decides he wants to introduce PowerMock or something,
instead. His pairing partner could explain to him why this is a bad idea; or
it could be rejected in a code review or similar. The same idea holds for
Scala, I think. If not everyone understands something like implicit types,
they should be avoided.

------
dancapo
There's a lot that could be criticized about Scala, but that article is a
criticism of the author, for me who actually knows something about Scala.

It starts with a criticism of a build system that is most likely SBT. Now, for
all its strengths, you could not pick an easier target than SBT if you wanted
to bad mouth a piece of Scala software, but what we get is:

* It is slow to recompile the build definition (true, not the most complex build files I ever saw ever took anywhere near that time); * I didn't bother to learn the syntax (or what was going on).

Is that it? If all you have to complain about SBT is this, then you never
actually made even a passing attempt to learn to use it. That doesn't make me
much confident about the author...

Next, the author has been writing Scala code for the past _two weeks_. Scala
is not, I argue, as complex as people make it to be, but it has enough
_different_ concepts than what most other languages offer that you simply
don't pick it up in two weeks, just like you didn't learn your first
programming language in two weeks.

If you come from Java, two weeks of Scala let you use Scala like Java: you'll
produce working software, though not in any idiomatic style. Well, we pick
later on that the team is using Spray, and Spray is a _very_ idiomatic
library. You do have to unlearn many habits to pick it up, and the author
doesn't seem interested in unlearning anything he "knows".

He picks Scala because, hey, there were doing XSL and doing XML processing, so
Scala must be good at it, right? Well, actually, no, but I can see why one
would think that, and also why one would be disappointed that it actually
isn't, but picking the wrong tool doesn't mean the tool is bad: it's just not
the tool for that.

So we go to TDD, where he comes up on Scala awful compile times (which
troubled him with SBT before). That is a problem that Scala community has
faced, and it has produced solutions to that problem. Specifically, it has
adopted SBT, a build tool which can compile incrementally (and automatically
on change), and even execute just the tests that are affected by a change
(automatically as well).

Of course, the author, having chosen Scala, decides to ignore the existing
solutions and picks up Gradle, which supports none of this. Now, Gradle is a
very nice build system, but, again, the author picks the wrong tool and
proceeds to blame the wrong thing from it.

Next, the author proceeds to have problems with libraries -- problems somehow
not shared with the rest of the community (see comments by other Scala users).
He mentioned stability problems, and then mentions two pieces of software with
excellent documentation, extremely stable, and supported across a broad range
of versions of their dependencies.

Now, choosing Spray when you are not familiar with Scala was a terrible
decision, and I can well see where the author had trouble using it -- while
not agreeing there's any problem with Spray itself. Having trouble with
Specs2, however, makes me seriously doubt his abilities -- if he truly had
trouble with it.

Next he proceeds to some discussion of simplicity, and I'd grant that Scala is
not simple. However, he ties that to a lack of regularity, which is
interesting in that Scala is _highly_ regular, much more so than Ruby. It just
allow different things than the languages he is used to, so it _looks
different_.

I can buy "looks different" \-- yes, it does. But the author's inability to
realize how regular it is just goes to show that he has a very, very poor
knowledge of Scala. That's not a problem with Scala, it's just that he didn't
learn Scala, and it keeps showing.

So, having not learned Scala, he tries to accomplish something that required a
specific Scala knowledge he lacked and fails. And somehow that's Scala's fault
and Spray's fault, not his.

Well, I admit it: if you don't learn Scala, it is very difficult to program in
Scala. That's certainly not the case with PHP, for example, but I have
certainly struggled with rather simple tasks in Ruby when trying to write code
in Ruby without learning it. I just never blamed Ruby for it.

Next, "everything is a type". I disagree that this is in any way a problem --
if you are going to complain about that, how about just writing "Scala is a
statically typed language" and leave it at that? We all knew that, didn't we?

So, having chosen a statically typed language, he dislikes the fact that it
actually tries to use types? Weird, but at least he doesn't make it a problem
of Scala itself.

On the other hand, it took me thirty seconds to find RawHeader, which allows
arbitrary headers, which indeed would be a weird thing to be missing. It's
right there, among the other headers. Among, say, Origin and either Access-
Control-* headers, which happen to be the CORS headers, all of which appear in
the API docs, so what gives?

Maybe they are new headers? Well, the CORS headers are new, if not _that_ new,
but maybe the article refers to something that happened months ago. The raw
header is there for quite a while, as you can see for yourself here:
[https://github.com/spray/spray/blame/master/spray-
http/src/m...](https://github.com/spray/spray/blame/master/spray-
http/src/main/scala/spray/http/HttpHeader.scala)

At this point, I don't even know where the author is coming from, that he
failed to spot this. It is certainly not Spray's fault, much less Scala's.

Next comes a rant on lack of H-M type inference. Well, we all would have liked
to have more type inference (without making the compiler even slower!), but
separate compilation, subtyping and full type inference is not a solved
problem. Which doesn't mean we can't gripe about it.

But there's a damning comment among it: the error message he describes in his
"workflow". Hey, Scala _infers_ the return type, so he doesn't need to add it,
unless he's doing recursion of calling overloaded methods. If he were doing
that, however, the error message would be different.

What the error message says, however, is that he is using _procedure_ syntax
-- that is, a method returning void in C/Java parlance -- when he actually
intended the method to return something. He doesn't need to add the type, he
just needs to use the correct declaration:

def method() { body } // procedure (unit-returning method)

def method() = expr // function

He spent two weeks programming in Scala, then went on to write a blog about
it, but he still hasn't figured out a simple detail like this, despite the
compiler telling him what the problem is?

Yes, beginners might well struggle with this oddity, but _for two weeks_???
And despite having fixed it throughtout the program? Really?

Now, detour briefly through long vs int, which I actually agree with, but
saying he was "reminded" of it shows a complete lack of familiarity with
statically typed languages.

Again, fine that you don't like statically typed languages, though I think one
ought to first _learn_ one of them before criticizing, but you could start and
end your post with "I don't like statically typed languages".

Then there are other issues which he enumerates but don't describe, and which
I can only disagree with. Horrible repetition required by case classes? Err,
what repetition?

So, in the end, it seems that what the author really wanted to say is: I don't
like statically typed languages, and I tried to use one for the wrong reasons,
in the wrong way, without learning it, and failed. No need to blame Scala for
his bad decisions.

------
mortyseinfeld
Because of Clojure's dynamic typing and idiomatic use of lots of nested
expressions it turns out to be a read-only language for me.

Scala seems to have a huge image problem. I think part of the problem is that
Odersky and crew have never written the treatise on how to use Scala's OO and
FP effectively. I'm surprised that Typesafe didn't come up with their own web
framework instead of using Play.

One lesson to be learned is that these days you need good IDE integration and
fast compiles (incremental) for rapid development. But Scala IDE support has
come a long ways in the past year or so. The Eclipse Scala worksheets is
awesome. I like it better than a standard REPL. Intellij support is still
going strong too.

------
bootily
As a java Dev I have been watching Scala to see what people make of it. It
seems like Scala is generally perceived as an academic exercise.

We all want more powerful tools and infinite expression but at what point are
we bikeshedding languages instead of building transparently clear solutions?

Scala seems to be solving problems i dont have.

~~~
kenbot
There's a lot of "seems" going around from people who haven't used the
language, or dynamic-typing folk who obviously aren't going to pick a language
that bets the farm on static types.

As a long-time Java dev myself, Scala is solving problems you don't even
realise you have, because you don't know to look for them.

Powerful types, immutable state and FP make a world of difference for writing
clear solutions, with better abstractions, less code, less bugs and less
bullshit than the horrendous status quo of corporate Java development.

~~~
dbcfd
> less code, less bugs and less bullshit than the horrendous status quo of
> corporate Java development.

It may take some getting used to syntax and design wise, but being able to
code things up in 1/10 the size of other languages completely blows away the
disadvantages of Scala.

------
sechastain
In every critique of scala, there is this:
[http://i.imgur.com/KrNcIGt.jpg](http://i.imgur.com/KrNcIGt.jpg)

