

On Scala - yareally
http://www.dehora.net/journal/2013/06/15/on-scala/

======
saryant
I started using Scala ~2.5 years ago for my undergrad thesis. At the time I
didn't really know what I was doing and essentially wrote Java with map/reduce
on collections.

I've been working steadily in Scala since and currently do so professionally.
I'm a fan, especially with the Akka actor framework.

Lately I've been playing with Play, Akka and ReactiveMongo. For-comprehensions
offer a terrific abstraction for dealing with asynchronous code. My current
side project is "Street View for Flights" implemented in the above stack. Lots
of calls to third-party REST APIs after checking if data has already been
retrieved and inserted into Mongo. Code like the following allows for
controllers to be asynchronous while staying readable:

    
    
      def byCode(airlineCode: String) = Action {
        Async {
          for {
            airline <- Airline.findByICAO(airlineCode)  // returns Future[Option[Airline]]
          } yield airline map { a => 
            views.html.airline(a)
          } getOrElse NotFound
        }
      }
    
    

The advantage for me is that those futures could be redeemed either by finding
the requested object in Mongo and on failure retrieving it from a third-party
API _while not blocking_ and keeping the code readable. Either way, the
controller just gets a Future without blocking.

Other parts of this project make heavy use of Akka actors to feed server-sent
events (sort of a compromise between Comet and WebSockets). Development has
been great fun because Scala really allows me to write code at a higher level.
Asynchronous, typesafe, nullsafe code with the compiler as my safety net.

~~~
laureny
The main problem I have with actors is that they are untyped.

What's the point of having a powerful type system like Scala's and then throw
it out of the window just so I can use a distributed framework?

~~~
noelwelsh
Scalaz has some nice (usefully typed) concurrency tools:

[https://github.com/scalaz/scalaz/tree/scalaz-
seven/concurren...](https://github.com/scalaz/scalaz/tree/scalaz-
seven/concurrent/src/main/scala/scalaz/concurrent)

[https://github.com/scalaz/scalaz-stream](https://github.com/scalaz/scalaz-
stream)

Like everything with Scalaz, the tools are great but almost completely
undocumented.

~~~
laureny
> Like everything with Scalaz, the tools are great but almost completely
> undocumented.

Exactly. I will start considering scalaz once its authors grow up and realize
that the lack of documentation is not a sign of quality.

~~~
jjm
Really now? As if these guys get paid to do create and fix scalaz all day
right? Like Oracle yeah? This is the story about every single open source
project. You can choose something else, wait it out for documentation, or
contribute it. Lucky you even have the source!

------
tkw8
Using Scala has been a breath of fresh air after 10+ years of (mostly) Java.
Mountains of boilerplate (I'm looking at you getter/setter/constructor auto-
generated code) become 2 or 3 lines, in some cases a 1 line class definition:

    
    
      class Foo(var x: Int, var y: Int, var name: String)
    

(Thats equivalent to 6 method definitions and a constructor in Java. Also, the
possibility that you forget to initialize one of the fields in your
constructor [which happens from time to time in most Java code] is removed)

It's not just about having to write less boilerplate, it's also about having
to read less code and expressing ideas using functional concepts where it
makes sense.

Critics like to complain that having many features makes the language complex.
In practice Scala code is fairly straightforward, the extra features just mean
that library designers have to power to implement some pretty amazing
interfaces for you using these features. Most Scala code is pretty sensible,
and it's nice to know that the extra expressive power is there when you need
it.

