9 ms·

What's all this fuss about Erlang?

155 points by DanielRibeiro 14y ago

Inufu 14y ago
This articles is now 5 years old - any Erlang programmers who can enlighten me about the current state of Erlang compared to the predictions in this article?
- kaeluka 14y ago
  erlang is a quite old language, as such, it doesn't move very fast. Erlang R15 brought some nice features, like (FINALLY!) line numbers in error reports, there will be a better (built-in) dict rather soon.
  - heretohelp 14y ago
    > (FINALLY!) line numbers in error reports Are...you serious?
    - gordonguthrie 14y ago
      Yup - because the language extensively uses tail call optimisation, inlining and other rewriting in the execution it used to be hard to reconstruct the original state of the code on a run time failure. It is less of a pain than it seems not to have line numbers in error reports - but it is still a pain.
      - jlouis 14y ago
        Actually, the inliner is not used unless you explicitly enable it (for the core). The runtime BEAM backend may decide to inline as well, but that is another part entirely. But yeah, it is not much of a problem having no line numbers when your functions tend to be of a 4-5 line size.
- timClicks 14y ago
  The library support and community have both deepened. Riak has been built, Facebook Chat has proven its scalability, open source projects have mostly moved to GitHub, #erlang and #erlounge IRC channels on freenode.net are very friendly and well populated. In the web space, there are now several options if a small team wants to build something to scale to 100k+ concurrent connections on a single server. Hackers in #erlounge are regularly benchmarking systems with 500k+ users. It's crazy talk.
  - dcosson 14y ago
    Actually, I was talking to a few facebook guys a couple weeks ago and they rewrote the chat app in c++ a few years ago. The primary motivator was that nobody knows Erlang, while most of their engineers already know c++. I found that really surprising coming a from a company that prides itself as having the smartest people around, and, as awesome as Erlang seems, after hearing that I might think twice about using it for a project if there's a possibility that I'd be hiring other engineers to work on it with me.
    - indiecore 14y ago
      I think that certain realities take over when you get as big as facebook is. It's not the little start-up that could anymore, it's now the 800 lb Gorilla that churns though staff. While you might be able to have the smartest people around at your beck and call you'll want to keep the system accessible to as many of them as possible so your options are always open and there are always going to be more C++ programmers around than Erlang programmers.
      - zaphar 14y ago
        This is weird though because erlang is way easier to wrap your head around than C++. A C++ programmer should be able learn erlang in a a couple weeks max. If they can't do that then I probably don't want them doing C++ code for me either. Now if they rewrote it in java, because java programmers are easier to find, that might be less weird but C++?
    - 14y ago
chubot 14y ago
I feel like Erlang had a lot of publicity a few years ago... but it doesn't seem like it has experienced increased popularity. Does anyone experienced with Erlang have some insights on why that is? Or am I wrong and is it being used in more and more important things? I think the model makes sense and maybe forces will yet conspire to make it more popular. But I've heard that it feels "old", i.e. lacking in conveniences you would expect in a modern programming language. And it seems like it should interact better with other programming languages -- i.e. you shouldn't have to assume that every node is written in Erlang. There's no migration path to Erlang in that case.
- jlouis 14y ago
  Erlang has experienced increased popularity. Yet, it has not experienced the avalanche popularity increase you see with e.g., Ruby or Javascript. I think Erlang is lucky that this has not happened since the community would not be able to keep its current excellent condition if that happened. Erlangs forte is in a very specific kind of system. If your problem is * Stateful * Concurrent * State has to "act on its own" * Distributed over multiple machines Then Erlang is a nice tool for the job. The language is not particularly old. Note you are not allowed to call a language old if the "newer" language is based on C or its semantics :)
  - minikomi 14y ago
    Have you built something cool which fits the bill? I'd love to hear about any successes!
    - asabil 14y ago
      There are plenty of successes out there: Riak, Ejabberd, Whatsapp messenger, Klarna, Demonware, Soundrop, Wooga... Just to name a few
      - johndonsp 14y ago
        I wonder if those apps run n-times faster on n-cores. I think probably not, due to inherent limitations in the parallelism available in them, but perhaps I should do a study to verify that. Erlang claiming n-times faster on n-cores is snake oil. First of all, not all problems have n-times parallelism in them!
azov 14y ago
From what I've heard and seen Erlang is great, but this article doesnt tell me anything about why it is great. Message passing? Come on! You can do message passing in C++, or Python, or any other mainstreem language. Its a matter of convention and system architecture. Its easier to hire developers for a mainstream language, and its probably easier to teach them these conventions then a whole new language + development environment. So, whats all the fuss about Erlang? PS. I dont mean to be critical about Erlang, I just dont think the article addresses the question in its title.
- Torn 14y ago
  I think people are upvoting on title alone.
