As an erlang fan, and a jvm critic, a few people have asked me whether or not I have tried the programming language scala which compiles to the jvm and integrates with java. I had not, and was not motivated in spite of their attempts.
Then fuzzy came across scala and asked me the same question last week or so. I gave him the same reply, and felt no more motivation to do so than ever.
But you see, fuzzy is my boss and (moreover?) one of my co-workers and collaborators. This week I went on one of those web-based hunts for something unspecified that lead here and there. This time, almost out of time, and remembering fuzzy's email about scala, "there" led to http://www.scala-lang.org.
OK, playing with scala for just a couple of hours forces me to take back all the crap I have dished out about the futility of the jvm when it comes to erlang-like programming, which I think we all should be doing. (Note: I said we all should be doing erlang *like* programming, not *erlang* programming per se!)
Someone suggested some time ago I should look at scala's actor library. Now I am deeply sorry so much time has passed since I followed that suggestion. Maybe I should have given some credit to the primary author, Martin Odersky, since years ago (nearly ten???) I used his pizza language extension / compiler for java quite a bit.
I am not a terrific fan of ML-like, Haskell-like type-inferencing, etc. languages. OK, but I never got over the curve enough to feel up to my level of ease with the smalltalk/lisp-like approach. Scala is along the lines of ML and Haskell, but that is not really a turn-off for me, more of a "so what".
Like some implementations of Haskell (at least the one I used the most, hugs), scala comes with a read-eval-print loop. That helps me a *lot*. Also scala supports the conventional unix syntax for writing executable scripts. Well, it is a *little* unconventional.
Scala feels pretty good even without its actors library. But actors...
Scala's actors (and remote actors) implement a pretty good chunk of erlang-like processes, process management, and message passing. And the performance on an unmodified jvm is beyond impressive. I guess it makes sense since event-oriented java library implementations have done the same. Scala takes that somewhat clumsy approach (in java) and wraps it up in a much nicer language and a richer erlang-like library.
Nicely done. Nice mix of objects and modern functional programming with pattern matching, etc. Message passing, pattern matching, and scalable "actors" -- that's a good mix for the future.
Scala is fairly new and mature: hopefully more people will take a look at it without hestiating like I did. The lift web framework is another reason to look, although not what I am after at this point.
9 comments:
Hi Patrick,
Scala has improved is scripting-fu recently. The following lift new project script can be executed with a simple scala new_proj.scala.
Since you seem to like the actor library, I wonder if you've heard about Actalk (http://www-oasis.lip6.fr/~briot/actalk/actalk.html). In Smalltalk since 1988 :-).
Martin
New scripting-fu -- great.
Actalk -- vague recollection from early OOPSLAs.
Thanks
One of the reasons I've been very interested in looking into scala is the exact thing that you mention here -- "erlang-like" concurrency.
I'm curious, though, if anybody knows of any inherent limitations since scala is based on the JVM that would limit its efficiency in scaling (concurrency -wise) that something like erlang doesn't need to worry about?
I don't even know if that's the right way to ask the question I'm after, but perhaps someone can make heads or tails of it :-)
Thanks!
ps: this post is on reddit, too:
http://programming.reddit.com/info/1wumi/comments
It's possible that some other discussion might pick up there that you could be interested in as well.
You might want to look at the Skittr example code that scales pretty well (hundreds of thousands of Actors) on a single box.
Scala Actor's inter-process communication is currently less than optimal. Part of the issue is serializing Java objects is non-trivial (serializing lists, hashes, strings, and numbers is a lot easier).
However, the guy who is working on Scala Actors is a wicked bright, hard working, and responsive guy and he's making lots of headway toward making Scala Actors darn good.
In terms of specifics, there's still an inter-Actor message passing overhead in the JVM. In the language shoot-out, Erlang is 4 times faster than Scala for pure message passing. That's a penalty, but the JVM makes up for it if you actually have to process the message.
For those interested, the paper which describes the architecture of Scala Actors can be found here:
http://lampwww.epfl.ch/~odersky/papers/jmlc06.pdf
It's an excellent read, very enlightening for the non-erlang programmer.
It doesn't discuss issues that David suggests, I haven't seen any details (nor have I looked at the whole implementation) of the "mailboxes" that the paper discusses, but I'm sure it could be an issue somewhere.
Anyway, kind of on the long side but definitely worth the time.
I think in closures and higher-order functions, so doing software without them is painful. The only pragmatic functional languages are Scala, F#, and CAL, and of those only Scala is object-oriented, hence I use Scala by process of elimination.
"pragmatic functional languages... of those only Scala is object-oriented"
Clearly Martin Odersky has been iterating over that combination since well before Scala, and Scala shows the benefits of his work. While I like languages that seem simpler to me, such as Scheme and Smalltalk, Scala does not seem to me overly complex for what it provides.
I used Pizza a fair bit and enjoyed it. Scala is just so much better still... it is nice to have a mostly-functional, yet fully object-oriented language with pattern matching, actors, and mailboxes.
@warren
F# ? what about Nemerle then ?
Post a Comment