This may sound like heresy but I find myself being more productive in Scala
than in Ruby. Part of that comes for the self-documenting nature of static
typing and clear interfaces (No more "what methods and fields does this Foo
object that is being passed in to this obscure method have?"). This is a very
useful property to have when reading other peoples' code. The tooling is
surprisingly mature (IntelliJ).

In hindsight picking Scala as a better Java should have been a no-brainer.

~~~
lucian1900
There are much less complex but precisely as powerful languages out there
(like Haskell). Scala's crazy amount of syntax is what makes me avoid it, not
unlike C++.

~~~
trailfox
Does Haskell let me use the many Java libs that are used extensively
internally in many organizations (including mine)?

~~~
virmundi
Terrible, terrible answer if you are mostly doing functional Scala. I've got a
blog post that deals with this. Tl;dr: Java libs are good along as they are
thread-safe or immutable; if they're not, you're looking at horrible side-
effects where there shouldn't be any.

[http://talesfromannoyance.blogspot.com/2012/05/why-im-
lookin...](http://talesfromannoyance.blogspot.com/2012/05/why-im-looking-at-
erlang-over-scala.html)

If you want reuse, you need to look at taking those parts and wrapping them up
in SOA.

~~~
trailfox
For many use cases OO Scala works just fine, functional code used where it
makes sense. Our goal is to integrate with existing systems, not to seek
purely functional code as a goal in and of itself.

~~~
virmundi
I agree with the concept. My concern is what happens as your team grows to
include others whose Scala background is more functional. There is a sense
that they should be aware of the old way your code base is put together.
Unfortunately things could go awry when they code new functional based code
expecting functional based input.

Don't get me wrong, I like Scala. You just really have to watch its dual
paradigm behavior when dealing with Java code

------
yareally
Like the author, I've been using Scala more and more as of late (mostly after
finding it to be a viable alternative to Java on Android). Perhaps the biggest
thing that I've had to get over is the "feature freedom" of the language after
being walled in by Java on Android. I know I'm not too far off in saying it,
but it's like Martin Odersky created it in direct response to the nanny-like
restrictiveness that Java has, but perhaps went too far in some areas (as the
article describes a bit). He did write the current java compiler, so he's well
familiar with how Java is. I just sometimes get the feeling someone pressed
accept to every feature enhancement to the language at some point as just
about any feature you can think of in a modern language has found its way into
Scala. Generally, I find that to be a good thing, but I can see how it would
be off-putting to some and makes Scala somewhat of a controversial language
for both imperative and functional language advocates.

If one is not careful and adhering to a formal style guide, it would easy to
end up with an unreadable mess of inconsistent code. Anyone with some
grounding in programming already at a professional level shouldn't have a
problem, but someone that's relatively new to development might want to look
into another language. For example, all of these are valid ways to create a
class with some parameters/properties:

