Hacker News Reader

Comment by KirinDave | Hacker News Reader

Why wouldn't Erlang be the next C++? Erlang's fast, compiled, but still flexible and dynamically, strongly typed. It has a type inference engine so you can look over your code, and it's fairly easy to do IDE integration with Erlang.

Erlang's distribution and multi-threading primitives are unbelievably well tested, and everyone could learn a thing or two from the OTP model.

I can't imagine why we'd ever consider Scala over Erlang.

View on HN

I think you missed the point of the comparison. One of the reasons C++ took off was that it was deliberately compatible with C (the dominant language at the time), so you didn't have to discard your existing C code and could ramp up from your existing skills. Likewise, today the dominant language is Java, and Scala compiles down to Java bytecode and allows you to continue to use your existing Java libraries. To my knowledge Erlang doesn't have these capabilities.

Good comment. We can't only look at the merits of the language itself, but also see wider context and circumstances in the software world. Thus my answer to the original question is: No, it isn't.

Following the same argument, Clojure and Jython qualify just as well as Scala does.

javascript using rhino as well

Erlang can integrate with anything out there, because it deliberately discourages binary inclusion. Instead you make remote "ports" that act like servers or vendors of results.

It's a very weird approach, but it's surprisingly effective.

Well can you give more info about these ports? Sounds like you want to do interprocess communication of some kind with the JVM?

1. How exactly would you setup the JVM? Will you need to wrap every Java class you want to use with some kind of communication mechanism? What about callbacks?

2. Can you subclass a Java class?

3. What is the overhead of calling Java methods from Erlang?

4. Has anyone demonstrated a bridge to a non-trivial Java library using a language not running on the JVM?

I feel interprocess communication might be ok for some apps but not all apps.

1. Yes, you write a communication mechanism. You can either use an existing one (like Thrift) or use the Erlang binary protocol. Erlang expects you to be acting like an erlang message-based process, like an actor.

2. No. Erlang is not an OO langauge, although its concurrency model is the actor concurrency model, which sometimes feels like Smalltalk's object model.

3. The cost of communication. Having implemented a few systems that do this, I've found it to be fairly small, even using a slow glue layer like ruby. See https://github.com/KirinDave/fuzed/tree ... Powerset uses almost exactly this codebase to manage query analysis on its frontend before dispatching to our results retrieval layer. Thus far, it's been one of the most flexible and robust parts of our architecture.

I felt this way too, and it is the case in some very specific scenarios. But the truth of the matter is that Java itself is often the wrong tool in these cases, so it's somewhat of a red herring to say that.

4. http://erlang.org/documentation/doc-5.6.1/lib/jinterface-1.4...

Scala's concurrency model is based on Erlang actually, although the Scala actors are not OS independent like Erlang, but the message passing mechanism and the concept of light weight processes independent of each other exchanging messages( no shared states ) is common to both. Scala runs on the JVM so its much easier to integrate it with huge java projects, and its performance is comparable with Java, and its being promoted in a big way by many of the big names in the industry. I see scala being widely accepted, whatever little I've used of it, I really love!

Scala's actor library emulates a subset of Erlang's message passing capabilities, but it's far from what Erlang has to offer. Scala's actors are not distributed, they don't have their own heaps (Erlang processes do, to minimize garbage collection sweeps for soft real-time performance), they aren't preemptively scheduled by the VM (the only preemptive scheduling is done by heavy native threads), and they don't have "shared nothing" sematics because Scala lets you send pointers mutable objects between processes. Furthermore, Scala doesn't have hot code swapping or Mnesia, both of which are essential for building scalable fault tolerant systems in Erlang.

Cause Erlang is a point solution that is totally painful outside of its target domain and has practically no library support.

You can call Java (or Python, Ruby, C etc) libraries from Erlang if you really have to. I'd bet Erlang's libraries would be quite sufficient for a wide range of apps, though.

Where did you run into pain trying to use Erlang outside of telcom apps? Just curious...

Also remember where java started (oak) - a much more point solution than what erlang has ever been.

Ya know, when I first this comment on library support I thought "Well kinda..." but after a couple of hours mulling it over not so much.

Erlang has a pretty good set of standard libraries, and whatever missing is relatively easy to build yourself, by comparison.

Granted, there are some very good OS Java libraries, but there's also an awful lot of drivel - one need only fire up their profiler to verify it.

I'd say you're being quite uncharitable to Erlang.

"I can't imagine why we'd ever consider Scala over Erlang."

Primarily because you're forced to use the JVM by some executive degree or similar. Likewise, if you're in a .NET shop you'd want to consider F#.

All that aside - I'm a huge Erlang fan.

opps. decree.

"Likewise, if you're in a .NET shop you'd want to consider F#."

Or Scala. It also compiles to the CLR.

Erlang's fast? Compared to what? Scala is usually about as fast as Java. Not trolling. Genuinely curious.

Erlang is fast if you are using multicore processors because it scales [almost] linerly by performance by core number.

As it's creator said, the main purpose of Erlang is not to be fast, it is to be reliable. Sure, you can throw a lot of processors at it, but at the moment we are still not there (I just bought myself a QuadCore, not a QuazillionCore), and other languages might be able to benefit from more cores, too (once they arrive).

You are totally right, scaling linearly is just a side effect of the shared nothing concurrency- and reliability-based programming model but it's quite a feature anyway!

Do you have data, or are you arguing that it should scale?

An important lesson I've learned is that just because you've written a parallel program, doesn't mean you've written a good one.

Reply on news.ycombinator.com