- asabil 14y ago
  Well, it all depends on what you mean by message passing. If you mean call a method or a function passing it a value type, then yes you can do message passing in any language. If on the other hand you mean passing data between completely isolated active entities (processes) that get scheduled for execution independently based on available CPU cores, I/O operations, receiver mailbox size... Then you need an multitasking operating system, which is in fact what the Erlang VM is.
  - yummyfajitas 14y ago
    If on the other hand you mean passing data between completely isolated active entities (processes) that get scheduled for execution independently based on available CPU cores, I/O operations, receiver mailbox size... Or you can use Python multiprocessing on Linux, or Scala actors, or Haskell actors, or Clojure agents...
- gingerlime 14y ago
  I was wondering the same thing about using the model itself rather than a language. I asked this on StackOverflow and received some interesting feedback http://stackoverflow.com/questions/10323393/is-the-actor-model-limited-to-specific-languages http://stackoverflow.com/questions/10323393/is-the-actor-mod... The short version: apparently you can do this in other languages, but erlang (and possibly other languages) have this concurrency baked-in much better. p.s. also worth mentioning RabbitMQ on the list of famous erlang projects
mstump 14y ago
Is the Erlang ecosystem and supporting libraries strong enough to support committing/betting resources on using it for production? We're using Clojure now for our back-end processes because it's a language I can live with, and I get the safety of java interop.
- cageface 14y ago
  I saw a great talk by Jonas Bonér (guy behind Akka) at the S.F. Scala group a few years ago. He said he fell in love with Erlang but eventually gave up trying to persuade people to deploy it and that Akka was basically an attempt to bring the core Erlang principles over to the JVM. Personally I think people are too paranoid and should worry less about deploying a new VM but a lot of commercial IT shops are very conservative.
  - mahmud 14y ago
    He must have taken a detour throught Groovy because he wrote this just before Akka. http://gpars.codehaus.org/ http://gpars.codehaus.org/
- nirvana 14y ago
  Erlang has been in production, in mission critical situations, for longer than the world wide web itself. In terms of web platforms and databases, etc, the answer is again yes. For one sampling of one companies clients check out: http://basho.com/company/production-users/ http://basho.com/company/production-users/
- pka 14y ago
  Facebook chat is based on Erlang, at least 1-2 years ago when they made a presentation [1] about it at CUFP. [1] http://cufp.org/videos/functional-programming-facebook http://cufp.org/videos/functional-programming-facebook
- jlouis 14y ago
  Clojure is a toddler compared to Erlang w.r.t age. Clojure started around 2007 or so, admittedly on a Lisp basis with Rich Hickey as the designer (which is to its benefit!) Erlang has been in production since the mid 90'es in real systems. For what it solves, it solves it really well.
johndonsp 14y ago
Message passing is fantastic... when you can decompose your problem into lots of small, independent jobs, like a web server. However not many algorithms are like that. If you can't decompose your problem into small independent jobs then you will be left with some kind of shared job. For example, an airline seat booking system, where at some point you need to modify a shared set of seat states (no, you can't divide the seat state up, because then you can't take massive bookings if needed). Another example is sorting algorithms. If you divide and conquer, at some point you need to combine results. In Erlang, the normal way to do this is to have a single actor handled that shared job. That then becomes a huge bottleneck, and with more cores it gets to be more and more of a bottleneck. This is Amdahl's law. This is where Erlang breaks. In a language with shared state (that includes Haskell or ML with mutable references) I can use very fine grained locks, or perhaps transactional memory, over this shared part of the problem, and continue to scale beyond what Erlang was capable of. Probably not near n-times for n cores, but much closer than what Erlang would allow. Erlang's message passing creates bottlenecks! And then there's no way out. In shared state you can be nice and message passing, but then also have the power to use very fine grained locks or TM to break down those bottlenecks.
- DennisP 14y ago
  Sorting algorithms? Let's take mergesort, for example. In Erlang a process could divide its portion of the collection in half, hand each half to another process, wait for two sorted collections to come back, merge them and pass the results up the chain. Conceptually simple and good multicore use. The only time you're down to a single core is on the final merge, between two sorted halves of the whole collection. The merge is an inherently sequential process. Are you claiming that somehow you can merge two sorted arrays in parallel using fine-grained locks? How exactly?
  - johndonsp 14y ago
    No, the parallelism in that algorithm is fundamentally limited. That bottleneck is not going away, and was an example of where neither Erlang nor any other model of parallelism will help you. Do you have any good ideas about how I can solve the seat booking example using Erlang's model of parallelism? There is a block of seats. I want to be able to handle seat bookings in parallel. The seats that people might want to book could be in large groups - as large as all of the seats.
