Comments on Ruby, Javascript, Erlang blog: Snakes, Gems & Coffee: The Scala vs Erlang Debate, Part 2: The Geek Off

Scala is a hybrid Object-Oriented/Functional Progr...

2009-07-18T02:28:03.284-05:00

Scala is a hybrid Object-Oriented/Functional Programming language on the JVM. When I heard that Twitter was using Scala, I was curious and started collecting all the sites and articles to learn scala programming. If you are interested check the link below for the big list I have gathered (more than 200 sites) for learning scala programming.
http://markthispage.blogspot.com/2009/06/more-than-100-sites-to-study-scala.html

Matt: Actually I readily admitted my factual mista...

2009-06-20T17:10:40.388-05:00

Matt: Actually I readily admitted my factual mistake with "you are absolutely correct - Erlang is impure!". I suggest you read the all the comments. What did I say that was dismissive of that particular fact?

Other "corrections" in the comments have argued that Scala is just as impure as Erlang. My argument is that there is still a difference in the degree to which Scala promotes a certain style of programming that is not functional in nature.

I am happy to discuss that, but let us separate what I did say to what you said I said because they are two different things.

An argument you made in your article was, "Scala i...

2009-06-20T12:46:04.113-05:00

An argument you made in your article was, "Scala is not a pure functional programming language and therefore many corollaries from lambda calculus cannot be applied for optimization purposes", in particular, in Erlang, you argue "there is a lambda calculus optimization that can be taken advantage of that will ease away our troubles called tail-recursion."

When this is pointed at as a flawed argument, you replied, rather than admitting a mistake, by "clarifying", and dismissing factual criticism as irrelevant concerns from "academic" vs "real-world" programmers. The truth is, if you invoke academic concepts like "corollaries from lambda calculus" and try and draw real-world conclusions about it, it's reasonable to criticise the validity or otherwise of your argument, and it is certainly not "like an ostrich digging its head in the sand" to do so.

Jayden: best not misquote him either;) Emil Ivano...

2009-06-20T11:14:40.031-05:00

Jayden: best not misquote him either;)

Emil Ivanov: Actually I did mention the two types of actors in Scala, please see:
"So Scala created this concept of a very peared down event-based actor, which does not have all the functionality of thread-based actors but does not incur the penalty of needing to be backed by a native thread."

Where is the error? If you have a lot of thread-based actors you are in trouble in Scala. If your app needs a lot of thread-based actors then you aren't going to be able to scale as easily as with event-based actors which are much more limiting. This *might* be a benefit in your applications, but if you don't change the way you write your software to be more event-based then you still have a scaling issue.

Paul Prescod: Let me respond to this comment since I have already responded to James' comment you mentioned: "2. there is no relationship between being purely functional and implementing TCO."
This is definitely something I want to clarify in a future post, but I do see a correlation between the fact that Scala actively encourages mutability with thread-based actors that need to consider thread-safety as an extra thought exercise in development, thread-based actors are less scalable, heavier weight (thus you need to throw more hardware are the problem) and debugging, troubleshooting costs go way up due to this complexity. There are some advantages to this also, namely legacy support. This is a very practical reason to do this in Scala. If you aren't concerned with legacy, I see the Scala practical impurity (not just theoretical impurity) as problematic and adding cycles to development as well as hardware to your production environments.

I commented earlier on the "purity" comment. Yes, Erlang is not a pure functional programming language in an academic sense. It is practically pure. It does have a process map that you can modifying interally and some I/O actions do have consequences, but these were added for practicality, not to encourage mutability in your software writing. The programming style encouraged by Erlang is pure functional in nature, NOT a messy hybrid that Scala actively encourages.

This is a fundamental difference and pretending it doesn't exist because of an academic definition is like an ostrich digging its head in the sand.

I have already mentioned that there are some positives as well as negatives to this.

There are practical limitations that Erlang has. Perhaps I didn't do enough of a job of highlighting these although I did mention them, so that might have been a very valid point. Highlight those practical limitations. This blog post is for people that build real world production systems NOT academics discussing technicalities.

And lastly I only used "debate" in the sense that it is a debate as to which language is right for your needs.

We can all have different opinions on the cost of a hybrid approach in relation to TCO, but I will not be changing mine just to sweep Scala's limitations (as I see them) under the carpet.

Hope that helps clarify a little.
Susan

Paul Prescod: I don't think Susan ever said facts ...

2009-06-20T10:29:55.983-05:00

Paul Prescod: I don't think Susan ever said facts were debatable.

It is interesting that you (Paul) are implying there cannot be any debate in terms of which programming language you want to use. Apparently you think Scala is the only language anyone should use?

