Live data from Hacker News

Why Erlang matters

petrohi.me

51–60 of 75 posts

Re: Why Erlang matters

#51

Would it be safe to say Scala with the Akka lib offers the same robustness and distributed scalability as Erlang? Erlang is using the actor model and so is Akka. I really want to learn one or the other as a goto functional language. I keep looking at sites like Netflix, Twitter and Foursquare. Those seem to be sites running on either Java or Scala. Why would they pick that instead of Erlang?

Pragmatism. It is easier to find JVM-knowledgeable people than to find BEAM-knowledgeable people. The actor model isn't the only aspect that gives Erlang its robustness. In fact, far more important is its supervisory model, which goes as deep as you want it and can supervise across system boundaries. I keep waiting for the language that learns these lessons from Erlang with a happier syntax, but I have yet to find it…

Akka does have supervisors. If you find Scala to be a happier syntax than Erlang (eye of the beholder), than Akka is worth looking into. It appears to be directly inspired by OTP and Erlang's "let it crash" ideology.

Re: Why Erlang matters

#52

Earlier quoted context omitted.

> RabbitMQ has some pretty serious limitations related to it being implemented on Erlang that keep it pretty strictly in the realm of being a message queue rather than a generic queue. Interesting, where can I learn more about this claim? What are the incompatible facets of a generic queue and Erlang? What is an example of these generic queues (or if it's only an ideal, what are its characteristics)?

Just don't use it for big, long-lived work queues and you'll be fine. If the queue gets badly backed up, you're probably fucked. Larger, longer-lived work queues are really more of a Hadoop thing, not an in-memory queue thing.

I got curious and googled a bit, here's what I found: http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-fo...

Where the first answer states that: "RabbitMQ presumes that consumers are mostly online, and any messages "in wait" (persistent or not) are held opaquely (i.e. no cursor). RabbitMQ pre-2.0 (2010) would fall over if your consumers were too slow, but now it's robust for online and batch consumers - but clearly large amounts of persistent messages sitting in the broker was not the main design case for AMQP in general."

(It's contrasted with Kafka, which is "designed for holding and distributing large volumes of messages")

Still, I see no reason why you say that it's Erlang that causes this?

Re: Why Erlang matters

#54
Every time I read something about the weird Erlang syntax I get so tired and try and tell myself not to get into the discussion, it's not worth the effort, some people will never just never learn, etc. But sometimes I can't help myself. So some of my thoughts on this:

- Syntax is the easiest part of learning a language. It's all written down and its just a RTFM. And yes, I have written a lot of C and lisp and prolog and erlang and ... and I never have problems with the syntax.

- If people worry so much about the syntax what happens when they get to the semantics?

- Seriously, why would you want to Erlang to have similar syntax to a language with different semantics? In my view that would be asking for trouble. I think one reason why I haven't had trouble with mixing languages is that both the syntax and the semantics are different. C looks like and behaves like C while Erlang looks like and behaves like Erlang.

- The erlang syntax is actually very simple, much simpler than the languages you would like it to look like.

I will now stop before I say something nasty.

I liked the blog.

Re: Why Erlang matters

#55

Earlier quoted context omitted.

Just don't use it for big, long-lived work queues and you'll be fine. If the queue gets badly backed up, you're probably fucked. Larger, longer-lived work queues are really more of a Hadoop thing, not an in-memory queue thing.

> If the queue gets badly backed up, you're probably fucked. Isn't that true of any queue ?

Not really, no. Depends on what how narrow you are about the definition of "queue".

Re: Why Erlang matters

#56

Every time I read something about the weird Erlang syntax I get so tired and try and tell myself not to get into the discussion, it's not worth the effort, some people will never just never learn, etc. But sometimes I can't help myself. So some of my thoughts on this: - Syntax is the easiest part of learning a language. It's all written down and its just a RTFM. And yes, I have written a lot of C and lisp and prolog…

When semantics are very different and syntax tries to pretend they aren't to create false familiarity this will lead to some very painful brain-splits later on. I can assert from my own experience with alternating the use of = between Erlang and C++.

Glad you liked the blog.

Re: Why Erlang matters

#57

Would it be safe to say Scala with the Akka lib offers the same robustness and distributed scalability as Erlang? Erlang is using the actor model and so is Akka. I really want to learn one or the other as a goto functional language. I keep looking at sites like Netflix, Twitter and Foursquare. Those seem to be sites running on either Java or Scala. Why would they pick that instead of Erlang?

I wonder how JVM garbage collection impacts real-time systems vs. Erlang.

Re: Why Erlang matters

#59
post #57

Would it be safe to say Scala with the Akka lib offers the same robustness and distributed scalability as Erlang? Erlang is using the actor model and so is Akka. I really want to learn one or the other as a goto functional language. I keep looking at sites like Netflix, Twitter and Foursquare. Those seem to be sites running on either Java or Scala. Why would they pick that instead of Erlang?

I wonder how JVM garbage collection impacts real-time systems vs. Erlang.

Usually badly. Erlang got one thing very right -- private heaps for each process. So when garbage collectors run they never have to stop all the processes and collect, and that is very important in types of system Erlang runs in.

I know Java has "pauseless" garbage collector but I think that is just marketing talk. Given how references to objects can be shared between threads I don't see a way for it to work.

Re: Why Erlang matters

#60
post #57

Would it be safe to say Scala with the Akka lib offers the same robustness and distributed scalability as Erlang? Erlang is using the actor model and so is Akka. I really want to learn one or the other as a goto functional language. I keep looking at sites like Netflix, Twitter and Foursquare. Those seem to be sites running on either Java or Scala. Why would they pick that instead of Erlang?

I wonder how JVM garbage collection impacts real-time systems vs. Erlang.

Erlang VM is much friendlier to garbage collection. For example immutability removes one of the biggest overheads of GC--tracking reference mutations. Process isolation allows to run garbage collection concurrently and without employing esoteric techniques. Many processes are short lived and never reach GC point, when they terminated memory is reclaimed wholesale.
Post reply on HN