nirvana 14y ago
Erlang is a secret weapon. Erlang is never going to be the really "hot" or "cool" language because it has an unusual syntax and that syntax is enough to keep it from becoming fashionable. But this is a feature, actually. Because the really good engineers, they will invest the week or two (really!) to learn the language and once they do that they come to love it, and as a result, erlang has some of the best engineers working with it. What Erlang does, you simply can't do with a library or bolt on solution, or anything involving ruby, python or the JVM. And what erlang does-- concurrency done right-- is so valuable these days that anyone solving real problems has run into it. Erlang as been quietly winning in production and building out just about every library you could want. And because the language is so elegantly designed, for many projects its really accessible- you can dive into the code and comprehend it. (I get lost in the riak sources, because it does so much it overflows my stack, but everything else is easy.) Erlang is not only a secret weapon, but it is a productivity multiplier.
- ryanong 14y ago
  Jose Valim made an awesome language for the erlang vm called elixir http://elixir-lang.org/ http://elixir-lang.org/ I have been playing around with it and it simplifies a lot of the things that bother me about erlang. It breaks some functional conventions for code readability such as rewriting the same variable
  - sandGorgon 14y ago
    Thank you for this! Ruby syntax on top of the erlang VM - I wonder why this is not more popular.
    - rubyrescue 14y ago
      It's really, really new. We've been playing w/it a lot @ Inaka (and we do about 30% Erlang consulting projects). It will catch on, i'm sure.
      - sandGorgon 14y ago
EvanMiller 14y ago
Some neat Erlang projects: * ErlGuten, PDF generator: https://github.com/hwatkins/erlguten https://github.com/hwatkins/erlguten * OpenCL binding: https://github.com/tonyrog/cl https://github.com/tonyrog/cl * gen_smtp, SMTP library: https://github.com/Vagabond/gen_smtp https://github.com/Vagabond/gen_smtp * erl_img, image manipulator: https://github.com/evanmiller/erl_img https://github.com/evanmiller/erl_img * ErlyDTL, Django template compiler: https://github.com/evanmiller/erlydtl https://github.com/evanmiller/erlydtl * BossDB, evented database abstraction layer: https://github.com/evanmiller/boss_db https://github.com/evanmiller/boss_db * Jerome, RTF/HTML/BBCode/Textile processor: https://github.com/evanmiller/jerome https://github.com/evanmiller/jerome * Cowboy, web server with WebSockets: https://github.com/extend/cowboy https://github.com/extend/cowboy * Chicago Boss, full-featured web framework: http://www.chicagoboss.org/ http://www.chicagoboss.org/ Those are just my favorites, there are many more listed here: http://erlagner.org/ http://erlagner.org/ Things I would use Erlang for: * Network programming * Web programming * Sending a lot of emails Things I would not use Erlang for: * Numerical programming * Video decoding * Desktop or mobile applications Basically Erlang is really good at receiving, parsing, and sending data, and bad at anything remotely processor-intensive (or graphical). I think this situation might change with Erlang's OpenCL binding (second link above), which lets the programmer skip the overhead of Erlang's run-time and go straight to the CPU or GPU for numerical tasks.
jdeseno 14y ago
For the people who don't like Erlang's syntax, there are alternatives. I've used Elixer (http://elixir-lang.org/ http://elixir-lang.org/) with some success. It has a Rubyish syntax and gets rid of a lot of the warts newcomers seem to dislike. The language is actually the easiest part, the biggest hurdle seems to be organizing a complicated application to take advantage of OTP. Erlang is really about OTP; not the language.
pkulak 14y ago
From what I can tell, Go seems to have about the same concurrency primitives as Erlang, but is much more approachable. Could someone start a new project in Go that would have required Erland a couple years ago?
- mseepgood 14y ago
  They are both based on CSP, but Go channels are a little bit different: http://www.youtube.com/watch?v=f6kdp27TYZs&t=4m57s http://www.youtube.com/watch?v=f6kdp27TYZs&t=4m57s
  - mononcqc 14y ago
    There is not much that is CSP about Erlang.
  - bascule 14y ago
    The main difference between CSP in Go and the actor model in Erlang is that actor mailboxes are many-to-one whereas CSP channels are many-to-many. If you were to model CSP using actors, channels would be actors.
    - Mr_T_ 14y ago
      And you can send a channel over a channel or store it in a data structure or pass it to a function.
