8 ms·

Why Erlang matters

73 points by petrohi 14y ago

rustc 14y ago
On a related note, has anyone tried Elixir[1], which is a Ruby-like language that runs on the Erlang VM. If so, what project was that? how was your experience? [1] http://elixir-lang.org/ http://elixir-lang.org/
- rubyrescue 14y ago
  Inaka does a lot of Erlang. We really like Elixir and we're excited about it. It's still early but it gives you the runtime environment of Erlang with the syntax of Ruby. It has a few very active, passionate folks behind it which will cause it to continue to grow.
- ludicast 14y ago
  Elixir is awesome, it's like Ruby and Clojure having sex on an Erlang waterbed. However it still is maturing at a quick clip so I haven't done any production work in it. But since Jose Valim is probably my favorite developer alive, I have faith that Elixir will do for Erlang what Rails did for Ruby. I know it sounds like I'm comparing Rails (a framework) to Elixir (a language), but what I am comparing is a way of bridging-in Joe/Jane Developer.
commentzorro 14y ago
Erlang's been fine for showing us what's good and what's bad. But most of all, Erlang allows us to take the good parts and move them to a "friendlier" language when the time comes.
- hvs 14y ago
  What do you mean by "Erlang allows us to take the good parts and move them to a 'friendlier' language when the time comes"? Is there something I don't know about porting code from Erlang to other languages? (Not being snarky, genuinely curious.)
  - commentzorro 14y ago
    Keep the idea of lightweight processes, crash at will, message passing, etc. and move these techniques into other languages so we don't have the awkward syntax.
    - klibertp 14y ago
      Aaaargh :( Why, why syntax does have to matter? I thought it matters too, at first, but after sixth or so language I noticed the feeling of importance of syntax vanishing. Now I find good support in my editor much more important than syntax. (Edit: and "you don't need editor support if you have good syntax" doesn't seem true to me either)
      - juan_juarez 14y ago
        That's the point. A great many programmers learn one or two languages over the course of their lifetimes - look at all of the career Java and C# programmers.
    - petrohi 14y ago
      There is still great chunk of goodness in the Erlang VM, which is not bound to Erlang language and can be further reused. Much like JVM having things like Scala and JRuby.
    - davidw 14y ago
      If it were just the syntax, it'd be ok. The paradox of Erlang is that the sorts of environments it's used in and that initially supported its development are often fairly conservative, so the features and choices it started out with are not easy to get rid of. This means the language is saddled with some ugly warts. It's really good at what it does and is definitely worth a look, but I agree that sooner or later someone is going to come along and steal lots of the good parts and add them to a more modern language.
- ericmoritz 14y ago
  Libraries like Akka <http://akka.io/&#62 http://akka.io/> or the Celluloid stack <http://celluloid.io/&#62 http://celluloid.io/> are nice and bring the good parts of OTP to more "friendlier" languages but you're still missing some fundamentals the Erlang VM which bring predictable performance such as distributed garbage collection.
jfaucett 14y ago
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?
- davidw 14y ago
  Here's something I wrote about Erlang a while back, and why I don't think it'll ever go mainstream: http://journal.dedasys.com/2007/09/22/erlang http://journal.dedasys.com/2007/09/22/erlang
- petrohi 14y ago
  One of the huge hurdles for me personally was Erlang's heritage of Prolog syntax. I actually gave up once, and only cleared it second time around. Now I can see certain elegance and succinctness in the syntax.
  - seiji 14y ago
    That is the only proper way to learn Erlang. Your first week or two becomes so frustrating, you just leave for a month. Then it starts to click when you come back. Things are much easier now with line numbers in error messages though.
- klibertp 14y ago
  > 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 it[1], but I heard this argument enough times to accept it as (sad) reality. [1] And there is still so many of them to learn! Take a look at any one RosettaCode page (http://rosettacode.org/wiki/Y_combinator http://rosettacode.org/wiki/Y_combinator) if you don't believe me :)
rossjudson 14y ago
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. So what I'm asking is, by what concrete mechanism does immutable message passing outperform cache coherence?
- seiji 14y ago
  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.
  - derdesign 14y ago
    > 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!
- petrohi 14y ago
  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.
dschiptsov 14y ago
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, there is a nice lecture - http://www.youtube.com/results?search_query=Erlang%2BJoe%2BArmstrong http://www.youtube.com/results?search_query=Erlang%2BJoe%2BA...
- klibertp 14y ago
  > 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.
- shtylman 14y ago
  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.
  - gamache 14y ago
    You make phone calls, right?
  - derdesign 14y ago
    I bet you or a friend of yours chats on facebook[1] or Watsapp[2]... [1] http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf http://www.erlang-factory.com/upload/presentations/31/Eugene... [2] http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2...
- 14y ago
pla3rhat3r 14y ago
How come there are no Erlang articles start with, "this new technology is GREAT!" Oh yeah. Nevermind.
- xnld 14y ago
  But... Erlang isn't new technology.
rartichoke 14y ago
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?
- SoftwareMaven 14y ago
  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.
  - codewright 14y ago
    Going back to the OP, does Akka provide that depth or not? Akka is a LOT more than just Actor-based concurrency.
  - ericmoritz 14y ago
    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.
- petrohi 14y ago
  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.
rvirding 14y ago
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.
- petrohi 14y ago
  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.
  - rvirding 14y ago
    Yes, in retrospect using = was probably not a very good choice. I will admit some things in Erlang didn't receive much thought before being added while to some things we gave a lot thought; for example the language/systems basic properties and the semantics of concurrency, message passing and error handling.
- hassy 14y ago
  It's almost an acid test: the person complaining either has only a cursory familiarity with Erlang or is someone who prefers style over substance.
z3phyr 14y ago
How does Erlang compare to Haskell?
- petrohi 14y ago
  Two most important differences that come to mind are 1) Erlang is dynamically typed language vs statically typed Haskell; 2) Haskell is functional language with lazy evaluation where side effects are the primary concern, Erlang has eager evaluation.
  - z3phyr 14y ago
    But, they are equally deployable in similar circumstances. Right?
- Fixnum 14y ago
  Until recently, Haskell didn't have an equivalent to Erlang's built-in support for distributed computing, but the new Cloud Haskell library (http://www.haskell.org/haskellwiki/Cloud_Haskell http://www.haskell.org/haskellwiki/Cloud_Haskell) provides message-passing concurrency with a semantics very close to that of Erlang (but with more support for type-safety). I'm not sure Cloud Haskell is ready to dethrone Erlang (and the OTP framework, and tooling for debugging distributed processes, and special VM features, ...) for high-reliability distributed computing today, but Haskell and its libraries are evolving with absurd speed and the Cloud Haskell ecosystem could certainly be competitive with Erlang in the near future. Haskell can certainly be used to write high-performance network applications (e.g., Mighttpd, Warp), so it's surely only a matter of time ...
  - z3phyr 14y ago
    +1 to Cloud Haskell. But, they should change its name so that it sounds like a library and not another language dilect. :) Judging by its name, I thought that its a new haskell dilect ;)
