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?

[the1]

let's say you have more than one future:

    findAirline:        AirlineCode =>                Future[Option[Airline]]
    getFlightsForToday: Airline =>                    Future[Seq[Flight]]
    findAvailable:      Seq[Flight] => Constraints => Future[Option[Flight]

compose them so that I get:

    findFlight: AirlineCode => Constraints => Future[Flight]

I don't want `Future[Option[Flight]]` since Future has own error handling (using Try). No cheating by using scalaz monad transformer.

[Uchikoma]

From my point of view and understanding, for is not good for this. Isn't it blocking? Say you have

  for 
     a <- forA
     b <- forB
     c <- forC(a)

it does not do a and b in parallel and then c, or does it?

[yareally]

Actors and the way Scala handles async is one of the reasons I wanted to get into using Scala on Android actually. The awkward way Android handles it is chock full of Java boilerplate and Scala's way is just much more elegant.

Another feature that got my attention was the ability to have a SQL framework that handled things similar to LINQ. I haven't tried it much yet, but Squeryl[1] has looked promising for being a Scala equivalent. I may have to look into Akka more though as that will easily take care of async SQLite calls as well[2].

[1] http://squeryl.org/introduction.html

[2] http://www.gamlor.info/wordpress/2012/05/async-sql-and-akka/

[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++.

[habosa]

Scala = scalable language. This is for all the reasons you said. Because the language allows so much, library designers can really extend the language itself and create whole new paradigms or do other powerful things you just can't do in any other language that's this stable and portable.

[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

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

[bad_user]

> 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

I'd say that's a bad idea.

People keep saying that Scala is not an opinionated language and that you have to make choices and stuff. That's not true and in fact, Scala is a very opinionated language that makes imperative code painful. That's why some beginners get so frustrated when they pick it up. Because they come with certain wrong assumptions about how features in Scala work.

Examples: Scala does not have "break" or "continue", while "return" does not behave as many people think it behaves. The "yield" keyword in "for" expressions is also totally different than the "yield" in C# or Python or Ruby. Actually "for" expressions in themselves are actually monad comprehensions - powerful, elegant, but definitely not your grandma's foreach. Also, collections are immutable by default.

[_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.

[mooreds]

Do you have any links to suggested style guides?

Google returns this: http://docs.scala-lang.org/style/ or this: http://davetron5000.github.io/scala-style/index.html but do you have any that you'd recommend?

[laureny]

> 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.

This reminds me a lot of C++: powerful but unless you agree on a consistent style and only using a subset of its functionalities, you end up with nightmare code bases.

[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.

[yareally]

Why don't you like implicits? Even the more conservative language C# has them.

It beats the heck out of having to do the following in Java:

BigInteger x = new BigInteger(someBigNumString);

BigInteger sum = x.add(new BigInteger("1000");

When you can do this in Scala (or similar in C#):

BigInt x = BigInt(someBigNumString)

BigInt sum = x + 1000

If you're going to say it can be abused, lots of things can be abused in any language. I prefer sanity in this case for implicits over risk of abuse. Having to use something like BigInteger in Java without implicits just makes my head hurt trying to read and write code using it.

[eli_gottlieb]

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

You mean implicit conversions, right? Because implicit parameters are the single best thing since sliced bread.

[happy_dino]

Could you expand on what exactly you feel is syntactically inconsistent?

Considering features: Well, it certainly depends where you come from. If you come from Scheme, Scala is huge. But if you come from Java or C# or F# or ..., Scala is refreshingly small, consistent and self-contained.

Regarding implicits: Most languages have implicits, they are just hard-coded into the language and will be there forever. In Scala, you can just de-import the ones you dislike and if enough people dislike those, they might even get deprecated and removed.

Implicits seem to be really the feature all people except actual Scala users love hating, especially exactly those kinds of implicits which aren't even widely used anyway. Implicit conversions make up maybe 10% of all usages of “implicit ” and require a feature import.

[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.

[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.