skue 14y ago
Most of the comments here talk about additional advantages of Erlang without commenting on the point of the original article -- which is that servers would move towards multi-core systems where Erlang excels. Of course, this hasn't really happened, because we've moved to cloud services instead, which typically offer a single virtual CPU. I'm not arguing against Erlang. It's a great language and folks could certainly choose to run it on their own multi-core system or scale across multiple virtual servers. But startups often pick the technology they can get running with minimal investment, then scale from there: a VPS or two with a single CPU and constrained RAM. So although Erlang might be a great long term investment, it requires a lot of RAM up front and hyped features like multi-core support don't matter as much to young startups choosing technology at the early stages. It would be great to see more discussion about how well Erlang scales across multiple VPS systems -- and not just theoretically, but how many systems you can practically scale across, how it impacts performance, RAM usage, etc. Plus how this would compare to just using an independent messaging queue/bus to accomplish the same thing in another language.
- vonkow 14y ago
  I'm by no means an expert, but I have written production Erlang applications (the instapaper-like functionality on bostonglobe.com). We initially had it running as a network of 5 VPS systems (three web-facing servers with copies of the entire db in memory and two machines keeping disk copies), which performed more than adequately. Even with the db in memory, RAM usage really wasn't an issue for us. The runtime was initially designed to run embedded in telephone switches so it's pretty lightweight, all things considered. I've heard talk that things start to get a little hairy once you scale to around 100 nodes, due to the sheer amount of messages getting passed around (there are ways around this, like creating hidden nodes that communicate between clusters). Performance across multiple VPS systems is really going to vary dramatically between different applications and VPS setups. An app that has to make lots of requests to other nodes, which are located across the globe, is going to suffer a lot more than one that has relatively little internode communication between VPSs in the same server rack, but that's just common sense. I'd be really interested to know what companies like Basho (creators of Riak) and Facebook have experienced with large setups, as horizontal scaling is one of the language's selling points. More so than scaling across multiple cores and machines, I find that one of its strongest points is it's scheduler. If one request to a server is particularly processor intensive (or hangs), it's not going to affect other requests, which is an awesome feature to have even with a single core. Erlang's definitely not for everything, but once yo get the hang of it, it's really easy to prototype in, scales well, and is generally lightweight enough to run on a cheap cloud instance (or embedded on a Raspberry Pi).
knodi 14y ago
I really like Erlang and have been using it on and off for about a year. Recently I starting playing around with Golang and much to my surprise goroutines are a very good homage to Erlangs concurrently model.
lucisferre 14y ago
One of the things the author failed to mention, when he asks if Erlang is difficult, is it's verbosity for anything non-trivial. Just try building something using WebMachine for example. You will end up repeating the same tedious boiler plate code for each and every resource. Very, very, fortunately the Elixir project seems to be making some headway and may just bring some decent language usability to Erlang. Erlang, is great architecturally, but in a lot of ways it's a toy language. It is going to need to evolve a bit to become palatable to the mass web development market.
- tikhonj 14y ago
  Hey, being verbose has never impeded languages like Java and Python.
  - lucisferre 14y ago
    I don't know much Python but as far as I k now it is capable of extension via mixins and Java can do similarly through AoP and inheritance. Erlang can do neither of these out of the box. What I'm really referring to is how dry a set of modules is capable of being, avoiding repeated boiler plate code being employed each and every time.
    - asabil 14y ago
      In the Erlang world, you do that by creating behaviors.
cantankerous 14y ago
Doesn't the N-times speedup on N cores really require you to write perfect Erlang? I feel like that's a really optimistic prediction. Even the authors said they needed to give their original programs some tweaking, and they're Erlang pros. At this point, I remain skeptical of this claim.
- MetaCosm 14y ago
  Not as much as you would expect. The natural way you build systems in Erlang is across erlang-processes (micro processes). Even if you are building an application running on a single core, you use erlang-processes extensively. This means for a little TCP-IP server, you use one erlang-process per incoming connection on one core or 32 -- the only difference is how they are schedule, when you are on 32 cores the Erlang VM starts up more threads and then schedules the erlang-processes across the VM threads and those threads are scheduled across physical processors. The trick is -- when you build software in Erlang -- you start up new processes for the true concurrency (in a web application, the true concurrency is number of connections, so they get there own processes). This means that Erlang applications routinely have hundreds of thousands of processes -- which makes it easy to schedule across a mere 32 or 64 or 128 physical cores.
nickknw 14y ago
I'm blogging my way through Seven Languages In Seven Weeks. Reading this makes me really look forward to the Erlang chapter. Only the last bit of Prolog and Scala stands between Erlang and I now!
tomerbd 14y ago
About this section in his article " The world IS concurrent. It IS parallel. Things happen all over the place at the same time. I could not drive my car on the highway if I did not intuitively understand the notion of concurrency; pure message-passing concurrency is what we do all the time." i dont get it i dont think this is correct when i drive my car into a gas station i wait for the person before me to finish filling his gas tank as he is using (locking) the gas stand anyone thinks what im saying is incorrect?
CalEl 14y ago
I had to use Erlang for a uni project and didn't mind it but it's not my favourite language.
mistercow 14y ago
Now that we're seeing lots of cores on the machines of ordinary people, what would be really nice is if languages like Erlang, which are by design better for parallel computing, could efficiently target JavaScript while taking advantage of web workers. As more and more application development becomes web based, it's really a shame to see almost-always-idle core after almost-always-idle core added to user end CPUs.

