Comments on: Notes on A History of Erlang http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/ Open Source, Modern Programming Languages, OS X, Photography, and ... Fri, 05 Dec 2008 12:40:07 +0000 http://wordpress.org/?v=2.6.2 By: Internet Alchemy » links for 2008-06-03 http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15363 Internet Alchemy » links for 2008-06-03 Tue, 03 Jun 2008 23:36:58 +0000 http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15363 [...] Notes on A History of Erlang Good summary of history of Erlang paper (tags: erlang history language) [...] [...] Notes on A History of Erlang Good summary of history of Erlang paper (tags: erlang history language) [...]

]]> By: Jim Roepcke http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15340 Jim Roepcke Thu, 29 May 2008 16:25:52 +0000 http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15340 I think (but haven't yet verified) it's a popular misconception that Erlang implements the Hewitt actor model. I've scoured Google and haven't found a single reference to the actor model from Erlang folk like Joe Armstrong. It's not mentioned once in his new Erlang book either. My hypothesis is this myth is allowed to persist because it's "close enough" to the truth, it's harmless, and it is helpful to have a more generic label than "Erlang-style concurrency" when they clone Erlang's messaging semantics, as many now languages have. Note that Armstrong says Erlang implements CSP (Communicating Sequential Processes), which is very close to the Actor Model but not quite. There's a page on the c2 wiki comparing them (http://c2.com/cgi/wiki?ActorsModel). I've been planning on e-mailing Joe Armstrong about this for a paper I was working on for the Erlang workshop, but life and illness have gotten in the way in recent weeks so I haven't gotten around to it and might not make the submission deadline. :( I think (but haven’t yet verified) it’s a popular misconception that Erlang implements the Hewitt actor model. I’ve scoured Google and haven’t found a single reference to the actor model from Erlang folk like Joe Armstrong. It’s not mentioned once in his new Erlang book either. My hypothesis is this myth is allowed to persist because it’s “close enough” to the truth, it’s harmless, and it is helpful to have a more generic label than “Erlang-style concurrency” when they clone Erlang’s messaging semantics, as many now languages have.

Note that Armstrong says Erlang implements CSP (Communicating Sequential Processes), which is very close to the Actor Model but not quite. There’s a page on the c2 wiki comparing them (http://c2.com/cgi/wiki?ActorsModel).

I’ve been planning on e-mailing Joe Armstrong about this for a paper I was working on for the Erlang workshop, but life and illness have gotten in the way in recent weeks so I haven’t gotten around to it and might not make the submission deadline. :(

]]> By: Ulf Wiger http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15339 Ulf Wiger Thu, 29 May 2008 13:58:24 +0000 http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15339 The first working SMP version of Erlang was described in 1998 (http://www.erlang.se/publications/xjobb/0089-hedqvist.pdf). Back in those days, SMP hardware was big and expensive, and not something that we could use in embedded telecoms systems. For that reason, no money was spent trying to productify it. So it is true that the existing SMP Erlang implementation has not been around long, even though the concepts have matured over the last 10 years since the first prototype. We have found it very stable, and it's already in use in commercial products. You are right in observing that the development of Erlang has always been a very pragmatic effort. The first working SMP version of Erlang was described in 1998 (http://www.erlang.se/publications/xjobb/0089-hedqvist.pdf). Back in those days, SMP hardware was big and expensive, and not something that we could use in embedded telecoms systems. For that reason, no money was spent trying to productify it.

So it is true that the existing SMP Erlang implementation has not been around long, even though the concepts have matured over the last 10 years since the first prototype. We have found it very stable, and it’s already in use in commercial products.

You are right in observing that the development of Erlang has always been a very pragmatic effort.

]]> By: Gordon Guthrie http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15338 Gordon Guthrie Thu, 29 May 2008 11:16:40 +0000 http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15338 Regarding SMP support - to maximise the use of an SMP box with Erlang is easy - start as many different Erlang Virtual Machines as there are processors... Erlang has *always* been SMP... But Erlang didn't have support for multi-core (many concurrent execution threads per processor) until people started building them - and it got support for multi-core pretty sharply then... (ie the virtual machine became multi (operating system) threaded... Regarding SMP support - to maximise the use of an SMP box with Erlang is easy - start as many different Erlang Virtual Machines as there are processors…

Erlang has *always* been SMP…

But Erlang didn’t have support for multi-core (many concurrent execution threads per processor) until people started building them - and it got support for multi-core pretty sharply then… (ie the virtual machine became multi (operating system) threaded…

]]> By: Sylvain Hellegouarch http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15336 Sylvain Hellegouarch Thu, 29 May 2008 07:06:38 +0000 http://www.sauria.com/blog/2008/05/28/notes-on-a-history-of-erlang/#comment-15336 I find the Erlang platform interesting. I mean its principles and ideas. I think it managed to go that way because it stayed fairly unknown for so long and wasn't never meant to be sold as an "enterprisey" solution like J2EE or .NET were. Had it been part of a more "let's build a platform that'll allow us to sell service afterwards" type of effort I think Erlang wouldn't be where it is now. I wonder though if the Erlang syntax is not a barrier to a larger adoption. Again probably this is not a desired goal from the Erlang developers anyway and thus is not a real issue. Indeed, more likely Erlang products will stay as described "An Erlang system can be thought of as a communicating network of black boxes". We'll see those boxes appearing in many areas where reliability and scalability are critical and applications will hook up in some ways with a more accessible from a developer's, thus a company's cash spent on salaries, point of view. In that kind of scenario Erlang systems will do just fine and its those plugged-in applications that'll fail them. Interestingly ejabberd for instance could well be one of those most important Erlang applications out there in a near future considering it provides the strength of Erlang while being dead easy to hook into using XMPP. A side note, for pythonistas out there, I believe that Kamaelia is a very interesting project as it provides some aspects of what Erlang can provide as library written in Python. I encourage developers to have a look at it. http://kamaelia.sourceforge.net/Home Happy coding. I find the Erlang platform interesting. I mean its principles and ideas. I think it managed to go that way because it stayed fairly unknown for so long and wasn’t never meant to be sold as an “enterprisey” solution like J2EE or .NET were. Had it been part of a more “let’s build a platform that’ll allow us to sell service afterwards” type of effort I think Erlang wouldn’t be where it is now.

I wonder though if the Erlang syntax is not a barrier to a larger adoption. Again probably this is not a desired goal from the Erlang developers anyway and thus is not a real issue. Indeed, more likely Erlang products will stay as described “An Erlang system can be thought of as a communicating network of black boxes”. We’ll see those boxes appearing in many areas where reliability and scalability are critical and applications will hook up in some ways with a more accessible from a developer’s, thus a company’s cash spent on salaries, point of view. In that kind of scenario Erlang systems will do just fine and its those plugged-in applications that’ll fail them. Interestingly ejabberd for instance could well be one of those most important Erlang applications out there in a near future considering it provides the strength of Erlang while being dead easy to hook into using XMPP.

A side note, for pythonistas out there, I believe that Kamaelia is a very interesting project as it provides some aspects of what Erlang can provide as library written in Python. I encourage developers to have a look at it.

http://kamaelia.sourceforge.net/Home

Happy coding.

]]>