Does Scala Scale Better Than Other Jvm Languages

Does Scala scale better than other JVM languages?

Scala is "scalable" in the sense that the language can be improved upon by libraries in a way that makes the extensions look like they are part of the language. That's why actors looks like part of the language, or why BigInt looks like part of the language.

This also applies to most other JVM languages. It does not apply to Java, because it has special treatment for it's basic types (Int, Boolean, etc), for operators, cumbersome syntax that makes clear what is built in the language and what is library, etc.

Now, Scala is more performatic than dynamic languages on the JVM because the JVM has no support for them. Dynamic languages on JVM have to resort t reflection, which is very slow.

What is the fastest language that runs on the JVM

See the Computer Language Benchmarks Game:

Java is very fast.

Scala almost as fast.

JRuby is 10-30 times slower.

Groovy is slow too.

On Performance and Java Interoperability: Clojure vs. Scala

I think either language will be fast enough for you. When comparing Python and Java, it seems a bit unreasonable to blame the language for the speed difference. Java is compiled JIT (except on mobile devices*) whereas Python is interpreted. Just because both use a bytecode does not mean the implementations will have even remotely comparable performance. But both Scala and Clojure are JVM languages so they should have similar performance.

Scala has a few implementation advantages over Clojure and I would expect somewhat higher performance. Although Scala's static typing would normally translate into a speed advantage over Clojure's duck typing, Clojure does support type hinting which can speed up code considerably. Possibly, ordinary Scala is faster than ordinary Clojure, but you only need to optimize the bottlenecks. Most of a program's run time is generated by a small amount of the actual code.

Regarding interop w/ Java, Scala is closer to Java but I'm sure both languages interoperate well. In Programming Clojure Stuart Halloway writes: "[you can access] anything you could reach from Java code.".

And since Scala author Martin Odersky wrote Sun's Java compiler, I kinda think no balls have been dropped on the Scala side, either. :-)

You would be hard-pressed to pick two better languages, though I like Ruby also. Why are you worried about which one to try? Why not try them both? Scala is more likely to be "the next Java", while it's hard to imagine that Lisp will finally take off after not doing so for over 50 years. But it's clear that Lisp is on its own unique level of abstraction, and Clojure is fairly simple, so Scala + Clojure won't be that much harder than just (the rather complex) Scala and I'm sure you will be glad you did it.

And for that matter they interoperate...

* dalvik (android's JVM) got a JIT compiler in 2.2 version in 2010

Scalability in Scala

In the context of Scala, Odersky usually means that it is scalable in the sense that it can be used for a wide range of tasks, from simple scripting to large libraries to behemoth enterprise applications.

It's good for scripting because of its type inference, relatively low verbosity (compared to Java), and functional style (which generally lends itself to more concise code).

It's good for medium size applications and libraries because of its powerful type system, which means it is possible to write code that mostly or only produces errors at compile time rather than runtime (to the extent that is possible). The Play! framework in particular is founded on this philosophy. Furthermore, Scala runs on the JVM and therefore can harness any of the many, many Java libraries out there.

And it's good for enterprise software because it compiles to JVM bytecode, which already has a great track record in enterprise software; further, the fact that it's statically typed makes the maintenance of very large codebases much easier.

Scala is also applicable to a number of other areas, making it even more "scalable": concurrency/parallelism and domain-specific languages come to mind.

Here is a presentation by Odersky, if you start at slide 6 and go forward, you'll see him explain some other uses of Scala as well.

Groovy and Grails vs Scala, Why Twitter choose Scala?

Maybe you can find your answers here: http://www.artima.com/scalazine/articles/twitter_on_scala.html

Paragraph "Reliable, high performance code" catches it pretty well :-).

Bill Venners: I’m curious, and the Ruby folks will want it spelled
out: Can you elaborate on what you felt the Ruby language lacked in
the area of reliable, high performance code?

Steve Jenson: One of the things that I’ve found throughout my career is
the need to have long-lived processes. And Ruby, like many scripting
languages, has trouble being an environment for long lived processes.
But the JVM is very good at that, because it’s been optimized for that
over the last ten years. So Scala provides a basis for writing
long-lived servers, and that’s primarily what we use it for at Twitter
right now. Another thing we really like about Scala is static typing
that’s not painful. Sometimes it would be really nice in Ruby to say
things like, here’s an optional type annotation. This is the type we
really expect to see here. And we find that really useful in Scala, to
be able to specify the type information.

Robey Pointer: Also, Ruby doesn’t really have good thread support yet.
It’s getting better, but when we were writing these servers, green
threads were the only thing available. Green threads don't use the
actual operating system’s kernel threads. They sort of emulate threads
by periodically stopping what they are doing and checking whether
another “thread” wants to run. So Ruby is emulating threads within a
single core or a processor. We wanted to run on multi-core servers
that don’t have an infinite amount of memory. And if you don’t have
good threading support, you really need multiple processes. And
because Ruby’s garbage collector is not quite as good as Java’s, each
process uses up a lot of memory. We can’t really run very many Ruby
daemon processes on a single machine without consuming large amounts
of memory. Whereas with running things on the JVM we can run many
threads in the same heap, and let that one process take all the
machine’s memory for its playground.

Alex Payne: I’d definitely want to hammer home what Steve said about
typing. As our system has grown, a lot of the logic in our Ruby system
sort of replicates a type system, either in our unit tests or as
validations on models. I think it may just be a property of large
systems in dynamic languages, that eventually you end up rewriting
your own type system, and you sort of do it badly. You’re checking for
null values all over the place. There’s lots of calls to Ruby’s
kind_of? method, which asks, “Is this a kind of User object? Because
that’s what we’re expecting. If we don’t get that, this is going to
explode.” It is a shame to have to write all that when there is a
solution that has existed in the world of programming languages for
decades now.