155 points by DanielRibeiro 14y ago

Inufu 14y ago

This articles is now 5 years old - any Erlang programmers who can enlighten me about the current state of Erlang compared to the predictions in this article?

kaeluka 14y ago
erlang is a quite old language, as such, it doesn't move very fast. Erlang R15 brought some nice features, like (FINALLY!) line numbers in error reports, there will be a better (built-in) dict rather soon.
- heretohelp 14y ago
  > (FINALLY!) line numbers in error reports Are...you serious?
  - gordonguthrie 14y ago
    Yup - because the language extensively uses tail call optimisation, inlining and other rewriting in the execution it used to be hard to reconstruct the original state of the code on a run time failure. It is less of a pain than it seems not to have line numbers in error reports - but it is still a pain.
    - jlouis 14y ago
      Actually, the inliner is not used unless you explicitly enable it (for the core). The runtime BEAM backend may decide to inline as well, but that is another part entirely. But yeah, it is not much of a problem having no line numbers when your functions tend to be of a 4-5 line size.
timClicks 14y ago
The library support and community have both deepened. Riak has been built, Facebook Chat has proven its scalability, open source projects have mostly moved to GitHub, #erlang and #erlounge IRC channels on freenode.net are very friendly and well populated. In the web space, there are now several options if a small team wants to build something to scale to 100k+ concurrent connections on a single server. Hackers in #erlounge are regularly benchmarking systems with 500k+ users. It's crazy talk.
- dcosson 14y ago
  Actually, I was talking to a few facebook guys a couple weeks ago and they rewrote the chat app in c++ a few years ago. The primary motivator was that nobody knows Erlang, while most of their engineers already know c++. I found that really surprising coming a from a company that prides itself as having the smartest people around, and, as awesome as Erlang seems, after hearing that I might think twice about using it for a project if there's a possibility that I'd be hiring other engineers to work on it with me.
  - indiecore 14y ago
    I think that certain realities take over when you get as big as facebook is. It's not the little start-up that could anymore, it's now the 800 lb Gorilla that churns though staff. While you might be able to have the smartest people around at your beck and call you'll want to keep the system accessible to as many of them as possible so your options are always open and there are always going to be more C++ programmers around than Erlang programmers.
    - zaphar 14y ago
      This is weird though because erlang is way easier to wrap your head around than C++. A C++ programmer should be able learn erlang in a a couple weeks max. If they can't do that then I probably don't want them doing C++ code for me either. Now if they rewrote it in java, because java programmers are easier to find, that might be less weird but C++?
  - 14y ago

chubot 14y ago

I feel like Erlang had a lot of publicity a few years ago... but it doesn't seem like it has experienced increased popularity. Does anyone experienced with Erlang have some insights on why that is? Or am I wrong and is it being used in more and more important things? I think the model makes sense and maybe forces will yet conspire to make it more popular. But I've heard that it feels "old", i.e. lacking in conveniences you would expect in a modern programming language. And it seems like it should interact better with other programming languages -- i.e. you shouldn't have to assume that every node is written in Erlang. There's no migration path to Erlang in that case.

jlouis 14y ago
Erlang has experienced increased popularity. Yet, it has not experienced the avalanche popularity increase you see with e.g., Ruby or Javascript. I think Erlang is lucky that this has not happened since the community would not be able to keep its current excellent condition if that happened. Erlangs forte is in a very specific kind of system. If your problem is * Stateful * Concurrent * State has to "act on its own" * Distributed over multiple machines Then Erlang is a nice tool for the job. The language is not particularly old. Note you are not allowed to call a language old if the "newer" language is based on C or its semantics :)
- minikomi 14y ago
  Have you built something cool which fits the bill? I'd love to hear about any successes!
  - asabil 14y ago
    There are plenty of successes out there: Riak, Ejabberd, Whatsapp messenger, Klarna, Demonware, Soundrop, Wooga... Just to name a few
    - johndonsp 14y ago
      I wonder if those apps run n-times faster on n-cores. I think probably not, due to inherent limitations in the parallelism available in them, but perhaps I should do a study to verify that. Erlang claiming n-times faster on n-cores is snake oil. First of all, not all problems have n-times parallelism in them!

azov 14y ago

From what I've heard and seen Erlang is great, but this article doesnt tell me anything about why it is great. Message passing? Come on! You can do message passing in C++, or Python, or any other mainstreem language. Its a matter of convention and system architecture. Its easier to hire developers for a mainstream language, and its probably easier to teach them these conventions then a whole new language + development environment. So, whats all the fuss about Erlang? PS. I dont mean to be critical about Erlang, I just dont think the article addresses the question in its title.

