vaskir's blog

Recently I started to learn Scala (for about 2 weeks now). Here is prons and cons so far (note: I've not written any serious code yet, just have read "Scala for the impatient" and now reading "Programming in Scala" by Odersky): Prons Passing not evaluated block as argument ("by-name arguments". Allows to develop better DSLs) Macros! There are few libraries written with macros, impossible to implement in a language like c# or f# (MacWire etc.) Cons No not-nullable types (this is a huge one) Not whitespace sensitive (curly braces everywhere)  No type inference for arguments and, sometimes, for result type (signatures involving generic types may be really hairy)  No compiler warning on implicitly discarded expression value (possibly wrong code like arr.map(x => x * 2); arr.map(x => x * 3). The result of the first map is discarded silently. In contrast, F# forces us to write arr |> Array.map (fun x -> x * 2) |> ignore; arr

Some time ago I compared F# and Haskell STM implementation performance. Today I'm adding Scala into it: So, it's more than two times slower than Haskell, but more than 3 times faster than F#. Interesting.

Scala keeps surprising me. It has much good stuff that F# has. For example, I believed that statically resolved type parameters are unique to F#. Turns out this is not the case. Scala has equivalent feature called "structural types". It has nice syntax compared to F#'s statically resolved type parameters. However, it uses reflection under the hood while F# uses inlining to instantiate functions in-place at compile time. This approach should definitely have awful performance characteristics. Surprisingly, it's not the case: Static call took about 0.5 seconds, "duck typing" call took about 4 seconds. It only 8-10 times slower than static call. Frankly, I expected something like 100x - 1000x degradation. So, it's not as fast as the equivalent feature in F#, but it certainly practically useful in many circumstances.