A recent comparison was made with scala and java collections. Lots of interesting tidbits. http://www.takipioncode.com/2014/01/23/java-scala-guava-and-...

It seems that the performance difference has little to do with temporary objects, but is to be fixed 2.11 anyway: https://groups.google.com/forum/#!msg/scala-internals/Fw37Nm...

> getting a value out of a map automatically creates another new object

Do you have a code sample for this?

From MapLike.scala

def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value }

From HashMap.scala

def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }

Out of curiosity, how would you rather have them be implemented? You either return an Option, or you will have to deal with null pointers.

Not sure how familiar you are with the Scala syntax, but that code actually has null pointer problems. The apply function turns Options into null pointers. They've given me the worst of both worlds, not only do I get null pointers, I get to have extra garbage created to accomplish it.

Yep I get that point. However, how would you avoid extra allocations and maintain safety (no nulls)?

I actually have no problem with the extra allocations if they maintain safety (that's not quite true, I actually need to break safety occasionally).

The problem is that the incoherent design of the collections library means that it is not clear to the programmers of the default mutable hash map lookup what they are striving for.

If they were striving for performance they would use a model that allowed for NPE against safety, that had allocation semantics that were sensible. Conversely, if safety was the overriding concern they wouldn't allow for the NPE.

Instead, in one of the most central data structures of the language we get unreasonable behavior. This is clearly a sign of bad design, thus reputing the original assertion that the Scala collections library were a good example of type programming.

PS: To trivially answer your question, they should have inverted the implementation here. A NPE throwing method for lookup wrapped with option sugar would make way more sense than the inverse.

Makes sense, thanks for your answer :)