Torn 14y ago
I think people are upvoting on title alone.
asabil 14y ago
Well, it all depends on what you mean by message passing. If you mean call a method or a function passing it a value type, then yes you can do message passing in any language. If on the other hand you mean passing data between completely isolated active entities (processes) that get scheduled for execution independently based on available CPU cores, I/O operations, receiver mailbox size... Then you need an multitasking operating system, which is in fact what the Erlang VM is.
- yummyfajitas 14y ago
  If on the other hand you mean passing data between completely isolated active entities (processes) that get scheduled for execution independently based on available CPU cores, I/O operations, receiver mailbox size... Or you can use Python multiprocessing on Linux, or Scala actors, or Haskell actors, or Clojure agents...
gingerlime 14y ago
I was wondering the same thing about using the model itself rather than a language. I asked this on StackOverflow and received some interesting feedback http://stackoverflow.com/questions/10323393/is-the-actor-model-limited-to-specific-languages http://stackoverflow.com/questions/10323393/is-the-actor-mod... The short version: apparently you can do this in other languages, but erlang (and possibly other languages) have this concurrency baked-in much better. p.s. also worth mentioning RabbitMQ on the list of famous erlang projects

mstump 14y ago

Is the Erlang ecosystem and supporting libraries strong enough to support committing/betting resources on using it for production? We're using Clojure now for our back-end processes because it's a language I can live with, and I get the safety of java interop.

cageface 14y ago
I saw a great talk by Jonas Bonér (guy behind Akka) at the S.F. Scala group a few years ago. He said he fell in love with Erlang but eventually gave up trying to persuade people to deploy it and that Akka was basically an attempt to bring the core Erlang principles over to the JVM. Personally I think people are too paranoid and should worry less about deploying a new VM but a lot of commercial IT shops are very conservative.
- mahmud 14y ago
  He must have taken a detour throught Groovy because he wrote this just before Akka. http://gpars.codehaus.org/ http://gpars.codehaus.org/
nirvana 14y ago
Erlang has been in production, in mission critical situations, for longer than the world wide web itself. In terms of web platforms and databases, etc, the answer is again yes. For one sampling of one companies clients check out: http://basho.com/company/production-users/ http://basho.com/company/production-users/
pka 14y ago
Facebook chat is based on Erlang, at least 1-2 years ago when they made a presentation [1] about it at CUFP. [1] http://cufp.org/videos/functional-programming-facebook http://cufp.org/videos/functional-programming-facebook
jlouis 14y ago
Clojure is a toddler compared to Erlang w.r.t age. Clojure started around 2007 or so, admittedly on a Lisp basis with Rich Hickey as the designer (which is to its benefit!) Erlang has been in production since the mid 90'es in real systems. For what it solves, it solves it really well.

johndonsp 14y ago

Message passing is fantastic... when you can decompose your problem into lots of small, independent jobs, like a web server. However not many algorithms are like that. If you can't decompose your problem into small independent jobs then you will be left with some kind of shared job. For example, an airline seat booking system, where at some point you need to modify a shared set of seat states (no, you can't divide the seat state up, because then you can't take massive bookings if needed). Another example is sorting algorithms. If you divide and conquer, at some point you need to combine results. In Erlang, the normal way to do this is to have a single actor handled that shared job. That then becomes a huge bottleneck, and with more cores it gets to be more and more of a bottleneck. This is Amdahl's law. This is where Erlang breaks. In a language with shared state (that includes Haskell or ML with mutable references) I can use very fine grained locks, or perhaps transactional memory, over this shared part of the problem, and continue to scale beyond what Erlang was capable of. Probably not near n-times for n cores, but much closer than what Erlang would allow. Erlang's message passing creates bottlenecks! And then there's no way out. In shared state you can be nice and message passing, but then also have the power to use very fine grained locks or TM to break down those bottlenecks.

DennisP 14y ago
Sorting algorithms? Let's take mergesort, for example. In Erlang a process could divide its portion of the collection in half, hand each half to another process, wait for two sorted collections to come back, merge them and pass the results up the chain. Conceptually simple and good multicore use. The only time you're down to a single core is on the final merge, between two sorted halves of the whole collection. The merge is an inherently sequential process. Are you claiming that somehow you can merge two sorted arrays in parallel using fine-grained locks? How exactly?
- johndonsp 14y ago
  No, the parallelism in that algorithm is fundamentally limited. That bottleneck is not going away, and was an example of where neither Erlang nor any other model of parallelism will help you. Do you have any good ideas about how I can solve the seat booking example using Erlang's model of parallelism? There is a block of seats. I want to be able to handle seat bookings in parallel. The seats that people might want to book could be in large groups - as large as all of the seats.

nirvana 14y ago