- rvirding 14y ago
  I think one significant difference is in the actual implementation, or rather its intended use. The BEAM implementation is built to be used in products, it is very stable and bug-free and the OTP team are very cautious when making changes. Incompatible changes are introduced with early notices and warnings, usually 3 major releases before the change is made. My impression is that Haskell implementations are more used as research tools and there is less control of what goes in and how it is to be supported. In that sense it would be safer to build a product on top of Erlang. That is just my impression and I could be wrong.
millerm 14y ago
I was just put on a new Erang/OTP project at work and will be working on it for the next 9 months or so. I'm currently on a "ramp up sprint" to get to learn the language, tools and libraries, then we will move on to development. I'm really enjoying the language. OTP is quite elegant and just awesome. Sure, there are a few annoying things in the language that I have already read about on the Net/here but, I can look past those paper cuts. I've been really diggin' Lisp (Clojure, Racket, CL and Scheme) and other functional languages and have been enjoying the concepts so much. I've really become enamored with functional languages and really don't want to write another lick of Java. I'll keep the Objective-C because I have to, you know why. I am not dissin' (crap, I used that word) Java. But, it is nice to be given the opportunity to think differently (damn, another unoriginal phrase). Anyway, just giving a shout out to Erlang as I am finding the platform to be very interesting and that makes the day go by much better.
- petrohi 14y ago
  Great to see more adoption for Erlang/OTP. The return on investment is clearly there for us at connect.me. We're implementing our backend and API in Erlang/OTP. Can you share what type of application you will be working on?