Good to know, Paul.

s/I have no accepted/I have NOW accepted/

2009-06-20T10:20:49.859-05:00

s/I have no accepted/I have NOW accepted/

@puzza007 you were right, I had to dig around in b...

2009-06-20T10:20:13.765-05:00

@puzza007 you were right, I had to dig around in blogger to find it. I didn't receive the email notification for this and a few other comments. I have no accepted them all now.

Sorry for any confusion. I will be responding next week regarding some comments.

In addition I wish to point out that Erlang has be...

2009-06-20T08:52:24.349-05:00

In addition I wish to point out that Erlang has been used in large scale production systems for over 15 years already. I think it's real world usage and maturity far exceeds Scala's currently.

I hardly think that was a good argument for Scala in comparison to Erlang!

I do wish to clarify my opinions though. I personally much prefer using Erlang over Scala for multiple reasons! However, despite Scala's current relative immaturity (which will not be so much of an issue after a few years if it continues with it's current momentum) it has potential. I don't really know if I would be swayed by Scala at that point, because I can't predict the future, but I do leave my mind open to that possibility.

I do enjoy seeing Scala's fan boys getting frazzled by these benchmarks though:)

Peace!

I find it interesting that it is a "single" benchm...

2009-06-20T08:42:29.369-05:00

I find it interesting that it is a "single" benchmark when Erlang wins, but not when Scala wins.

Also my blog posts about Erlang vs Scala are specifically talking about multi-core applications (on servers primarily). I have not suggested that Erlang is a multi-purpose programming language for desktop applications. However, at the same time I do not believe Scala fits the multi-purpose programming language that would be particularly suitable for desktop applications either. I am a little confused by your argument?

I have made no such claims about multi-purposeness, nor do I believe Scala fits that profile either. So the comment seems a little out of context.

Perhaps you could expand if I am missing your point?

Losing a single benchmark is hardly what I would c...

2009-06-20T08:04:28.403-05:00

Losing a single benchmark is hardly what I would call embarrassing for Scala, a more general purpose language. It would be interesting to see how Erlang pays off in the real world right now, aside from benchmarks. How many and what types of programs are written for multiple cpus and are just waiting to be rewritten in Erlang so that they execute more quickly? Would programs written in Erlang be faster on current desktops? How many CPUs do you need to see Erlang do things more quickly?

@puzza007 I haven't withheld any comments on this ...

2009-06-19T16:48:05.284-05:00

@puzza007 I haven't withheld any comments on this post yet. When did you make the comment? I don't see it in blogger.

Why didn't you allow my comment earlier?

2009-06-19T16:27:47.350-05:00

Why didn't you allow my comment earlier?

Actually I see a very different story in the resul...

2009-06-19T10:17:23.582-05:00

Actually I see a very different story in the results.

The bigger issue with the results seems to show that Scala really isn't scalable in resource usage and for longer running computations is outperformed by Erlang. Also I noticed how the benchmark tests are running an older Erlang before the new SMP scheduler was introduced.

Based on the benchmarks I would be very worried about memory availability for Scala systems that were more than trivial. It looks very worrying to me actually.

The big question is why anyone is still only interested in sequential (linear) performance when parallel performance is clearly what matters in a multi-core age.

Take a look at this concurrent benchmark to look at real world concurrent results:
http://shootout.alioth.debian.org/u32q/benchmark.php?test=threadring&lang=all&box=1

Scala / Erlang running time ratio = 2.921866217

Note: the above benchmark used an older Erlang VM without the new SMP scheduler which is likely to vastly improve on this performance. Thus the ratio is likely to be even more embarrassing for Scala.

erlang is quite a bit slower than scala for sequen...

2009-06-19T09:40:53.135-05:00

erlang is quite a bit slower than scala for sequential stuff. http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=scala&lang2=hipe&box=1

"One major side effect of being a pure functional ...

2009-06-19T04:29:48.859-05:00

"One major side effect of being a pure functional programming language is that there is NO STATE. There is no way to pass "state" around, but there is a lambda calculus optimization that can be taken advantage of that will ease away our troubles called tail-recursion."

I think what you're trying to say here is that there's no mutable state/variables in Erlang. To achieve a state update you'd typically call your recursive loop function with a new variable representing the updated state. Tail-call optimisation makes sure that this can be done with a constant stack size.

Jason: James was simply correcting facts in the ar...

2009-06-19T03:24:37.721-05:00

Jason: James was simply correcting facts in the article. It isn't a "debate". It's just getting mistakes fixed. I noticed the exact same things in my reading. 1. Erlang is not purely functional and 2. there is no relationship between being purely functional and implementing TCO.