Erlang is a secret weapon. Erlang is never going to be the really "hot" or "cool" language because it has an unusual syntax and that syntax is enough to keep it from becoming fashionable. But this is a feature, actually. Because the really good engineers, they will invest the week or two (really!) to learn the language and once they do that they come to love it, and as a result, erlang has some of the best engineers working with it. What Erlang does, you simply can't do with a library or bolt on solution, or anything involving ruby, python or the JVM. And what erlang does-- concurrency done right-- is so valuable these days that anyone solving real problems has run into it. Erlang as been quietly winning in production and building out just about every library you could want. And because the language is so elegantly designed, for many projects its really accessible- you can dive into the code and comprehend it. (I get lost in the riak sources, because it does so much it overflows my stack, but everything else is easy.) Erlang is not only a secret weapon, but it is a productivity multiplier.

ryanong 14y ago
Jose Valim made an awesome language for the erlang vm called elixir http://elixir-lang.org/ http://elixir-lang.org/ I have been playing around with it and it simplifies a lot of the things that bother me about erlang. It breaks some functional conventions for code readability such as rewriting the same variable
- sandGorgon 14y ago
  Thank you for this! Ruby syntax on top of the erlang VM - I wonder why this is not more popular.
  - rubyrescue 14y ago
    It's really, really new. We've been playing w/it a lot @ Inaka (and we do about 30% Erlang consulting projects). It will catch on, i'm sure.
    - sandGorgon 14y ago

EvanMiller 14y ago

Some neat Erlang projects: * ErlGuten, PDF generator: https://github.com/hwatkins/erlguten https://github.com/hwatkins/erlguten * OpenCL binding: https://github.com/tonyrog/cl https://github.com/tonyrog/cl * gen_smtp, SMTP library: https://github.com/Vagabond/gen_smtp https://github.com/Vagabond/gen_smtp * erl_img, image manipulator: https://github.com/evanmiller/erl_img https://github.com/evanmiller/erl_img * ErlyDTL, Django template compiler: https://github.com/evanmiller/erlydtl https://github.com/evanmiller/erlydtl * BossDB, evented database abstraction layer: https://github.com/evanmiller/boss_db https://github.com/evanmiller/boss_db * Jerome, RTF/HTML/BBCode/Textile processor: https://github.com/evanmiller/jerome https://github.com/evanmiller/jerome * Cowboy, web server with WebSockets: https://github.com/extend/cowboy https://github.com/extend/cowboy * Chicago Boss, full-featured web framework: http://www.chicagoboss.org/ http://www.chicagoboss.org/ Those are just my favorites, there are many more listed here: http://erlagner.org/ http://erlagner.org/ Things I would use Erlang for: * Network programming * Web programming * Sending a lot of emails Things I would not use Erlang for: * Numerical programming * Video decoding * Desktop or mobile applications Basically Erlang is really good at receiving, parsing, and sending data, and bad at anything remotely processor-intensive (or graphical). I think this situation might change with Erlang's OpenCL binding (second link above), which lets the programmer skip the overhead of Erlang's run-time and go straight to the CPU or GPU for numerical tasks.

jdeseno 14y ago

For the people who don't like Erlang's syntax, there are alternatives. I've used Elixer (http://elixir-lang.org/ http://elixir-lang.org/) with some success. It has a Rubyish syntax and gets rid of a lot of the warts newcomers seem to dislike. The language is actually the easiest part, the biggest hurdle seems to be organizing a complicated application to take advantage of OTP. Erlang is really about OTP; not the language.

pkulak 14y ago

From what I can tell, Go seems to have about the same concurrency primitives as Erlang, but is much more approachable. Could someone start a new project in Go that would have required Erland a couple years ago?

mseepgood 14y ago
They are both based on CSP, but Go channels are a little bit different: http://www.youtube.com/watch?v=f6kdp27TYZs&t=4m57s http://www.youtube.com/watch?v=f6kdp27TYZs&t=4m57s
- mononcqc 14y ago
  There is not much that is CSP about Erlang.
- bascule 14y ago
  The main difference between CSP in Go and the actor model in Erlang is that actor mailboxes are many-to-one whereas CSP channels are many-to-many. If you were to model CSP using actors, channels would be actors.
  - Mr_T_ 14y ago
    And you can send a channel over a channel or store it in a data structure or pass it to a function.

skue 14y ago

Most of the comments here talk about additional advantages of Erlang without commenting on the point of the original article -- which is that servers would move towards multi-core systems where Erlang excels. Of course, this hasn't really happened, because we've moved to cloud services instead, which typically offer a single virtual CPU. I'm not arguing against Erlang. It's a great language and folks could certainly choose to run it on their own multi-core system or scale across multiple virtual servers. But startups often pick the technology they can get running with minimal investment, then scale from there: a VPS or two with a single CPU and constrained RAM. So although Erlang might be a great long term investment, it requires a lot of RAM up front and hyped features like multi-core support don't matter as much to young startups choosing technology at the early stages. It would be great to see more discussion about how well Erlang scales across multiple VPS systems -- and not just theoretically, but how many systems you can practically scale across, how it impacts performance, RAM usage, etc. Plus how this would compare to just using an independent messaging queue/bus to accomplish the same thing in another language.

