
Scala – The good, the bad and the very ugly - bilalhusain
http://www.slideshare.net/Bozho/scala-the-good-the-bad-and-the-very-ugly
======
noelwelsh
M'eh. Yes, Scala has flaws but I feel like this talk makes too much of minor
annoyances. Ultimately you make an engineering decision about platform. Do you
want decent performance, lotsa libraries, and a modern statically typed
language? Scala is arguably your best option at present (yes this can be
argued with; no that isn't an interesting argument to have). Maybe we'll all
be using Rust/Haskell/whatever in 5 years, but in the meantime I got code to
write and products to build and I'm using Scala for better or worse.

Specifically:

\- Code on slide 3 has typos. (Yeah, that's minor)

\- Lambdas are slower than Java 8 -- that's because Scala currently supports
Java 6+. Java 8 has been released for 6 months. This is a ridiculous
complaint.

\- Heavy in terms of concepts -- another ridiculous complaint. If you want to
keep on writing Java, keep writing Java. If Scala didn't bring new stuff to
the table it wouldn't be interesting.

\- Implicits -- agreed they can be misused. Type classes are the way forward.

\- I don't understand many of the "very ugly" complaints. Yes, collections
have lots of methods. Is this surprising? Yes, library code may be written in
an abstract way. So what? Yes, DSLs look like DSLs. Yes, abstracting over
arity is a problem in all statically typed languages. etc.

There are valid complaints to be made about Scala. I feel this talk
demonstrates a lack of understanding of the language, and many of its
complaints are in fact misunderstandings.

To me the biggest issue this talk reveals is that if you come from an OO
background (which I assume the author does) then learning Scala will require a
change of mindset. I don't think it is fair to make this a language complaint
though. Scala makes it fairly obvious what you're getting yourself into and,
as I said above, if you wanted to keep on writing code the way you have in the
past it's not clear why you are using Scala in the first place.

~~~
pron
> If you want to keep on writing Java, keep writing Java.

Ah! But that’s the point, because Scala is pulling a bait-and-switch. If it
were only a modern statically typed language I wouldn’t complain so much about
it (and I really do complain a lot about Scala, I guess). Yes, I find its
gaudy indiscrimination aesthetically unpleasing[1], but that’s a matter of
personal taste. The problem is that Scala still markets itself as “a better
Java”, and people are drawn to it so they wouldn't have to write getters and
constructors. And at first, Scala does seem to be that. Only after a while you
realize that it’s a whole other beast altogether — not necessarily the one you
bought into. If Scala were marketed as “a JVM language Haskellers can learn to
live with”, I’d have no issue with it (except the aesthetics, that is :)).

[1]: Yet, with its near-infinite list of features it can't even type
immutability, which even Java 8 can through its pluggable type systems.

~~~
noelwelsh
Indeed, if Scala wasn't closely compatible with Java (in terms of both syntax
and interop) it would not have so much traction. That's the deal with the
devil that Scala made, and one reason it has an excess of cruft. For example,
no language needs both traits and abstract classes, unless that language wants
to interoperate easily with Java.

I am broadly agreed with you. Scala could do with trimming, and I'm optimistic
that both Typelevel and Typesafe will accomplish this in the near future.

~~~
anentropic
" For example, no language needs both traits and abstract classes, unless that
language wants to interoperate easily with Java."

now I'm wondering - does Clojure then suffer the same crufting? or it's less
interoperable?

~~~
noelwelsh
I believe Clojure is less directly interoperable. For instance, a Scala class
is a Java class. I believe creating a Java class in Clojure is something you
have to call into a library to do.

Update: reading the Clojure docs, the main issue I see is compiling Java code
against Clojure code. Clojure has a number of constructs for calling Java code
and creating Java objects, but it's not clear to me how you define an API in
Clojure that Java code can then call.

~~~
pron
Actually, Clojure interoperates with Java much more cleanly, and easily than
Scala. Every Clojure collection _is_ a Java collection and vice versa. Every
Clojure map _is_ a Java map and vice-versa. Plus, because Clojure is less
statically typed than Java, Java typing idioms don't clash with Clojure's.

~~~
noelwelsh
> Plus, because Clojure is less statically typed than Java, Java typing idioms
> don't clash with Clojure's

Well, you made me laugh. :)

But the real deal is compiling stuff to JVM bytecode ahead of time, which Java
code can then be compiled against. It's not clear to me that Clojure provides
this, which is what I was getting at.

