Scala News Aggregators

There's been a steady increase in the number of people writing about Scala online. Hopefully we here at Scala Blogs have done our part to help encourage this. However, with more and more people writing about Scala, it gets harder and harder to find all the Scala-related content online. Here's a short guide to the Scala content aggregators I've found.

• Scala Blogs: We have our very own aggregators. The bottom two panes on the right side of the screen show the most recent links tagged with the "scala" label on del.icio.us and the most recent results for "scala" on Google Blog Search. (Advantages: Content not found by other aggregators. Disadvantages: small and hard to find, no history unless you visit del.icio.us or Blog Search directly.)
• Scala Buzz: Artima's Scala Buzz forums aggregate content from several prominent Scala bloggers. It also provides in-site discussion of articles.
• Planet Scala: David MacIver put together the excellent Planet Scala, which also aggregates content from prominent Scala blogs. He's pretty good about adding new feeds as they become relevant, but as far as I can tell you can't submit one-off links.
• Scala Room on FriendFeed: Robin Barooah put together a Scala room on FriendFeed. This one is probably my favorite, as it aggregates feeds specified by the administrator as well as allows individual members to submit one-off links. It also allows for in-site discussion. It doesn't get much traffic, but some of the Bay Area Scala Enthuisasts ocassionally hang out here.
• Scala Reddit: Amir Michail set up a Scala subreddit a few months ago. It's similar in concept to the FriendFeed room, except it doesn't automatically add content from specified feeds and seems to have languished from lack of attention.

My favorites are probably the FriendFeed Room and Planet Scala. Do you know of any others that I missed?

'Application' trait considered harmful

Programmers new to Java are often confused and annoyed by the overly complex structure of a basic Java program. One line in particular, "public static void main(String[] args)" stands out as lengthy and cryptic.

class MyJavaApp {
  public static void main(String[] args) {
    // ... body ...
  }
}

Scala, descended from Java and reusing much of Java's ecosystem, has a similar requirement, though a slightly less onerous one.

object MyScalaApp {
  def main(args: Array[String]) {
    // ... body ...
  }
}

Now, Scala claims to be able to scrap Java boilerplate in many cases, and simple program construction is no exception. A very ingenious Scala programmer devised the Application trait, which allows us to further simplify the declaration of a simple program. By simply mixing in the Application trait, we can turn any object into a program.

object MyScalaApp extends Application {
  // ... body ...
}

For pedagogy, this second approach is clearly preferable. When teaching Scala to programmers unfamiliar with Java, it's no longer necessary to go into the details of a wordy, vestigial Java pattern. When teaching programmers familiar with Java, it can serve as yet another example of how Scala can make their lives easier.

Unfortunately, the Application trait is evil.

Given the simplicity of the pattern, one would be justified in assuming that both of the Scala code snippets are functionally equivalent. This is wrong. To understand why, let's look at the entire source code for a possible implementation of the Application trait. (The actual source code is slightly more involved, but not in any way that affects this discussion.)

trait Application {
  def main(args: Array[String]) {}
}

How does it work?, you might ask. How can it run my code without referencing it in any way? To understand how the Application trait works, it's important to understand Scala constructors.

In Scala, the body of a class also doubles as its primary constructor. Likewise, the body of a singleton object doubles as its only constructor. The Application trait works by running the entirety of the application in the constructor for MyScalaApp. This is a clever trick for reducing a bit of boilerplate code, but it turns out to be a catastrophically bad idea.

It's a bad idea for two reasons.

First, concurrency is broken. The JVM does not allow other threads to access a class during initialization. You can easily get yourself into deadlock by writing concurrent code in classes that use Application. (See Ticket #746)

Second, performance is broken. HotSpot doesn't bother to optimize class initialization. This can cause performance differences of several orders of magnitude in classes that use Application. (See this blog post and the ensuing mailing list discussion.)

While the Application trait may save you a line of code, it comes with many severe and hidden pitfalls. Hopefully it will be removed from the standard library, or at least deprecated. In the meantime, save yourself the headache and avoid Application in your applications.