[https://gist.github.com/yareally/5811498](https://gist.github.com/yareally/5811498)

After having to use Java on Android for the past three years, such freedom is
both liberating and shocking at the same time. I use C#, JavaScript and Python
pretty frequent as well, but it's just I'd say Scala is even more liberal than
any of those feature wise. It's more like Perl (not quite, but close), but not
quite in the area of a Lisp variant. Scala is definitely written from the
viewpoint of the developer and not the intended users though. It's also nice
to have access to features that are standard in languages like Python, Ruby,
C# and functional languages. Seeing 13 lines of Java become 1 line of Scala[1]
is a great feeling.

I'd say if you have experience with Java, C#, Python, Ruby or any functional
language you'll pick up on Scala pretty quick. If Java is your only language
experience, it might be a bit rough at first, because of the expressiveness
and freedom of the language, but don't let it detour you. If needed, you can
mostly stick to the imperative side of Scala and slowly work in more
functional features as well as some of the useful syntactical sugar stuff
(like operator overloading) that Scala provides.

[1]
[https://gist.github.com/yareally/5810767](https://gist.github.com/yareally/5810767)

~~~
_pmf_
> I just sometimes get the feeling someone pressed accept to every feature
> enhancement to the language at some point as just about any feature you can
> think of in a modern language has found its way into Scala.

That was also my impression. Clojure is sometimes painfully restrictive (I
need forward declarations for functions if I use them before they are defined?
In a compiled language in 2013? Really?), but at least it is curated.

~~~
bad_user
With all due respect, this impression is just folklore.

The difference between Scala and Clojure is the difference between ML and
Lisp. Languages from the ML family are statically typed by definition,
therefore they need slightly more features to be expressive. On the other
hand, the trade-off is worth it for many people, because the compiler actually
helps you - for example it's far easier to work with various functors (such as
monads) in ML languages, than it is to do that in Lisp.

Also, Clojure is not "painfully restrictive" or "curated". Name one thing that
Clojure doesn't allow you to do.

~~~
roryokane
Clojure does not allow you to define reader macros. Though I do not claim that
Clojure is “painfully restrictive” because of this.

I would like reader macros because they would enable the implementation of
sweet-expressions
([http://readable.sourceforge.net/](http://readable.sourceforge.net/)).

~~~
willismichael
[http://briancarper.net/blog/449/](http://briancarper.net/blog/449/)

------
TeeWEE
What I dont like about scala is its "syntaxtic flexibility". Or how I would
call it, non consistent syntax.

Too much features: Scala has everything, it seems like the language designers
coudn't make a choice about what is best. "Whoo this is cool, lets add it".
One word: implicits, arrgh

Also the fact that is built on top of java... When you design a good language,
you should try to do it right, and leave all other out. However this is a
design choice of Scala. And I think this choice makes the language a short
term language, just as a stepping stone for java programmers to better
languages.

\- end of rant -

~~~
tomp
Personally, I think implicits are one of the most useful, influential and
practical features for extensibility and code reuse. They allow flexibility
and extensibility without too much typing, while keeping things clean and safe
(type-checked).

Imagine, for example, math. Sometimes, I want 1/3 to be exact (i.e. a
rational), so that 1/3 * 3 == 1, other times I want 1/3 be a float (eg. when
doing numeric algebra). In a language with implicits, I could simply import
the correct math object that provides the correct implementation of /, and use
it in the whole module. Furthermore, if this math implementation is passed as
an implicit parameter, every other library/function I use (even in another
module) automatically uses the implementation of / that I want.

This could be used in many other situations as well, such as memory
management, where we could have an implicit policy (allocate on stack, heap,
reference-counting, GC, ...), "opening" of classes (import a class and an
implicit extension of it), and many other.

In a way, this is similar to what Haskell type-classes do, except that it can
actually be controlled by the programmer.

~~~
TeeWEE
Implicit Conversion is indeed powerfull. But so is the goto statement. My
experience with implicit conversion is: "Lets read this code, Ah i think it
does X. Let's run it, wait what is happening, ow my why is this implicits
here?"

You could argue that you should use them with care, but i'd argue not to
include them in the language. You'll go c++ all the way.

Implicits are very powerfull for creating DSL's in Scala. And indeed scala is
a good language for doing DSL's. But for me understanding what was happening
by reading code was difficult. And i think code should be easy to understand.

~~~
tomp
The difference between goto and implicits is that the former are completely
statically safe - typechecked and declared, and an IDE can at any point of the
program tell you what's being passed implicitly. They are a bit like local
(i.e. funcion-scope only) goto, which isn't that bad (and sometimes necessary,
e.g. `break <label>`).

------
JustinJ70s
Starting adopting Scala about 18 months ago after much frustration with Java's
copious boilerplate. It's like a breath of fresh air and feels in many ways
like a dynamic language thanks to type inference. We still use many Java
libraries but interfacing with Scala is a breeze. It's got more up-take than
Kotlin or Ceylon and I'd say the only decent alternative on the JVM is Clojure
but that's a different beast. If you're in a position where your after
functional programming on the JVM then consider not waiting years for Java to
catch up. Give Scala a go.

~~~
trailfox
Same experience here.

------
dkhenry
Best line in the article

""" If a grand unified theory of programming language existed, its
implementation would be called Scala """

~~~
laureny
I think Kotlin would be a better candidate for this. Scala's surface area is
way too big for this purpose.

~~~
yareally
Kotlin is a promising language, but still pretty new, so it doesn't have as
many libraries out there tailored for it yet or questions asked about weird
corner cases you might encounter (so it can make it a bit harder to track down
bugs). That has its positives if you want to be a pioneer in the language and
start popping out some useful open source libraries though.

I love what Jetbrains does though and actively read their blog as they keep
improving it. Kotlin has a bright future (I think some of the developers of
Groovy are working with Jetbrains on it), but still a language in its infancy.

~~~
vorg
Scala may be a safer solution because Kotlin is newer, but that doesn't stop
Kotlin being a better choice than other older languages like Groovy.

Today the Groovy P.M. announced they're adding statically-typed traits
([http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-
td...](http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-
td5715831.html)) to Groovy, talking about them like they're an innovation. But
they were already implemented by former Groovy++ developer Alex Tkachman
([https://code.google.com/p/groovypptest/wiki/Traits](https://code.google.com/p/groovypptest/wiki/Traits))
2 years ago. Groovy added static compilation into Groovy 1 year ago by copying
it from Tkachman's Groovy++ codebase, then announced it to the world as
"Groovy 2.0" without crediting him. Now they're trying the same trick again,
laundering the Groovy++ Traits and passing it all off as "Groovy 2.2".

Alex Tkachman is now one of the Kotlin developers (along with Groovy's creator
James Strachan). So which codebase would you trust: one laundered without
credit from someone else's implementation (Groovy), or a second try from the
actual person who wrote the first attempt (Kotlin)?

------
kclay
I started using Scala last year with the Play! 2 framework (did a write up on
it earlier this year on HN) and was a breathe of fresh air. I didn't have any
prior functional programming skills so it was a bit of learning functional
programming and the language as well, but it was a fun experience. When ever I
have the chance to choose the tech stack for a new project whether personal or
professionally, Scala and Play! is the first choice. I just finished a Scala
lib for rethinkdb (will announce later).

------
lmm
Description of apply() is backwards or at least unclear; it's not that "new
Song(name) goes to Song.apply(name)", rather, "Song(name)" ->
"Song.apply(name)", which is commonly (and automatically, in the case of case
classes) implemented as "new Song(name)".

It's worth mentioning the positive side of more concise syntax for closures -
as someone who previously used lamdbas heavily in python this is a real win.
"Seq("1", "2", "foo").map({n => stoi(n)})" should just be "Seq("1", "2",
"foo").map({stoi(_)})" \- or, in this particular case, "Seq("1", "2",
"foo").map(stoi)". Of course, the price is shown at the end as having more
than one way to write the same thing - but the differences in those examples
are (IMO) superficial and don't impair readability.

The specific problem of infix/suffix methods should be solved with 2.10's
compiler flags. They should also go some way towards improving source
compatibility (features for which the syntax is expected to possibly change
will stay behind flags), while 2.10 introduces a better binary compatibility
policy. Still, most of the criticism is fair, and I'm pleased to see a
comprehensive impression post like this.

------
anonymoushn
There seem to be some problems in the examples.

    
    
      scala> def theSquareMullet(i:Int) = i * i
      theSquareMullet: (i: Int)Int
      
      scala> def theHoffSquareMullet({ mullet: => Int }) = mullet * mullet
      <console>:1: error: identifier expected but '{' found.
           def theHoffSquareMullet({ mullet: => Int }) = mullet * mullet
                                   ^
      
      scala> def theHoffSquareMullet(mullet: => Int) = mullet * mullet
      theHoffSquareMullet: (mullet: => Int)Int
      
      scala> theSquareMullet(theHoffSquareMullet(10))
      res0: Int = 10000

------
Stranger2013
Completely new to Scala but I think that "18 ways" code sample is a bit
exaggerated. It is just a choice between C#-ish "a => a + 1" and Haskell-ish
"_ + 1".

------
eli_gottlieb
I started out with Scala three years ago on a hobby project when I wanted an
impure functional language compatible with a Java library I felt myself bound
to use.

Since then, it has become such a strong favorite that I have remodeled part of
my own hobby programming language based on Scala.

------
milos_cohagen
enjoyed the article very much! nice analysis.

