Comments on: Erlang vs. Scala

By: tam

tam — Mon, 11 Aug 2008 03:05:36 +0000

Nice to meet you

By: Humanist → Why Make Erlang a Functional Language?

Humanist → Why Make Erlang a Functional Language? — Fri, 27 Jun 2008 02:30:12 +0000

[...] — Yariv Sadan [...]

By: Shawn

Shawn — Mon, 02 Jun 2008 06:00:38 +0000

If you want to waste some more time it would be interesting to see a comparison with Clojure in these categories :)

As a Lisp on the JVM, there will be similarities with Scala’s answers on features like hot code swapping, garbage collection, recursion, network I/O, libraries, and reliability. But I have to say David makes a good case on all of those.

Clojure’s author has issues with “location transparency”, so don’t hold your breath on that type of distribution.

Since it’s Lisp, you get a lot of the dynamicism and FP concepts that you know and love (a REPL, of course; I’m not sure how easy it is to get a remote one).

A big feature of Clojure is its immutable data structures, which all work with the built in software transactional memory and asynchronous agent/action systems for concurrency. In terms of scheduling, I believe those systems are built on threads.

No Mnesia, but I wonder if one could make a really nice one using the pure Java version of Berkeley DB.

I’m not trying to change your mind. You like Erlang and it has what you need today. But as a language for Java environments, it looks promising.

By: Eric

Eric — Fri, 30 May 2008 19:38:47 +0000

This is a great post. I love your blog, keep it up.

By: Your Bear

Your Bear — Thu, 29 May 2008 23:13:45 +0000

I am very surprised that the OTP framework of Erlang/OTP was not mentioned. (Or did I miss it in the text?)

By: Tim

Tim — Mon, 26 May 2008 00:37:10 +0000

D’oh, and I should point to the Wide Finder summary, http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results and to the currently-in-progress round 2: http://www.tbray.org/ongoing/What/Technology/Concurrency/ - come and help explore!

By: Tim

Tim — Mon, 26 May 2008 00:36:03 +0000

For Wide Finder, it turned out (my interpretation) that coarse-grained parallelism was the winning formula. Thus, the winners were Perl and Python. Erlang placed very well, though, with all sorts of horrid workarounds for the file/string-processing weakness.

By: Yariv

Yariv — Sun, 25 May 2008 18:29:33 +0000

@Tim Didn’t Erlang perform quite well in the wide finder project, beating most languages? I actually think that whatever weaknesses Erlang may or may not have in string processing and file io (of which I have seen scant evidence btw) are insignificant for the majority of applications for which people consider Erlang, webapps included. These complaints are reminiscent of the “Ruby/Java/PHP is slow” arguments that many practitioners of the languages have happily ignored and went on to build their successful apps.

By: Tim

Tim — Fri, 23 May 2008 17:43:58 +0000

As of right now, Erlang has miserable performance at file I/O, string processing, and regular expressions; which makes it a non-starter for some apps. That aside, as a light user of Erlang and a mere student of Scala, Erlang feels way more elegant, if only because it’s smaller. But that’s a pretty nice platform Scala runs on.

By: pk11

pk11 — Fri, 23 May 2008 10:38:31 +0000

“In terms of “Rails is plenty fast enough”, that’s clearly wrong. Once you have a site that has high enough volume to care, you’re dead in the water with Rails (see Twitter.) The JVM has radically faster String handling, XML handling and just about everything else handling than does Erlang. Once you get into serving pages and doing the things that sites want to do, you want a runtime that’s fast, stable, and manageable. Ruby has none of these. Erlang has two of these. JVM has three of these.”

David,
with all respect it’s just not true. If the jvm made a web solution scalable (I doubt it), rails has a jvm targeted deployment option too (via JRuby).

As lots of people mentioned twitter’s issues at this point probably more architecture related than rails or ruby. And it’s clear that there are lots of high traffic rails apps out there. So architecture what matters not the lang/framework when it comes to scalability, even if scala is scalable by definition:D