~~~
pron
Of course Clojure does this. Clojure doesn't even _have_ an interpreter.

------
nrinaudo
I feel that most of (not all) the criticisms are fair, but superficial.

True, the IDEs are poor, for a certain definition of poor. Had I not used
IntelliJ for Java, for example, I'd find IntelliJ for Scala amazing. Knowing
how much better it can be spoiled me, but frankly, IntelliJ for Scala is not
_bad_. It just could be better. Also, Emacs has a very robust Scala mode.

True, there's a _lot_ to learn before you can consider yourself fully fluent.
You do not need to know everything, however. And once you've started on the
path, things tend to flow naturally. For example, implicit conversions are
easy to grasp. Once you understand them, implicit parameters and type classes
are not much more complicated. Once you know type classes, it opens the door
to a lot of functional "design patterns" \- functors, applicatives, monads...
these are not strictly necessary, but they're _fun_ to learn about. And they
teach you algebraic data types, which in Scala means case classes, sealed
traits, ... it all sort of flows naturally.

True, it's easy to write absolutely un-maintainable code. While that's true of
any language, Scala makes it rather easier than most. It's also very easy to
write highly maintainable, legible code, and to avoid complex, ascii art based
operators (or at the very least to offer wordy equivalences at 0 cost through
`@inline`). I feel that saying "it can be hard to read, if you don't follow
basic guidelines" is a bad reason not to use a language. A good reason to be
careful, though.

My personal experience is that, once you start feeling comfortable with the
language, you get much more productive than with Java. It does require some
initial work, though: if all you know is OO, learning how to design your code
for composition rather than inheritance takes a while - it takes a while just
to realise that it's not a bad idea, let alone embrace it!

Also, ScalaCheck. Man, do I wish there was a good Java equivalent for some of
my legacy code (that would not require me to rewrite all of my tests).

~~~
dreamweapon
_Once you know type classes, it opens the door to a lot of functional "design
patterns" \- functors, applicatives, monads... these are not strictly
necessary, but they're fun to learn about._

For a certain value of "fun", I guess.

Generally I find in engineering that it's best _not_ to add abstraction (or
other forms of complexity) to a system unless there are strong, clear benefits
to doing so. The more we learn about Scala, it's just not clear that it
delivers those benefits (in proportion to the time investment it demands).

It's not that I don't "dig" abstraction. It's just that I have an infinite
list of things to learn about (some fun, some not so fun) in any given
development environment. (In general, most of these are in the non-fun
category: dealing with dependencies,build tools, and legacy quirks that can
never be fixed).

And another infinite list in _my own problem domain_ \-- you know, that thing
I'm supposed to be, theoretically, directly working on (in the service of
which all of these fancy software tools were supposed to be a means, not an
end). Plenty of very real and juicy abstractions. More than I can ever hope to
get to the bottom of, in fact.

But don't get me wrong. If applicatives and such are your bag, then that's
great. Maybe Scala is the right language for you, then.

~~~
pea
I agree with you in terms of abstraction; I do believe Scala adds a lot to
practical programming as well. I feel the community is tainted by a bunch of
type-nerds trying to compile their Haskell, and don't care about writing
simple, maintainable code.

We use Scala because it is speedier to push features. I work much quicker in
it, and we don't have to worry about a lot of the stuff we would in Java. That
said, we don't use a bunch of the most complex features of the language (I am
just talking simple pattern matching, map/flatmap/filter/unzip). So far, it's
actually the most productive language we've used.