dsiemon 14y ago
http://dl.acm.org/citation.cfm?id=2209269 http://dl.acm.org/citation.cfm?id=2209269
- petrohi 14y ago
  Great article. I've been inaccurate in the blog saying that cache coherence will or should go away. What I mean is that ugly (non-scalable) effects of cache coherence as implemented by today's vendors can be relieved by Erlang VM to some degree. In the comment above [1] I say "It can also scale well if sniffing is not a broadcast". Your article is to the point by addressing exactly this issue with tracking of sharers. [1] http://news.ycombinator.com/item?id=4780706 http://news.ycombinator.com/item?id=4780706
chaitanyapandit 14y ago
I had the syntax fear when I started learning Erlang, but I think the syntax is tailored to the language itself: - Recursion - Pattern Matching The problem occurs when you try to translate the Erlang syntax to the language of your choice, which isn't the right approach. C, and Java don't use pattern matching, so naturally their syntax is not designed for it. Maybe one should write a small program to demonstrate the key functionalities of Erlang, like write a TCP packet decoder etc, then try doing the same in your prefereed language and then see what makes sense.

73 points by petrohi 14y ago

rustc 14y ago

On a related note, has anyone tried Elixir[1], which is a Ruby-like language that runs on the Erlang VM. If so, what project was that? how was your experience? [1] http://elixir-lang.org/ http://elixir-lang.org/

rubyrescue 14y ago
Inaka does a lot of Erlang. We really like Elixir and we're excited about it. It's still early but it gives you the runtime environment of Erlang with the syntax of Ruby. It has a few very active, passionate folks behind it which will cause it to continue to grow.
ludicast 14y ago
Elixir is awesome, it's like Ruby and Clojure having sex on an Erlang waterbed. However it still is maturing at a quick clip so I haven't done any production work in it. But since Jose Valim is probably my favorite developer alive, I have faith that Elixir will do for Erlang what Rails did for Ruby. I know it sounds like I'm comparing Rails (a framework) to Elixir (a language), but what I am comparing is a way of bridging-in Joe/Jane Developer.

commentzorro 14y ago

Erlang's been fine for showing us what's good and what's bad. But most of all, Erlang allows us to take the good parts and move them to a "friendlier" language when the time comes.

