As you may have noticed, Ericsson hasn't done the best PR for Erlang. The closest things resembling sales pitches I see from that part of the world are either academic-looking papers or PowerPoint presentations that require downloading heavy PDF files. There are also the mailing list postings that are often intelligent and hilarious but they are ultimately preaching to the choir.
When people talk about Erlang, they usually mention how Erlang is great for building concurrent, distributed, highly-available, fault-tolerant, systems; it powers phone switches with nine nines availability; the AXD 301 switch has 850K lines of Erlang code; Yaws scales with large numbers of connections; ejabberd is the most scalable XMPP server; and all sorts of such heavy-sounding accomplishments.
If I hadn't read Joel Reymont's wagerlabs.com blog, where he wrote about his experiences writing a poker server in Erlang, I probably would have never thought I would actually like Erlang as a language.
What nobody from Ericsson talks about is that Erlang makes coding FUN.
It may be possible to arrive at this realization through deduction: to build large-scale, stable systems you need a productive language. If the language got in your way and prevented you from doing things in a straightforward manner, your code would start growing in complexity. Complexity leads to bugs. Bugs lead to downtime. Systems written in Erlang must have close to zero downtime. Therefore, Erlang must make developer's lives easy.
For developers, ease often equates with fun. Ease means that they can express their thoughts succinctly, test their solutions quickly, and then move on to the next problem.
Programmers love garbage collection, for instance, because it makes their lives easy. Similarly, some programmers are Ruby fanatics because they think Ruby is the epitome of ease (I used to think so too in the old days -- about 3 months ago :) ). Other programmers believe ease comes from using functional languages, because they are the most powerful.
You can read Paul Graham's essays on Lisp about this. You can also read Peter Norvig's comparison between Python and Lisp. (As you're reading this comparison, mentally add Erlang as well as 2 more categories: concurrency and fault tolerance, and picture Erlang as being the top dog :) )
So what exactly makes Erlang coding fun? To me, these are the main factors:
- Erlang is a functional language. It fits well in my brain.
- Erlang is dynamically typed, which means that I can write less code (read Haskell vs. Erlang, Reloaded) and also test my code easily in the Erlang shell. (Erlang's dynamic nature also allowed me to create Smerl :) )
- Erlang has pattern matching, which lets me write a single line of code to express a thought that would in other languages translate into a horrendous structure of nested if-else statements.
- Erlang has single-assignment semantics, which means that functions have no side effects (on bound variables). This makes Erlang code very readable. It also makes debugging easy.
- Concurrency, concurrency, concurrency.
- With Erlang's hot code swapping, I can deploy my changes unto a system while it's running. When I made the haXe remoting adapter for Yaws, I didn't have to take Yaws offline (try that with Apache or Lighttpd :) ).
- The compiler checks the validity of my code without locking me into a type system.
- Good runtime metaprogramming capabilities (with Smerl).
- I used to like Eclipse, but Erlang made me an Emacs fiend :)
- I'm learning a lot and interacting with very smart people.
Some people have asked me, "If all I want is to build a stateless, CRUD-style webapp, and I don't need telcom-grade scalability, etc, why should I bother learning Erlang? Ruby on Rails handles it just fine. It also has more web development libraries."
I hope I was able to give a reasonable answer to this question. However, as much as I write about Erlang, reading this blog won't take you all the way there. You have to experiment with Erlang and see how it feels for yourself. I can't guarantee you'll like it -- all I can do is tell you why I do.
39 comments:
That programming in Erlang is fun was one important message that we tried to get through when we at Ericsson's CSLab gave internal courses to Ericsson personel. But boy what a hard work that was. I recommend Bjarne Decker's Thesis as an interesting read on the topic.
Hi Tobbe, by "us" I meant the "general public." There's no indication on the website or in any of the tutorials that Erlang == FUN (or if there is, I didn't notice it). Ruby on Rails has much better marking on that front. I don't mean to criticize CSLab's efforts -- I'm just noting the perception of an outside observer.
For me, Erlang is fun (although not in some cases) but so is Haskell and Lisp.
C is not fun, Python can be fun until you have to do multi-threading with mutexes. But doing GUI with Python is fun (I bet doing GUI with Erlang is not much fun).
I am not sure how to difene what is fun and what is not, but surely is not a simple definition and most of the jobs aren't fun.
Wow this is a real-time as it gets in blogging. Yariv great blogging and promotion of Erlang. BTW cool name too.
I worked for a wireless company here in Canada whose name I won't mention except for it was Rogers. Anyway they used Ericsson's AXE mobile switching centres. Thats when I learned about Erlang back in 1997. Great to see it was set free and being evangelized.
Hi Robert,
I'm afraid that you can find most answers to your questions by Googling, reading the Yaws documentation as well as my past postings, and also by learning Erlang and doing some tutorials. There are also very mailing lists where much smarter people than myself will help you out.
For all those extra libraries you want that you think are missing, you can either build them yourself or keep reading this blog because your desires may be answered sooner than you think ;)
I will just say one more thing: I don't know about VIM :)
Best
Yariv
Bob: Thanks a lot for answering my questions. Your answers are very helpful. When I get some bandwidth, i'll go take Erlang out for a spin.
Yariv, I'm trying to be disciplined and stay on my self-appointed task of learning Lisp, but when I find your blog and read the daily enthusiastic posts, I just want to run off and play with Erlang :(
I find it interesting that you're taking to Erlang after getting to know Ruby. But you say functional programming fits your brain, and that's great. For other programmers' brains a few of the reasons you cite for having fun with Erlang I presume would be true of Ruby as well (runtime metaprogramming, dynamic typing, smart people, I'm sure some Ruby people like Emacs), but to me the biggest difference is the concurrency and message passing. The book Programming Ruby makes it sound like you have to be so incredibly diligent to get benefit from Ruby threads. And using pipes you can communicate between threads or processes, but it doesn't seem as natural as the Erlang message passing.
The question I keep asking myself is why would Erlang have a monopoly on its style of concurrency and super cheap processes? What's stopping a Ruby or C++ programmer bored of shared memory from peeping the Erlang source and building an amazing threading system into his favorite interpreter or compiler? Is there something fundamental to message passing that doesn't jive with other programming styles?
Thanks Yariv for your enthusiastic blogs.
Question: I am wondering if you can tell us your thoughts on how Erlang and Limbo/Inferno from Bell Labs/Lucent (see: http://www.vitanuova.com/ and http://cm.bell-labs.com/plan9/) compare. It seems to me that both model concurrency according to the Communicating Sequential Processes (CSP) process algebra of C. A. R. Hoare (see: http://en.wikipedia.org/wiki/Communicating_sequential_processes ).
Also, I just looked at Erlang but still don't know exactly why they use a period to terminate statements. Can you tell me why - I hope there is a good reason besides the analogous one.
------
By the way, we all know "fun" is a relative thing (-: However, syntax plays a significant role.
Besides Erlang, a short list of languages I consider "fun" (at least to learn) include:
J (son of APL) - http://www.jsoftware.com/
Take an aspirin while you try it. Just kidding (-: But definitively worth it - it will amaze you.
J is a non-von Neumann programming language. So it is functional but not in the traditional (confused) sense. Great for numerics.
See: http://en.wikipedia.org/wiki/J_%28programming_language%29
REBOL: the "relative expression based object language" and dialecting language.
http://www.rebol.com/
Actually I think REBOL is very promising and is definitely "fun", lean, and mean with virtually no baggage. It is somewhat Lispish/Schemish in style. Worth looking into it.
SETL & family - http://en.wikipedia.org/wiki/SETL_programming_language
Based on set theory. Cool ideas but unfortunately this language is somewhat moribund.
PROLOG - http://en.wikipedia.org/wiki/Prolog_programming_language
Mathematica - http://www.wolfram.com/
This is commercial software but great especially for symbolics.
Of course the Lisp / Scheme family.
Yes, there are others but don't want to put you to sleep...
-fva
Oops - Don't know why blank lines got chewed out. Also, the Wikipedia J link got trimmed. Just click on the trimmed link and follow the 1st link on the Wikipedia page.
Sorry, - fva
Yariv,
Sorry about the "period" question above. I am just a newbie. The following code for the factorial function from "Getting Started With Erlang" made the answer clear to me
-module(tut1).
-export([fac/1]).
fac(1) -
1;
fac(N) -
N * fac(N - 1).
Regarding the FUN aspect. marketing etc. It is an intersting question why Erlang hasn't become more popular (and well known) than it has. We (the Erlang community) has discussed this on and off for years. I guess many of us old-timers got tired of discussing this and started to spawn of start-ups to build fun products using Erlang instead :-) Perhaps if O'Reilly could be persuaded to write a nice Erlang book we could get some more public focus on Erlang.
Bob -- to be precise, I should have said that functions don't have destructive side effects on previously-bound variables. I find this to be an a fantastic but seldom spoken-about language feature and relatively few non-functional programmers know about it. When I started coding in Erlang, single-assingment felt weird and restrictive, but now I understand the brilliance behind it.
I think saying that web developers *don't need* to use concurrency explicitly may be a misconception that has been created by the fact that most web development languages suck for concurrency. If you're building a Meebo-style app, you certainly need scalable, effective concurrency. Even RoR has a "concurrency" library (http://backgroundrb.rubyforge.org/), but it palls in comparison to what Erlang has to offer. In addition, for serving a CRUD-style app, maybe you really don't need to touch concurrency features directly, but when you try to do anything remotely more complex, concurrency often becomes a requirement. Erlang is years ahead of any other language in this department, and this gives Erlang web shops a competitive advantage.
Shawn: After I read Hackers and Painters, I had a growing desire to learn Lisp as well (I did Scheme in college, never touched it since), but I already got hooked on Erlang as well :)
As I wrote in my article, "Why Erlang Is A Great Language for Concurrency," I truly believe that concurrency is something a language has to "get right" from the beginning. Erlang "got it right" because it was designed from the ground up for concurrency programming. Even if other languages added some Erlang-style message passing, it would take years for the developer communities to adopt them and for open source software to utilize them. What differentiates Erlang from most languages is that Erlang's creators created a culture of concurrency among its developers. Concurrency is everywhere you look in Erlang code. This is partly why Joe Armstrong says Erlang programmers have a head start.
Pupeno, fun is certainly a relative term. All I can say is why I think Erlang is fun, and I can't promise it would be fun for everyone. If I wanted to write a native GUI, Erlang would probably make my life pretty hard (Joel Reymont is working on Erlang-Cocoa bindings, though, so things are changing). However, for the problems I enjoy solving, working with Erlang is pure joy.
Tobbe -- there's definitely a glaring mismatch between Erlang's power and developer's awareness and adoption of it. That's partly why I started this blog. I thought more people should know about it. Then again, I think Ericsson can do many things to make Erlang more accessible to outsiders: redesign the website, make the documentation friendlier, keep an official blog, etc.
fva -- thanks for the feedback and all the intersting links. It'll take me a little while to go through all of them :) In Erlang you use a comma to terminate expressions and a period to terminate function bodies. I think that's because Erlang doesn't have Lisp's entirely list-based structure, but there might be some other reasons.
Shawn, I think what you suggest is possible, witness Termite Scheme for a good example of a rewrite of Scheme using Erlang concurrency concepts. But somebody's gotta 1) understand how to do it, 2) want to do it instead of something else (opportunity cost), and 3) actually do it. Apparently there aren't many people that meet those three criteria. The Termite project for instance is being done by a bunch of grad students. The Java world seems satisfied with locks and synchronization for concurrency, rather than an outside-the-box approach, though I've no idea what they have in mind for future versions beyond Mustang (or what MS has in mind for future C#).
And I agree with Yariv, in most cases I'd rather work with a language designed from the ground up for concurrency, if concurrency is what I need, than something that was modified to support it. And it is fun to work with, especially b/c when I'm working with Erlang I feel like I'm really learning something new, rather than a reimplementation of the same old concepts. That alone is enough to drive me to spend all my free time working through the getting started guides and docs and blogs on it.
However, some past threads here have questions Erlang's usefulness in every situation, and there's nothing wrong with that. A great example is ITA's technology, which is an interesting mashup of Lisp, C, C++, and Java, in which the strengths of one replace the weaknesses of another in a best-of-breed integration. There's nothing wrong with thinking like that when considering architecting an Erlang application, assuming you actually know the languages in question well enough to make the right calls. I think a lot of us are still trying to get to that point - understand Erlang well enough to know its strengths and weaknesses and how and whether to combine it with other languages for particular applications.
I'm just wondering how Erlang fair against Zope.
@Tobbe: Do you have materials like slide shows, papers, and so forth from that internal marketing effort? And if so, can you release these (under some nice license) if they are interesting?
@Byron: An example is ejabberd: it uses C on some places where Erlang would be too slow.
Gah. The AJAX comment post is massively unintuitive. :-/
The link about 1.7 MLOC is for slide 27 (pdf page 28).
Either that slide is wrong or the Erlang FAQ needs to be updated.
"
AXD301 has several hundred people working on it and the code volume has reached about 850 kloc of Erlang (and 1 Mloc of C/C++).
"
http://www.erlang.org/faq/t1.html#AEN50
Obviously 850KLOC is still sizeable, but it's better to be accurate. :)
The link about 1.7 MLOC is for slide 27 (pdf page 28).
Either that slide is wrong or the Erlang FAQ needs to be updated.
"
AXD301 has several hundred people working on it and the code volume has reached about 850 kloc of Erlang (and 1 Mloc of C/C++).
"
http://www.erlang.org/faq/t1.html#AEN50
Obviously 850KLOC is still sizeable, but it's better to be accurate. :)
Thanks Jeremy, I'll fix the number in the posting.
The PDF you link to has a funny mistake:
"... up to 80,000 disturbing processes"
Why Ericcson forgot to tell us that Erlang is fun?
Maybe Erlang is their secret weapon to be ultra-productive in telco business?
More powa for them who used it! ^_^
Usually before I learned a language I checked their background first.
Java was designed for network stuff and it is proven, they're suitable to do distributed systems.
C/C++ was designed for systems level programming (or things that required more speed like Game programming which exploit the graphics chip), they, too, are proven to be exactly what it was designed for.
C# is just a better version of C++/MFC for Desktop application, same thing here, it is proven C# to be more suitable in desktop arena than in web-app.
Python was designed because Perl looks ugly. Python also was designed to be a glue language. And again.. it was proven than Python is a great glue language (nobody in Python community ever debated that everybody should use Python to write all of your GUI and all of your games).
PHP... go figure out? :P
Well, most languages are designed to do specific tasks (though the tasks are not too narrow/limited as you may think).
Erlang was designed to tackle telco's problems and I assume it will stay like that ^_^.
I don't mean you should not learn Erlang to do your web-app. By all mean, go ahead and be an Erlang evangelist. But I do hope Erlang evangelist don't go too nuts like those Ruby on Rails MLM people.
By the way, in my own opinion, maybe Ericcson people don't really care if Erlang would be successful. They're not selling Ruby on Rails like service around Erlang unlike those Pragmatic Bookshelf people. Erlang solves their problem and that's all there is to it. They need to make money on other things.
Period is from Prolog. (In which the first implementation(s?) of Erlang were written).
Ed -- I've met most of the people who created Erlang, and although it's true that Erlang's popularity isn't likely to affect Ericsson's bottom line, many of them are truly puzzled by the fact that Erlang isn't the most popular language on the planet for building real-world systems ;)
Yariv, you really should have put the last bullet point on top of the list. This is "the Python paradox" - if you choose to learn such a language (not necessarily Erlang, but also Haskell, Lisp, etc.) you'll inevitably run into very smart people. For me this was one of the most important rewards - really great people you can learn from don't grow on trees.
Just to be fair with regard to pattern matching :
Some other languages don't force you to use if/else, they have a 'CASE' like construct.
I admit that the erlang mechanism is more elegant.
Yariv,
I admit it, I'm fascinated by the idea of Erlang....but...well. Here's the thing.
I'm an IT programmer ( boo! hiss! ). I design applications and glue services together (what yegge called serverware). It's hard for me to understand what Erlang can do for me because the evangelists are usually talking at a crazy-smart Comp Sci PhD level of implementations.
I think this is something where PHP, Perl, Python, and (lately) RoR have excelled. Within 2 tutorials at O'Reilly, you can see how "Oh this can be used to make something better / easier for end users".
Re: Haskell / Erlang . It's a cool language and i loooove languages ( philo. degree and all.. ) but a series of example solutions in the have not appeared. When i search for examples of Erlang I've not yet seen a problem I have that Erlang would rock at.
Maybe this is all just a problem with my problemset....
A few people besides myself seem to think that building webapps with Erlang/ErlyWeb is easier than with Rails: http://progexpr.blogspot.com/2006/12/erlyweb-blog-tutorial.html. Erlang is actually a pretty simple language -- simpler than Ruby, Python, Perl and Haskell.
Yariv, to me these lines of code are not simple
-module(start).
-export([boot/0, boot/1]).
Now, a friend of mine with no Python background read his friend's Python source code because his friend asked him to debug the code (his friend was a little bit clueless). My friend can read, understand and fix the code quite fast with no help of manual whatsoever.
I kinda agree with him.. Python does look easier than Erlang. Your argument is kind of biased unless you can pick some random human being and gave him/her an Erlang code to be modified.
-module(start).
-export([boot/0, boot/1]).
Those lines don't look intuitive at all.
neither these lines
compile() ->
erlyweb:compile("/path/to/app/blog",
[{erlydb_driver, mysql}]).
To say that ErlyWeb framework is easier than Rails is also a little bit misleading (given that people thought Rails is easy)
I was tempted to check out Rails thanks to their great marketing scheme: make your own blog in 15 minutes.
I downloded eBook of Rails (the thiniest one from Bruce A. Tate, a half-baked book just to generate some sales). Followed some example from chapter 1 to 3. Concluded that if you really need to use Rails, you have to learn Ruby.
Learning Ruby takes quite some time. It's not easy. Learning Ruby the crappy way is easy. Learning Rails by going through examples DOES make it look easy.
But rolling a professional product in Rails IS not easy.
For me, Rails is sort of a trap. It looks easy when they do it on their screencasts but in actuality, it is not (especially if you need to extend Rails to the next level).
Ed, to use ErlyWeb of course you have to be somewhat familiar with Erlang. And Erlang is different from OO languages such as Python, so unless you have some familiarity with functional languages, unfamiliar Erlang code may not seem easy to understand. However, ease and simplicity are somewhat different things. Erlang is simpler than Python, Perl and Ruby because as a language, its semantics are much simpler, i.e. it has fewer rules and concepts you need to know in order to use it (which doesn't mean it's less powerful -- quite the opposite, actually). The same goes for ErlyWeb vs. Rails. But whereas simplicity is arguably objective, ease is subjective, and that's why using ErlyWeb may not be as easy as using Rails for some people -- at least until they learn a bit of Erlang.
I think that conceptually, ErlyWeb is both simpler and more elegant than Rails, partly because of ErlyWeb's design and partly because it's based on functional semantics rather than OO/imperative semantics. This elegance also makes it easier to use IMO. But I guess I may be biased :)
@Ed:
I agree, I don't know python but a friend and I were discussing a problem and he wrote in python, I wrote in Perl and much like a Spaniard talking to an Italian, we got through with only a few double-checks.
The Erlang code you cited ( from Wikipedia ) doesn't immediately share its secrets, nor does erlang have a 'build a blog in 15 minutes' screencast. Screencasts sold me on Textmate and Rails - perhaps Yariv will deign to do a "Here's why you totally gotta use Erlang" screencast.
Interesting comments.. :D
Erlang has benefits that have already been stated with regards to concurrency and its decoupling from the threads/locks/semaphores etc. I am an engineer with a big blue company and have been programming professionally for 20 years. I see many posts here talking about syntax and have to think that you guys may be a little green when it comes to software development. If Erlang provides a better solution for concurrent programming then perhaps you should look at it from the angle of whether or not concurrent programming will be skill that will be needed more and more in the industry to remain competitive, and if Erlang is the best tool to use to complete the job then it may be in your best interest as a programmer or someone learning to be a one to understand this language. The criterion for a good solution is not necessarily that it can teach you to throw together yet another blogging app in 15 minutes, but what it can do for you when you work with the tool for a 6 month or year long project and have mastered it, and finally what sort of application you are able to produce VS the other tools would have enabled you to do. Good software engineers like tools that allow them push the hardware to the limits in an efficient manner, not do what any idiot can do in 15 minutes and get scared of something that looks like it might involve some technical skill (very minor, Erlang is very elegant).
[...] Yariv’s Blog, Ericsson’s Biggest PR Blunder [...]
Post a Comment