vonkow 14y ago
I'm by no means an expert, but I have written production Erlang applications (the instapaper-like functionality on bostonglobe.com). We initially had it running as a network of 5 VPS systems (three web-facing servers with copies of the entire db in memory and two machines keeping disk copies), which performed more than adequately. Even with the db in memory, RAM usage really wasn't an issue for us. The runtime was initially designed to run embedded in telephone switches so it's pretty lightweight, all things considered. I've heard talk that things start to get a little hairy once you scale to around 100 nodes, due to the sheer amount of messages getting passed around (there are ways around this, like creating hidden nodes that communicate between clusters). Performance across multiple VPS systems is really going to vary dramatically between different applications and VPS setups. An app that has to make lots of requests to other nodes, which are located across the globe, is going to suffer a lot more than one that has relatively little internode communication between VPSs in the same server rack, but that's just common sense. I'd be really interested to know what companies like Basho (creators of Riak) and Facebook have experienced with large setups, as horizontal scaling is one of the language's selling points. More so than scaling across multiple cores and machines, I find that one of its strongest points is it's scheduler. If one request to a server is particularly processor intensive (or hangs), it's not going to affect other requests, which is an awesome feature to have even with a single core. Erlang's definitely not for everything, but once yo get the hang of it, it's really easy to prototype in, scales well, and is generally lightweight enough to run on a cheap cloud instance (or embedded on a Raspberry Pi).

knodi 14y ago

I really like Erlang and have been using it on and off for about a year. Recently I starting playing around with Golang and much to my surprise goroutines are a very good homage to Erlangs concurrently model.

lucisferre 14y ago

One of the things the author failed to mention, when he asks if Erlang is difficult, is it's verbosity for anything non-trivial. Just try building something using WebMachine for example. You will end up repeating the same tedious boiler plate code for each and every resource. Very, very, fortunately the Elixir project seems to be making some headway and may just bring some decent language usability to Erlang. Erlang, is great architecturally, but in a lot of ways it's a toy language. It is going to need to evolve a bit to become palatable to the mass web development market.

tikhonj 14y ago
Hey, being verbose has never impeded languages like Java and Python.
- lucisferre 14y ago
  I don't know much Python but as far as I k now it is capable of extension via mixins and Java can do similarly through AoP and inheritance. Erlang can do neither of these out of the box. What I'm really referring to is how dry a set of modules is capable of being, avoiding repeated boiler plate code being employed each and every time.
  - asabil 14y ago
    In the Erlang world, you do that by creating behaviors.

cantankerous 14y ago

Doesn't the N-times speedup on N cores really require you to write perfect Erlang? I feel like that's a really optimistic prediction. Even the authors said they needed to give their original programs some tweaking, and they're Erlang pros. At this point, I remain skeptical of this claim.

MetaCosm 14y ago
Not as much as you would expect. The natural way you build systems in Erlang is across erlang-processes (micro processes). Even if you are building an application running on a single core, you use erlang-processes extensively. This means for a little TCP-IP server, you use one erlang-process per incoming connection on one core or 32 -- the only difference is how they are schedule, when you are on 32 cores the Erlang VM starts up more threads and then schedules the erlang-processes across the VM threads and those threads are scheduled across physical processors. The trick is -- when you build software in Erlang -- you start up new processes for the true concurrency (in a web application, the true concurrency is number of connections, so they get there own processes). This means that Erlang applications routinely have hundreds of thousands of processes -- which makes it easy to schedule across a mere 32 or 64 or 128 physical cores.

nickknw 14y ago

I'm blogging my way through Seven Languages In Seven Weeks. Reading this makes me really look forward to the Erlang chapter. Only the last bit of Prolog and Scala stands between Erlang and I now!

tomerbd 14y ago

About this section in his article " The world IS concurrent. It IS parallel. Things happen all over the place at the same time. I could not drive my car on the highway if I did not intuitively understand the notion of concurrency; pure message-passing concurrency is what we do all the time." i dont get it i dont think this is correct when i drive my car into a gas station i wait for the person before me to finish filling his gas tank as he is using (locking) the gas stand anyone thinks what im saying is incorrect?

CalEl 14y ago

I had to use Erlang for a uni project and didn't mind it but it's not my favourite language.

mistercow 14y ago

Now that we're seeing lots of cores on the machines of ordinary people, what would be really nice is if languages like Erlang, which are by design better for parallel computing, could efficiently target JavaScript while taking advantage of web workers. As more and more application development becomes web based, it's really a shame to see almost-always-idle core after almost-always-idle core added to user end CPUs.