Packages in JVM languages

As mentioned in the comments to the question Travis Brown is correct, scalac does not place any such constraints or restrictions on the paths or names of files of the source and you can even specify multiple packages in one file if you wish.

However, the bytecode generated by scalac puts the bytecode classes files in the necessary directory structure required by the appropriate classloader.

Here are some examples showing the flexibility (I do not necessarily advocate these styles, just showing the flexibility).

// in packages1.scala file in local directory
package my {
  package states {
    sealed trait State
    case class CheckingOut(shoppingCartId: Long) extends State
    case class ConfirmedOrder(orderId: Long) extends State
    case class ItemShipped(orderId: Long, itemId: Long, quantity: Int) extends State
  }
}

And this...

// in packages2.scala file
package com.foo.bar

sealed trait Scale
case object WebScale extends Scale
case object LolScale extends Scale
case object RoflScale extends Scale
case object WatScale extends Scale

And this style is possible too:

// in packages3.scala file
package foo {
  package awesomeness {
    class Main extends App {
      println("Bananas are awesome")
    }
  }
}

package foo {
  package lameness {
    class Main extends App {
      println("Congress is pretty lame, honestly")
    }
  }
}

As well as this...

package foo
package bar

// now we are in package foo.bar for remainder of file unless another package statement is made

Here is the resulting source and compiled bytecode tree:

$ tree
.
├── com
│   └── foo
│       └── bar
│           ├── LolScale$.class
│           ├── LolScale.class
│           ├── RoflScale$.class
│           ├── RoflScale.class
│           ├── Scale.class
│           ├── WatScale$.class
│           ├── WatScale.class
│           ├── WebScale$.class
│           └── WebScale.class
├── foo
│   ├── awesomeness
│   │   ├── Main$delayedInit$body.class
│   │   └── Main.class
│   └── lameness
│       ├── Main$delayedInit$body.class
│       └── Main.class
├── my
│   └── states
│       ├── CheckingOut$.class
│       ├── CheckingOut.class
│       └── State.class
├── packages1.scala
├── packages2.scala
└── packages3.scala

8 directories, 19 files

I am not sure if Clojure supports such flexibility but Clojure convention is to use the Java convention of structuring source code with it's commonly used build tool lein (see leiningen tutorial here).

The one thing to note, however, is that in both Scala and Clojure there appears to be a departure from the $DOMAIN.$APPLICATION format that is often used in the Java world (e.g. com.oracle.jdbc..., org.hibernate.session..., etc). In Scala you will see the $DOMAIN part of the package name being taken out completely (e.g. scalaz..., akka.{actor,io, ...}, etc.).

Also of note is the way you can import from packages in Scala:

• Import all public "things" in foo.bar package: import foo.bar._
• Import just one class/trait/etc (just like Java): import foo.bar.Baz
• Import one class/trait/etc from package and rename it in current scope: import foo.bar.{Baz => FooBarBaz}
• Import a subset of things from package: import foo.bar.{Baz, Boo, Bla}

Also of note is package private scoping in Scala:

package foo.bar

class Baz{
  private[bar] def boo[A](a: A)
  private[foo] def bla[A](a: A)
}

Above boo is private to the foo.bar package (and subpackages) and bla is private to foo and all it's subpackages.

For further details read the Scala language specification and related links:

• Section 9.2 "Packagings", 9.3 "Package Objects", 9.4 "Package References"
• A Tour of Scala: Packages

Does JVM memory overhead scale linearly, or is it constant?

The overhead is about 10MB + 4xC-memory.

The 10MB is the JVM without anything. Java 7 64bit version uses about this much.

The 4x memory is obviously a "guesstimate" because it depends on which data types you use. If you use 100% references in java they take up about 4 times as much memory. The same difference there is between int and Integer.

If there are a lot of malloc/new in your C code there will be that in Java too, and Java's GC might not run when you want it to, so there's also an overhead of "dead references not yet cleaned up" that depends greatly on things out of your control (GC timing).

What is the purpose of Scala programming language?

One of the things mentioned in talks by Martin Odersky on Scala is it being a language which scales well to tackle various problems. He wasn't talking about scaling in the sense of performance but in the sense that the language itself can seem to be expanded via libraries. So that:

val lock = new ReentrantReadWriteLock
lock withReadLock {
   //do stuff
}

Looks like there is some special syntactic sugar for dealing with j.u.c locks. But this is not the case, it's just using the scala language in such a way as it appears to be. The code is more readable, isn't it?

In particular the various parsing rules of the scala language make it very easy to create libraries which look like a domain-specific language (or DSL). Look at scala-test for example:

describe("MyCoolClass") { 
  it("should do cool stuff") {
     val c = new MyCoolClass
     c.prop should be ("cool")
  }
} 

(There are lots more examples of this - I found out this one yesterday). There is much talk about which new features are going in the Java language in JDK7 (project coin). Many of these features are special syntactic sugar to deal with some specific issue. Scala has been designed with some simple rules that mean new keywords for every little annoyance are not needed.

Why does Scala have very little enthusiasm about it?

I think there exist users who are pretty passionate about Scala. Daniel Spiewak writes a lot of blog articles about the language, and the Twitter people often talk about rewriting portions of their software in Scala. The big reason that Clojure may seem, in comparison, to generate more enthusiasm is because, well, Clojure is a dialect of Lisp, and Lispers tend to be very passionate about their language. I think that idea is key: a lot of Clojure programmers use Clojure because they love Lisp, not because they hate Java, whereas a lot of Scala programmers (not all, but a lot) use Scala not because they love object-oriented functional languages, but because they don't want to use Java.

---

Related Topics