hvs 14y ago
What do you mean by "Erlang allows us to take the good parts and move them to a 'friendlier' language when the time comes"? Is there something I don't know about porting code from Erlang to other languages? (Not being snarky, genuinely curious.)
- commentzorro 14y ago
  Keep the idea of lightweight processes, crash at will, message passing, etc. and move these techniques into other languages so we don't have the awkward syntax.
  - klibertp 14y ago
    Aaaargh :( Why, why syntax does have to matter? I thought it matters too, at first, but after sixth or so language I noticed the feeling of importance of syntax vanishing. Now I find good support in my editor much more important than syntax. (Edit: and "you don't need editor support if you have good syntax" doesn't seem true to me either)
    - juan_juarez 14y ago
      That's the point. A great many programmers learn one or two languages over the course of their lifetimes - look at all of the career Java and C# programmers.
  - petrohi 14y ago
    There is still great chunk of goodness in the Erlang VM, which is not bound to Erlang language and can be further reused. Much like JVM having things like Scala and JRuby.
  - davidw 14y ago
    If it were just the syntax, it'd be ok. The paradox of Erlang is that the sorts of environments it's used in and that initially supported its development are often fairly conservative, so the features and choices it started out with are not easy to get rid of. This means the language is saddled with some ugly warts. It's really good at what it does and is definitely worth a look, but I agree that sooner or later someone is going to come along and steal lots of the good parts and add them to a more modern language.
ericmoritz 14y ago
Libraries like Akka <http://akka.io/&#62 http://akka.io/> or the Celluloid stack <http://celluloid.io/&#62 http://celluloid.io/> are nice and bring the good parts of OTP to more "friendlier" languages but you're still missing some fundamentals the Erlang VM which bring predictable performance such as distributed garbage collection.

jfaucett 14y ago

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?

davidw 14y ago
Here's something I wrote about Erlang a while back, and why I don't think it'll ever go mainstream: http://journal.dedasys.com/2007/09/22/erlang http://journal.dedasys.com/2007/09/22/erlang
petrohi 14y ago
One of the huge hurdles for me personally was Erlang's heritage of Prolog syntax. I actually gave up once, and only cleared it second time around. Now I can see certain elegance and succinctness in the syntax.
- seiji 14y ago
  That is the only proper way to learn Erlang. Your first week or two becomes so frustrating, you just leave for a month. Then it starts to click when you come back. Things are much easier now with line numbers in error messages though.
klibertp 14y ago
> 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 it[1], but I heard this argument enough times to accept it as (sad) reality. [1] And there is still so many of them to learn! Take a look at any one RosettaCode page (http://rosettacode.org/wiki/Y_combinator http://rosettacode.org/wiki/Y_combinator) if you don't believe me :)

rossjudson 14y ago

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. So what I'm asking is, by what concrete mechanism does immutable message passing outperform cache coherence?

seiji 14y ago
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.
- derdesign 14y ago
  > 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!
petrohi 14y ago
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.

dschiptsov 14y ago

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, there is a nice lecture - http://www.youtube.com/results?search_query=Erlang%2BJoe%2BArmstrong http://www.youtube.com/results?search_query=Erlang%2BJoe%2BA...

klibertp 14y ago
> 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.
shtylman 14y ago
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.
- gamache 14y ago
  You make phone calls, right?
- derdesign 14y ago
  I bet you or a friend of yours chats on facebook[1] or Watsapp[2]... [1] http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf http://www.erlang-factory.com/upload/presentations/31/Eugene... [2] http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2...
14y ago

pla3rhat3r 14y ago

How come there are no Erlang articles start with, "this new technology is GREAT!" Oh yeah. Nevermind.

xnld 14y ago
But... Erlang isn't new technology.

rartichoke 14y ago

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?

SoftwareMaven 14y ago
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.
- codewright 14y ago
  Going back to the OP, does Akka provide that depth or not? Akka is a LOT more than just Actor-based concurrency.
- ericmoritz 14y ago
  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.
petrohi 14y ago
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.

rvirding 14y ago

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.

petrohi 14y ago
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.
- rvirding 14y ago
  Yes, in retrospect using = was probably not a very good choice. I will admit some things in Erlang didn't receive much thought before being added while to some things we gave a lot thought; for example the language/systems basic properties and the semantics of concurrency, message passing and error handling.
hassy 14y ago
It's almost an acid test: the person complaining either has only a cursory familiarity with Erlang or is someone who prefers style over substance.

z3phyr 14y ago

How does Erlang compare to Haskell?

petrohi 14y ago
Two most important differences that come to mind are 1) Erlang is dynamically typed language vs statically typed Haskell; 2) Haskell is functional language with lazy evaluation where side effects are the primary concern, Erlang has eager evaluation.
- z3phyr 14y ago
  But, they are equally deployable in similar circumstances. Right?
Fixnum 14y ago
Until recently, Haskell didn't have an equivalent to Erlang's built-in support for distributed computing, but the new Cloud Haskell library (http://www.haskell.org/haskellwiki/Cloud_Haskell http://www.haskell.org/haskellwiki/Cloud_Haskell) provides message-passing concurrency with a semantics very close to that of Erlang (but with more support for type-safety). I'm not sure Cloud Haskell is ready to dethrone Erlang (and the OTP framework, and tooling for debugging distributed processes, and special VM features, ...) for high-reliability distributed computing today, but Haskell and its libraries are evolving with absurd speed and the Cloud Haskell ecosystem could certainly be competitive with Erlang in the near future. Haskell can certainly be used to write high-performance network applications (e.g., Mighttpd, Warp), so it's surely only a matter of time ...
- z3phyr 14y ago
  +1 to Cloud Haskell. But, they should change its name so that it sounds like a library and not another language dilect. :) Judging by its name, I thought that its a new haskell dilect ;)
