Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Erlang matters

petrohi.me

Post reply on HN
Print view View original

21–30 of 75 posts

Re: Why Erlang matters

#21

Post by seiji »

rossjudson wrote: post #13

What's missing from your article is a demonstration or theory that outlines how transmission over CPU-interconnects of immutable messages as blocks of memory outperforms the cache coherence algorithms already in place. Immutable message transmission has no way to say "I already know about this message; don't send it again." Most of the good characteristics of Erlang that you describe are achievable in other languages…

It's not about raw performance. It's about getting shit done and keeping shit highly available. In large systems, shared data isn't mentally optimal to work with (see: every multithreaded program with shared data segfaulting for some unknown reason this very second).

We can always drop down to C or asm to make ultra-shared data structures with minimal overhead. We could always do that. But people end up wanting to spend their precious lives making a difference in the world and not checking the return value of malloc thirty times per day.

Re: Why Erlang matters

#22

Post by petrohi »

rossjudson wrote: post #13

What's missing from your article is a demonstration or theory that outlines how transmission over CPU-interconnects of immutable messages as blocks of memory outperforms the cache coherence algorithms already in place. Immutable message transmission has no way to say "I already know about this message; don't send it again." Most of the good characteristics of Erlang that you describe are achievable in other languages…

Immutable message passing is an abstraction. In a optimized virtual machine it may well be implemented by leveraging cache coherence. The sender process writes memory block. This places it into its local cache. Then the receiver process reads this memory block. This uses cache coherence to sniff the block directly from the sender's cache. This is awesome way to leverage parts of cache coherence protocol that play well with immutable memory blocks. It can also scale well if sniffing is not a broadcast. Cache coherence can quickly get ugly when a cache line is contested for writes--be this false sharing or a spin lock. My point I guess is that immutability and message passing promotes awesome parts of cache coherence and limits the need for the ugly parts.

Re: Why Erlang matters

#23

Post by derdesign »

seiji wrote: post #21
rossjudson wrote: post #13

What's missing from your article is a demonstration or theory that outlines how transmission over CPU-interconnects of immutable messages as blocks of memory outperforms the cache coherence algorithms already in place. Immutable message transmission has no way to say "I already know about this message; don't send it again." Most of the good characteristics of Erlang that you describe are achievable in other languages…

It's not about raw performance. It's about getting shit done and keeping shit highly available. In large systems, shared data isn't mentally optimal to work with (see: every multithreaded program with shared data segfaulting for some unknown reason this very second). We can always drop down to C or asm to make ultra-shared data structures with minimal overhead. We could always do that. But people end up wanting to sp…

> But people end up wanting to spend their precious lives making a difference in the world and not checking the return value of malloc thirty times per day

So true!

Re: Why Erlang matters

#24

Post by klibertp »

dschiptsov wrote: post #15

It is not just "matters". It is a deeply-researched and well-engineered explicitly concurrent programming language by smart and passionate people. It is a very rare example of first-class project, compared to the common nonsense, like Java or, god forbid, NodeJS.) If it is not that popular (which is rather good) it is not a language's fault. It is due to inability to acquire and maintain an appropriate mindset. btw,…

> language by smart and passionate people [...] compared to the common nonsense, like Java or, god forbid, NodeJS.

Are you implying that creators of Node and Java are stupid and lack passion? It seems like you are... And it's a) not relevant here at all; b) simply not true.

> It is due to inability to acquire and maintain an appropriate mindset.

It's debatable, but I tend to agree here.

Re: Why Erlang matters

#25

Post by SoftwareMaven »

rartichoke wrote: post #20

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.

Re: Why Erlang matters

#26

Post by petrohi »

rartichoke wrote: post #20

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?

It is interesting to look at virtual machines from the prospective of what they enforce. The JVM was a huge step forward when it allowed for safer memory management. Garbage collection is possible precisely because JVM enforces its memory model. You cannot use pointer arithmetic and arbitrary casts. This helps to ensure the level of ecosystem and make developers more productive. Erlang VM enforces immutability at its core. We can call it safer concurrency management. We can combine hundreds of libraries and still maintain this safety. I would argue that if something is not enforced in the VM, but rather a is "good guideline", the ecosystem descends to the lowest safety that is enforced.

Re: Why Erlang matters

#27

Post by bradkittenbrink »

rossjudson wrote: post #13

What's missing from your article is a demonstration or theory that outlines how transmission over CPU-interconnects of immutable messages as blocks of memory outperforms the cache coherence algorithms already in place. Immutable message transmission has no way to say "I already know about this message; don't send it again." Most of the good characteristics of Erlang that you describe are achievable in other languages…

I don't think he's arguing that message passing will generally outperform shared state with cache coherence. Particularly not for applications which are designed well. The argument (as I understand it) is that since the hardware is fundamentally doing message passing, (and since that will become even more of a problem as hardware continues to scale) it will be easier to design an application that performs well (but maybe not optimally) if you use the message passing paradigm, and easier for your application to perform poorly if you don't. You're right though that this isn't exclusive to erlang, but applies to all languages which eschew shared state.

Re: Why Erlang matters

#28

Post by shtylman »

dschiptsov wrote: post #15

It is not just "matters". It is a deeply-researched and well-engineered explicitly concurrent programming language by smart and passionate people. It is a very rare example of first-class project, compared to the common nonsense, like Java or, god forbid, NodeJS.) If it is not that popular (which is rather good) it is not a language's fault. It is due to inability to acquire and maintain an appropriate mindset. btw,…

This reminds me of a great quote.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses" -stroustrup

If you have to write about how your language matters, you have already missed the point. If it mattered, people would be using it.

Re: Why Erlang matters

#29

Post by codewright »

klibertp wrote: post #12
jfaucett wrote: post #6

People are always asking what is a good HN article, I'd say this is, great links to research that backs up many of the assertions. "Erlang matters today because it demonstrates how these semantics can be elegantly packaged in one language, execution model and virtual machine." I think yes, in a theoretical sense this is absolutely true. The question is why is it not a language in widespread practical use?

> The question is why is it not a language in widespread practical use? 1. It kind of is, I think RabbitMQ, CouchDB and Riak are doing ok, for example. 2. Both syntax and semantics are sufficiently different from "industry standard" to be a hurdle for majority of people... I'm being told. I don't understand this; the more different the language is the more interesting it seems to me and the more happy I am to learn i…

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.

CouchDB is more C++ than Erlang these days, bad example. It hasn't been mostly Erlang for a really long time. Erlang basically only does the clustering behavior, which is something Zookeeper et al. do already.

Riak is the only solid example out of those you listed, and its known for having poor raw performance, excellent availability, easy clustering, and awful usability.

Re: Why Erlang matters

#30

Post by gamache »

shtylman wrote: post #28
dschiptsov wrote: post #15

It is not just "matters". It is a deeply-researched and well-engineered explicitly concurrent programming language by smart and passionate people. It is a very rare example of first-class project, compared to the common nonsense, like Java or, god forbid, NodeJS.) If it is not that popular (which is rather good) it is not a language's fault. It is due to inability to acquire and maintain an appropriate mindset. btw,…

This reminds me of a great quote. "There are only two kinds of languages: the ones people complain about and the ones nobody uses" -stroustrup If you have to write about how your language matters, you have already missed the point. If it mattered, people would be using it.

You make phone calls, right?
Post reply on HN