Our dig is the community and things peripheral from the core language:
documentation is generally awful (Play, SBT). Dependencies management is awful
(SBT doesn't work). Libraries are overly complex (Dispatch). And compile times
suck.

------
virtualwhys
The IDE story has vastly improved in Scala, certainly nowhere near that of
Java but decent nonetheless. The best way to shoot yourself in the foot is to
have automatic build turned on in your IDE _and_ to run SBT in a separate
terminal; with that approach you get dog slow compilations, blocked UI, and
other hair pulling madness. When SBT is boss (i.e. IDE auto build turned off
and compile target shared between the two) then you'll have a far saner
development experience.

The OP hasn't been using Scala for long so many of his gripes boil down to
lack of experience. You have to learn the ropes, the (myriad) corner cases,
etc. of the language before things start to click.

It's like starting out in Haskell, where on earth do you even begin to
understand this utterly new paradigm, much less go into production with large
scala projects in it? The answer is: you don't, you learn, learn, learn until
you're well grounded in the language and its frameworks; _then_ you bet the
bank on it because you're sold on its clear-as-day powers.

I'll go out on a limb and say that the only viable type safe alternatives to
Scala and its ecosystem are C#/F# on .NET, and Haskell. In other words, yes,
Scala has its warts, but overall is pretty much unmatched in terms of
expressivity, power, and performance.

~~~
the_af
I like Scala, but it gets me that the official IDE, Scala IDE, is so utterly
broken. If you let the IDE handle the build, you'll constantly get spurious
compilation errors, which in a statically typed language are _unacceptable_.

Letting SBT do the build may work, but come on. This is the _official_ IDE! Is
there any acknowledgement in scala-ide.org that you should let SBT to do the
build? Do Odersky and the guys at Typesafe use that setup, or do they suffer
their IDE silently?

I haven't had much luck with IntelliJ either.

~~~
Roboprog
I would never let any IDE run my build.

Builds are always scripted with explicit settings, which anyone can run, with
the same results, regardless of what editor and preference settings they use.
(so long as needed compilers are installed on server/workstation)

~~~
the_af
I think we're not using the word "build" in the same sense. I meant when
writing code with your IDE, not when building the deployable artifact. In
Eclipse this would be in _Project - > Build Automatically_; I forget the
setting in IntelliJ.

Incremental compilation in the IDE is useful because you see errors as you
type. This is an entirely separate issue from reproducible builds, etc.

~~~
Roboprog
OK, so you are talking about the ability of the IDE to scan (and parse where
needed) the code and libraries to generate a symbol table for validation,
auto-completion and definition / usage look-up.

~~~
the_af
Yes, but note that for this the IDE needs compilation, which is why I used the
word "build" (perhaps confusingly).

Eclipse for Java does this perfectly, and I assume many other IDEs do so too.
Scala IDE, which is built on top of Eclipse, does a terrible job at this. For
a statically typed language such as Scala, it's aggravating when your tools
report spurious compilation errors.

------
DanielBMarkham
Saw some Scala at a conference recently. The guy was demonstrating using it to
do TDD.

I lost track somewhere in the first ten minutes or so, but it looked like he
was importing/using multiple DSLs and helper libraries. After I lost track of
the exact details, I started scanning for the gist of what he was doing.

After an hour, he had what looked like the most massive clusterfuck I've ever
seen in a project file -- all to do something that would take a dozen lines or
so of simple FP script. Seemed like every functional thing he used was either
also an object or had to be bolted into an object graph for it to work. The
project file had scores of things in it.

This did not leave a good impression. It reminded me of when I saw my first
C/Win32 app and realized you needed a couple hundred lines of code and several
files just to say "hello world" \-- except this was a couple orders of
magnitude more complex. It was a god-awful abomination.

Hopefully Scala projects are not like this.

~~~
lmm
Not all Scala projects are like this. There's a sect that wants to write tests
in "human readable" fashion, e.g. the people who like Cucumber in Ruby; in
Scala those same people write their DSLs within the language, something Scala
is good at and that I'd argue provides real advantages over an "external" DSL.
But you don't have to do that; I write Scala professionally and all my tests
are just ordinary JUnit test methods.

~~~
DanielBMarkham
Whew!

I'm okay with using DSLs. Hey, if you have good FP, flaunt it. My concern
after watching this, however, was whether or not the JVM development
environment itself encourages complicating things beyond the most minimum
thing needed to solve a problem when you're using it in a functional manner.
(I haven't done Java in a decade). So, for instance, could I have just written
a simple 12-line script to solve the problem he was banging around? Or would I
have to create some kind of object with a "main" method? Could I just add in a
test file and write functional tests from there, aka JUnit, or do I have to
bolt something in that then requires a separate project structure and so forth
(aka JUnit)

There's no right or wrong answer for any of these types of project
configurations. Heck, I like my tests in a separate project. It just looked
like every time he had a new need, the project got 14 times more complex. The
solution to one problem made the entire development environment more
complicated for everything else. That's heading in the wrong direction, no?

Admittedly I only had a brief glance. Thanks for the answer!

~~~
benwaffle
Scala's creator's course on coursera certainly doesn't encourage complicating
things beyond the minimum necessary

[https://www.coursera.org/course/progfun](https://www.coursera.org/course/progfun)

~~~
orteipid
I've used Scala on and off professionally for about 4-5 months and the best
advice I could ever give to someone using it for the first time is to try and
treat it like Ruby but with type safety.

As numerous people before me have said, the language is a mess. Although it
offers some benefits, the syntax is so absolutely bloated that you're probably
better off taking the time to really consider whether or not you absolutely
need it for all of the headaches and unreadability you're going to run into in
terms of code. There aren't many Scala developers out there and the learning
curve can and likely will punish you when things need to get done, assuming
you're bringing in new developers.

The open source libraries all generally seem to have glacially slow
development processes, which in some cases might be considered acceptable, but
when the main Scala team pushes out 2.11.x (and to some degree actively
encourages its use) and X framework you're using literally cannot run because
library Y is not compiled against it, you end up stuck on Scala 2.9/2.10 which
is really unpleasant for you because you're missing out on the speed increases
and other quality of life improvements (how many times have you run into the
22 argument limit for case classes on 2.10?).

Perhaps I'm asking for too much, but Scala strikes me as a language that's
supposed to be moving a bit faster than Java in terms of development, but that
doesn't really seem to be the case. All in all, while it has some neat parts,
if I never got to work with it again I wouldn't be crying about it.

~~~
_pmf_
I resent Scala because it takes up a spot in the JVM ecosystem that I wish a
ML family member would occupy.

I really hope Java 8 will slow down Scala's growth.

~~~
spopejoy
I really wonder why we need the JVM at all.

For Haskell at least, the GHC runtime is getting pretty good, and seems to
have at least basic tools for GC analysis etc. I'm ignorant of MLs so perhaps
someone can speak to their status.

Of course there's the much-touted "Java Ecosystem" but it's looking crustier
than ever methinks. Maven?? Blech! Also, it doesn't seem wise anymore to build
a website on Servlets/JSP/SpringMVC etc, esp. if you want to attract devs.
Rest APIs maybe.

What's the killer feature these days recommending the JVM?

~~~
frowaway001
Reliability, performance, maturity, instrumentation, diagnostics.

Just picking one example from the list, performance: How is GHC's runtime
dealing with 100GB+ heaps?

~~~
sixbrx
Do the Oracle or OpenJDK JVMs deal well with heaps that large? I have no
interest in other JVMs because my employer would not consider switching and I
can't say I blame them.

~~~
kasey_junk
It depends on what you mean by "deal well with heaps that large". You can
certainly set them that large with no problems. But given your memory patterns
they can cause dramatically bad GC times.

------
lmm
Does the syntactic diabetes really bother people? Like, yes, these are
different sequences of characters that mean the same thing, but visually it's
very clear that they are the same thing; it's not the perl "there is more than
one way to do it" where the ways of doing it are _conceptually_ very
different. It seems no different from complaining that I can write f(a, b) or
f((a), (b)), which is a choice you get in almost every language.

Implicits are dangerous, sure. Typeclasses are vital and extension methods are
nice, but it might be better to cover these use cases with something more
specific. That said, these days the IDEs flag up implicits so it's not really
a problem day-to-day.

Concise really helps readability at the function/module level - there's a huge
drop in readability when a function reaches the point that you can't fit it on
one screen. It may well be that the 1-line scala version of a method takes
exactly the same time to read as the 10-line java version - but if it means
you can fit your whole class on one screen, that's still a win.

Symbolic method names are bad and I wish the community would move away from
them.

The definition of ++ is perfectly sensible once you stop panicking and start
actually reading it. As is the parser; sure, it's a DSL, it uses some short
symbols, but I defy you to find a better way to express the parser given. When
you're building up a complex parser, it's well worth having a concise
notation.

jsonFormatX are legacy cruft. In a modern json library you can avoid them by
using Shapeless instead; hopefully spray-json will do this too.

The .toSet() example is deprecated and will give a warning if you actually try
and run it.

Java-8 style lambda compilation is already available under an experimental
flag, and the next release will have full support.

~~~
bsaul
Syntactic diabetes is to me the best warning sign. It means the focus on
orthogonality has been lost somewhere in the evolution of the language.

There should be only one way to express a given language operation, and this
way should be the simplest and most elegant. Not just because of aesthetic
(which is crucial when speaking about readability), but also because it would
combine the most harmoniously with other parts of the language.

It seems to me that at this point scala should deprecate all non-essential
syntactic sugar and features and reduce the language to its "core". Or, at the
very least, people should start a fork with that goal. Hell, it could even be
just a compilation option.

~~~
lmm
I don't see how it's a loss of orthogonality; just like a whitespace-
insensitive language, it's saying that the choices of bracket and dot are
syntactically equivalent. And that syntactic freedom means the precedence of a
Scala line is often much clearer than the equivalent in other languages:

    
    
        a b {c d (e f g.h(i))}
    

In Haskell you'd have to write that as something like:

    
    
        a b (c d (e f (g h i)))
        //or alternatively
        a b $ c d $ e f $ g h $ i

~~~
tel
I don't understand what you're trying to argue here. At least in this example,
I cannot see how the Haskell version is not much more clear.

~~~
lmm
I find it much easier to visually tell what the tree structure (AST) is in the
Scala version, because of the different possible delimiters -the fact that a
'(' must match a ')' and not a '}' makes it much easier to visually parse.

------
Yuioup
Excellent quote:

    
    
      "Concise" doesn't necessarily mean fast to write or easy to read

~~~
weego
Maybe, but it's just a generic statement about programming, it has no real
value in a critique of Scala specifically. Part of the beauty of any flexible
language is you can go back and refactor it down to a more elegant solution as
you learn more. That doesn't mean you have to boil the code down to a point
where it is largely impossible to read any more in Scala than any other
language.

There are real pain points in Scala when you try and scale it from single
developers to teams working on a project and most of them are to do with the
flexibility of the language.

I think all companies working with Scala end up settling on a sub-set of the
language that they are happy with. In that sense, the bad is irrelevant: you
are never put in a situation where, say, you are forced into using implicits
(apart from light use in external libraries like lift-json) so if you don't
use them you never suffer their downsides. If you obsess over parts of a
language you don't even have to use... then well I'm afraid I have nothing but
scorn for people like that.

At team-scale then your main pain point is trying to get style of writing that
everyone can get behind. Code reviews can be painful when developers with
different ideas on how to solve a problem butt heads and pull requests turn
into "That's not how I would have written it" instead of critiquing the actual
code presented.

The tooling and compiling I completely agree with. SBT is a horrific mess. I
don't have a single good word to say about it.

~~~
mercurial
> Maybe, but it's just a generic statement about programming, it has no real
> value in a critique of Scala specifically.

About Scala specifically? No, indeed. About languages which make it possible
to create custom ASCII operators? Certainly. I don't know how the Scala
culture about this is, but my experience with Haskell is that once people run
with it, you get awful ASCII DSLs with cryptic operators all over the place.

> I think all companies working with Scala end up settling on a sub-set of the
> language that they are happy with.

So, pretty much like C++, a language that people love to hate. The problem is
that, out in the wild, you're going to end up with legacy code made by people
who picked a different sub-set.

~~~
weego
There is an infamous library called dispatch. Someone put together
[http://www.flotsam.nl/dispatch-periodic-
table.html](http://www.flotsam.nl/dispatch-periodic-table.html) to try and
help other developers out when using it. I use it because it is good... but
hell. The lack of discipline there is awful.

 _The problem is that, out in the wild, you 're going to end up with legacy
code made by people who picked a different sub-set._

This is the situation I've been in for the last year and I agree that for
every point I make in praise of language flexibility this is the strongest
counter-point.

~~~
oelang
Dispatch was one of the first libraries for scala, it's not really fair to use
it as an example.

The latest version of dispatch doesn't have that many operators anymore.
[http://dispatch.databinder.net/Combined+Pages.html](http://dispatch.databinder.net/Combined+Pages.html)

------
BozeWolf
Yes, scala. I'm having some fun with it... but i'm also having a lot of
arguments with it. I especially recognise the parts of "there is no
best/single way of doing things". I can overcome the syntax diabetes.

I'd like to do functional programming, I'm doing server/web based stuff
mostly. I'd like the language to have a big(large) ecosystem. Clojure is fun
and all, but it's more or less a hackernews language. There are only a few
serious businesses using it. It also lacks a web framework like Play!. Same
goes for Haskell. So besides all the bad stuff of scala, having play and quite
a large ecosystem is why i wanted to try it.

~~~
simi_
I don't want to be that guy, but why don't you try Go? It's the perfect server
side language IMHO.

~~~
lmm
With a type system that's weaker than Java's? Look at e.g. the way spray
handles HTTP headers; it eliminates a bunch of errors that are in some sense
trivial, but almost all bugs are trivial when looked at in the right way. You
just couldn't do something like that in Go.

~~~
grey-area
_Look at e.g. the way spray handles HTTP headers..._

For those of us not familiar with Scala it'd be interesting to see you expand
on that statement. Are you talking about the type definitions in this file?

[https://github.com/spray/spray/blob/release/1.1/spray-
http/s...](https://github.com/spray/spray/blob/release/1.1/spray-
http/src/main/scala/spray/http/HttpHeader.scala)

~~~
lmm
Yeah. It means you can e.g.

    
    
        respondWithHeader(`Content-Encoding`(UTF8)) { ... }
    

and the header and its parameters are typed, and so if you make a typo in the
name or the value (or try to pass the value of one header to another) then
you'll get a compile-time error.

~~~
grey-area
You could type things like headers in Go too if you want to, by introducing a
new type for each header in a similar way, get them to check values are valid
on being assigned etc. (std lib does it in a simpler less robust way but it's
quite possible). Go could then do compile time checking for those types, e.g.
something like:

[http://play.golang.org/p/GeUgsjitVS](http://play.golang.org/p/GeUgsjitVS)

    
    
        func respondWithHeader(h HttpContentEncoding) string {...}

~~~
hderms
I would imagine having union types and such would make something like this a
bit more powerful. Not entirely sure, but having a hierarchy of http
contentencoding types, and http error/success types could make it easier to
write code that handles all error conditions. Also having a type for sanitized
strings versus unsanitized strings. That being said, I've never used a
language with a sophisticated type system to do web programming.

~~~
grey-area
_Not entirely sure, but having a hierarchy of http contentencoding types, and
http error /success types _

Yes the Scala server shown was an interesting example, though I'm not sure if
it would be impossible to do in other languages or just harder.

 _Also having a type for sanitized strings versus unsanitized strings._

The golang stdlib does do this, it's quite handy as a reminder.

------
wiradikusuma
I submitted a YouTube video 165 days ago where Martin Odersky explains how to
avoid coding the complicated way.
[https://news.ycombinator.com/item?id=7641626](https://news.ycombinator.com/item?id=7641626)

------
eranation
I use scala a lot and it did become my go to general purpose language (as well
as my workplace adopted it as a first class citizen and used for many new
projects)

I do have issues with it, but mostly with developers using (abusing) it. (And
library authors that are a bit religious about the functional paradigm and
simply love their operators...

With great power comes great responsibility, the is no better description to
this language.

Also, I was looking at the CanBuildFrom hell with fear, but Odersky et al's
book on Scala surprisingly did a good job getting the pieces in place for me.
It even makes sense of the madness.

[http://www.artima.com/shop/programming_in_scala_2ed](http://www.artima.com/shop/programming_in_scala_2ed)

Finally, Bozho is one of my most respected contributors on stackoverflow. And
I can say that his slides actually do justice to Scala, I might disagree on
the conclusions, but the facts are absolutely right.

------
mcv
I kinda agree with this. Scala has good bits. Very good bits. Gorgeously
beautiful bits, even. But the ugly bits are so terrifyingly ugly that I dare
not touch it.

Give me the Scala pattern matchers (that can also match by type and even by
content of case classes, I believe), with the case classes and the actor
concurrency model, but keep the horrendous type system and the confused parts
of the syntax.

~~~
frowaway001
> horrendous type system and the confused parts of the syntax

Could you expand on that a bit?

In my experience, Scala is one of the few languages which don't fight against
everything you want to express in a typesafe way.

Also, I find the syntax extremely consistent. Easy to remember and almost no
special rules.

~~~
mcv
The article shows some examples where you can choose between regular brackets
or curly brackets. There's a lot of different ways to say the exact same
thing. Why? Which is best? Are there any cases where one works but the other
doesn't, and if so, why does the other exist? But maybe I'm too used to
different brackets meaning different things. I'm used to Java and Groovy where
brackets are used very consistently.

The type safety goes way overboard with extremely arcane, incomprehensible
expressions. The excessive power of the type system makes compiling far too
slow. And the pattern matchers mean you can easily get your type back when you
need it. I really strongly prefer the more dynamic approach of Groovy. Total
type safety is a trap.

~~~
frowaway001
> The article shows some examples where you can choose between regular
> brackets or curly brackets. There's a lot of different ways to say the exact
> same thing. Why? Which is best? Are there any cases where one works but the
> other doesn't, and if so, why does the other exist?

Yes, but which one would you remove?

If you disallowed the curly ones, developers would suddenly require an
additional language feature to define methods which could be used like this:

    
    
      using(someResource) {
        // do something with ressource
      }
    

Apart from that {} has semicolon inference, while () doesn't. That's extremely
helpful, if you have some expression and really want to make sure that it
can't be split into something like { doThing1, doThing2 } by an unaware
developer.

> Total type safety is a trap.

Sure, there are limits on what can be done with a type system, but these
options have been growing larger and larger in the last decades.

I wouldn't throw away the last 40 years of progress in that area and start
doing stuff manually which any decent compiler can figure out for me.

> Groovy

I haven't heard from Groovy since a long time ago. Is it still actively
developed? The last things I saw was that they were struggling to catch up,
and work on the new MOP still wasn't finished.

On the Gartner PLI, Groovy is way down on position 20. That doesn't look too
promising either ...

~~~
vorg
> I haven't heard from Groovy since a long time ago.

It's still the sole language used in Grails, which is losing adoption share to
newer web frameworks. Gradle is on the rise, but Gradle will probably soon
open its configuration as an API so any language can use it, so Scala and
Clojure could become more popular for scripting Gradle in the future.

> Is it still actively developed?

There's a technical developer employed by Pivotal who's presently working on
making Groovy work on Android. I don't know if he's working on it full-time or
merely squeezing in development between fee-paying consultancy work.

> The last things I saw was that they were struggling to catch up, and work on
> the new MOP still wasn't finished.

I don't think work on a new MOP has started. It's pitched for Groovy 3 and the
next version of Groovy is still version 2.x.

> On the Gartner PLI, Groovy is way down on position 20.

On Tiobe, it's still hovering around position 49, where it's been fluctuating
since 2007, sometimes higher, often out of the top 50.

------
fideloper
Is there a book everyone recommends for learning Scala? In the beginner range,
not someone coming from Java.

~~~
huehue
`Scala for the Impatient` is really good.

~~~
thescrewdriver
Scala for the Impatient is really good, but not sure that it's designed
entirely for beginners.

For more beginner-centric content perhaps check out:

Learning Scala:

[http://shop.oreilly.com/product/0636920030287.do](http://shop.oreilly.com/product/0636920030287.do)

[http://chimera.labs.oreilly.com/books/1234000001798/index.ht...](http://chimera.labs.oreilly.com/books/1234000001798/index.html)

...or Atomic Scala:

[http://www.atomicscala.com/](http://www.atomicscala.com/)

------
taf2
golang

~~~
thescrewdriver
Perhaps you could elaborate on how naming a random language relates to this
discussion...

~~~
throwaway1979
Heh ... it is the other mainstream "hot" language.

I was looking for a language to move to post-python. I love python but the
2.7->3 jump has been annoying. More than that, I felt I needed static typing
for the next big system I did ... too much pain debugging python.

I looked at Scala since it had the JVM behind it. While the language seems
decent, it seems too easy to write unreadable code. Multiple ways of doing the
same thing ... yada yada.

Friends at Google had been espousing Go for a long time and I didn't bother.
Seemed like a proprietary language with little adoption. Two things changed
for me. I got some exposure to erlang via elixir. This made me think about the
whole channel concept. Second, I had to read code in Docker (which is
awesome). I learned a bit of the language and was surprised how small the
language was. Really reminded me of C, which I love. There seems to be more
adoption of Go .. e.g. Cloud Foundry and others. I like Go enough that I will
be spending more time learning and investing in it.

Just by 2 cents.

------
xwowsersx
From the looks of it, the author of these slides has written very little
Scala. Take slide #7, for example, where he writes def bar() = { "1" } when
def bar = "1" is perfectly sufficient. Ironically, I may very well be pointing
out the bad parts of scala (i.e. that () is simply a convention for indicating
Unit or side-effecting functions, but its just convention and not enforced by
the type system in any way). Notwithstanding that, I don't think someone who
has written very little Scala is in a great position to offer a reasonable
critique.

This is a longer discussion, but in the very first slide he points to the
object-orientation as a plus. In my opinion, he's already wrong. "There is no
such thing as Object-Oriented programming." See: [http://blog.higher-
order.com/blog/2008/12/04/no-such-thing/](http://blog.higher-
order.com/blog/2008/12/04/no-such-thing/)