rvirding 14y ago
I think one significant difference is in the actual implementation, or rather its intended use. The BEAM implementation is built to be used in products, it is very stable and bug-free and the OTP team are very cautious when making changes. Incompatible changes are introduced with early notices and warnings, usually 3 major releases before the change is made. My impression is that Haskell implementations are more used as research tools and there is less control of what goes in and how it is to be supported. In that sense it would be safer to build a product on top of Erlang. That is just my impression and I could be wrong.

millerm 14y ago

I was just put on a new Erang/OTP project at work and will be working on it for the next 9 months or so. I'm currently on a "ramp up sprint" to get to learn the language, tools and libraries, then we will move on to development. I'm really enjoying the language. OTP is quite elegant and just awesome. Sure, there are a few annoying things in the language that I have already read about on the Net/here but, I can look past those paper cuts. I've been really diggin' Lisp (Clojure, Racket, CL and Scheme) and other functional languages and have been enjoying the concepts so much. I've really become enamored with functional languages and really don't want to write another lick of Java. I'll keep the Objective-C because I have to, you know why. I am not dissin' (crap, I used that word) Java. But, it is nice to be given the opportunity to think differently (damn, another unoriginal phrase). Anyway, just giving a shout out to Erlang as I am finding the platform to be very interesting and that makes the day go by much better.

petrohi 14y ago
Great to see more adoption for Erlang/OTP. The return on investment is clearly there for us at connect.me. We're implementing our backend and API in Erlang/OTP. Can you share what type of application you will be working on?

dsiemon 14y ago

http://dl.acm.org/citation.cfm?id=2209269 http://dl.acm.org/citation.cfm?id=2209269

petrohi 14y ago
Great article. I've been inaccurate in the blog saying that cache coherence will or should go away. What I mean is that ugly (non-scalable) effects of cache coherence as implemented by today's vendors can be relieved by Erlang VM to some degree. In the comment above [1] I say "It can also scale well if sniffing is not a broadcast". Your article is to the point by addressing exactly this issue with tracking of sharers. [1] http://news.ycombinator.com/item?id=4780706 http://news.ycombinator.com/item?id=4780706

chaitanyapandit 14y ago

I had the syntax fear when I started learning Erlang, but I think the syntax is tailored to the language itself: - Recursion - Pattern Matching The problem occurs when you try to translate the Erlang syntax to the language of your choice, which isn't the right approach. C, and Java don't use pattern matching, so naturally their syntax is not designed for it. Maybe one should write a small program to demonstrate the key functionalities of Erlang, like write a TCP packet decoder etc, then try doing the same in your prefereed language and then see what makes sense.