Momingle: Ruby does not have a simple syntax. It is much more complicated than (for example) Python or Javascript, to say nothing of Lisp or Smalltalk (which are even simpler). For example, Ruby has begin/end and curly braces. If statements can go at the beginning or end of lines. It overloads the "<<" operator to mean a bunch of different things. There are a ton of different kinds of attributes (instance attributes, class attributes, class instance attributes, maybe more). It has different syntaxes for blocks versus methods versus (lambda) functions, each with unique syntax, when Javascript, Lisp and Python get along with just functions.

"... [Scala] makes a rather large assumption [...]...

2009-06-19T02:25:08.511-05:00

"... [Scala] makes a rather large assumption [...] that the Java libraries being used are thread-safe."

This is not correct.
It just doesn't. Actually - it's the other way around - Scala actors allow you to run non thread-safe code in parallel. The code inside of the actor doesn't need to be thread-safe. That is one of the advantages of using actors over threads with locks.

"However, within the same process/actor there are ...

2009-06-19T02:19:23.282-05:00

"However, within the same process/actor there are no side effects in Erlang."

The process dictionary?

Also, I'd argue that trying to make a distinction about purity "within the same process" is largely moot: if I call io:format(), it produces a side effect. It makes no practical difference if it's implemented by sending a message to another process that performs the side effect, or whether the current process performs the side effect. You get no more purity than if you'd called println in Scala.

"I thought I had mentioned that the lack of full tail-recursion support in Scala was due to the JVM not being stackless like the Erlang VM" -- the Erlang VM uses a stack, doesn't it?

Would someone please mention execution speed? My i...

2009-06-19T02:17:40.851-05:00

Would someone please mention execution speed? My impression from reading around is that Scala is not much worse than Java whereas Erlang is a whole lot worse. Execution speed may have more to do with tooling than language design, but it's certainly a factor in deciding on a language.

I started learning both Scala and Erlang the same ...

2009-06-11T16:59:11.576-05:00

I started learning both Scala and Erlang the same time. I started with Scala first, went through all the tutorial and guides. Then I went to erlang. From language perspective, I found erlang's syntax much cleaner. That is probably due to Scala is a static type language and erlang is a dynamic type language and Scala has to be both OO and FP the same time. But even the FP syntax in Scala seems a bit overkill to me. Pattern matching is a lot easier in erlang than using case class in Scala. That is just my beginner's opinion. I am no language expert. I just voice my opinion as a developer who wants to get things done and quick. That means I want to be able to learn a language fast. Syntax does matter. One of the reasons so many developers were able to switch to Ruby quickly is due to its simplicity of its syntax.

Apparently I misread your name...sorry James.

2009-04-22T23:19:00.000-05:00

Apparently I misread your name...sorry James.

Jason: I think actually the more important point s...

2009-04-22T23:18:00.000-05:00

Jason: I think actually the more important point she might be making is between hybrid vs non-hybrid functional languages. Scala tries to marry up a quadrillion things up in one language, whereas Erlang is simply functional.

Whether it is pure or not, I don't think that was the point...it is more a matter of hybrid-ness NOT purity.

Having a (one-sided) academic debate about definitions of functional language purity seems rather pointless.

@James I thought I had mentioned that the lack of ...

2009-04-21T22:47:00.000-05:00

@James I thought I had mentioned that the lack of full tail-recursion support in Scala was due to the JVM not being stackless like the Erlang VM? I will reread tomorrow morning to find the offending part of the posting.

@James I will clarify what I meant: In an inter-pr...

2009-04-21T22:44:00.000-05:00

@James I will clarify what I meant:
In an inter-process (or inter-actor) frame of reference, you are absolutely correct - Erlang is impure! I should have caught this in my proof-reading, but since I am terrible at both writing and proof-reading it was inevitable that I missed this (and probably quite a few others).

However, within the same process/actor there are no side effects in Erlang. Scala allows side effects within a thread/actor. Erlang and Scala are fundamentally different in this regard. And it is this distinction I was referring to throughout the posting.

Thanks for keeping me honest!

Another comment. The reason Scala doesn't have fu...

2009-04-21T19:09:00.000-05:00

Another comment. The reason Scala doesn't have full tail call optimization has nothing to do with its impurity. Scheme, SML, OCaml, and Erlang are all impure but have tail recursion.

Scala's lack of tail recursion is entirely due to a trade-off. The JVM doesn't do tail recursion itself. It is possible to add tail recursion on top of the JVM using various tricks, but they are expensive. SISC does its own stack based heap and Kawa uses trampolining.

An interesting compromise, available in Clojure now and Scala soon, is to let programmers manually specify where they want to do tail calls via trampolining.