Ericsson’s Biggest PR Blunder: Forgetting to Tell Us That Erlang Programming Is FUN

Posted by Yariv on August 24, 2006

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.

Trackbacks

Use this link to trackback from your own site.

Comments

Leave a response

  1. Tobbe Thu, 24 Aug 2006 17:58:36 EDT

    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.

  2. Yariv Thu, 24 Aug 2006 18:04:43 EDT

    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.

  3. lickedcat Thu, 24 Aug 2006 18:15:06 EDT

    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.

  4. Pupeno Thu, 24 Aug 2006 18:15:28 EDT

    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.

  5. roberthahn Thu, 24 Aug 2006 19:42:35 EDT

    hmm… well, if I was one of the ’some people’ wanting to build stateless, CRUD-style webapps, I wouldn’t quite feel satisfied with the answer you’ve given yet. But as long as you’re ok with the dialogue, I’ll keep asking you the questions.

    This post has talked up how great it is that Erlang can be productive when you scale it up to big big big. And you know, that’s cool. I get that. But 99.9999% of all web scripts being used are tiny. like, 20-100 SLOC tiny. I can appreciate that you’d want to focus on the interesting web apps that would have high SLOC counts, but there’s still the basic fill-out-a-form, send-an-email garden variety script that has to be written. I’m a big fan of simple and small. Will Erlang fall over itself on small? Heck, can I use Erlang to send email notifications to people?

    So from the web developer’s perspective, the “Why Erlang?” question hasn’t yet been satisfactorily answered head on. But you do leave us some interesting breadcrumbs. Look at the bulleted list. Many of the items there sounds pretty enticing to me. I’m still concerned about how to deploy Erlang-based scripts, which you haven’t talked about at all, because I doubt that there’s much uptake by most hosting providers, and maybe you can talk about that. I also didn’t get the following points however:

    • Concurrency, concurrency, concurrency. — concurrency in a webserver i get. Not sure what this buys me on a script though.
    • The compiler checks the validity of my code without locking me into a type system. — I don’t understand this; the terms you use seem to employ definitions I can only guess at
    • Good runtime metaprogramming capabilities (with Smerl). — I can kind of see this, given what I see with the Camping microframework (in Ruby), but would like to know more
    • I used to like Eclipse, but Erlang made me an Emacs fiend :) — vim user here - please tell me that using vim to write Erlang isn’t going to make me feel like a second-class citizen, dude

    So, still interested. You obviously ‘get it’ when it comes to using Erlang for building web sites. I hope you’ll still be able to help the curious ‘get it’ too.

  6. Yariv Thu, 24 Aug 2006 20:44:38 EDT

    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

  7. Bob Ippolito Thu, 24 Aug 2006 21:47:40 EDT

    Functions having no side-effects is definitely not true, you should know better than that having written smerl! However, Erlang programmers are encouraged to isolate side-effects to message passing, so the majority of functions don’t really have any side-effects.

    Not all of Robert’s questions are easily answered by googling, here’s some thoughts:

    • Concurrency in a script doesn’t buy you anything at face value, however, *running* your script concurrently does. Erlang scales to millions of processes a whole hell of a lot better than operating systems do, so writing your scripts in Erlang (assuming they’re running in an Erlang-based server) means they run faster and you can run more of them concurrently. It’s not about code size or complexity, it’s about developing applications that respond faster and can be deployed on a fraction of the hardware that a “traditional” solution would require. In other words, Erlang can give you a quick development cycle AND killer “performance per watt” compared to other development paradigms.

      A quick development cycle currently requires a good deal of Erlang knowledge, but the learning curve is definitely going to get much shallower over the next few months/years thanks to attention such as this. Rails would be hard too if you gave it to a new user and didn’t give them good documentation and a thriving community to tap into…

    • The compiler mostly checks syntactic validity of your code, but dialyzer can analyze your code for things such as type errors and unreachable code using type inference and various other tricks.

    • Vim is generally “a second class citizen” to Emacs in any language that Emacs supports well. However, Vim’s syntax highlighting and indenting for Erlang works just fine. You can use Vim with Erlang just like you’d use anything else. FWIW, I prefer Vim for most code editing tasks, but I do use Aquamacs Emacs for Erlang programming because distel is great. I don’t use Emacs for anything else.

  8. Bob Ippolito Thu, 24 Aug 2006 21:47:48 EDT

    Functions having no side-effects is definitely not true, you should know better than that having written smerl! However, Erlang programmers are encouraged to isolate side-effects to message passing, so the majority of functions don’t really have any side-effects.

    Not all of Robert’s questions are easily answered by googling, here’s some thoughts:

    • Concurrency in a script doesn’t buy you anything at face value, however, *running* your script concurrently does. Erlang scales to millions of processes a whole hell of a lot better than operating systems do, so writing your scripts in Erlang (assuming they’re running in an Erlang-based server) means they run faster and you can run more of them concurrently. It’s not about code size or complexity, it’s about developing applications that respond faster and can be deployed on a fraction of the hardware that a “traditional” solution would require. In other words, Erlang can give you a quick development cycle AND killer “performance per watt” compared to other development paradigms.

      A quick development cycle currently requires a good deal of Erlang knowledge, but the learning curve is definitely going to get much shallower over the next few months/years thanks to attention such as this. Rails would be hard too if you gave it to a new user and didn’t give them good documentation and a thriving community to tap into…

    • The compiler mostly checks syntactic validity of your code, but dialyzer can analyze your code for things such as type errors and unreachable code using type inference and various other tricks.

    • Vim is generally “a second class citizen” to Emacs in any language that Emacs supports well. However, Vim’s syntax highlighting and indenting for Erlang works just fine. You can use Vim with Erlang just like you’d use anything else. FWIW, I prefer Vim for most code editing tasks, but I do use Aquamacs Emacs for Erlang programming because distel is great. I don’t use Emacs for anything else.

  9. roberthahn Thu, 24 Aug 2006 21:58:21 EDT

    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.

  10. Shawn Thu, 24 Aug 2006 22:16:33 EDT

    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?

  11. fva Fri, 25 Aug 2006 00:25:09 EDT

    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

  12. fva Fri, 25 Aug 2006 00:35:11 EDT

    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

  13. fva Fri, 25 Aug 2006 01:25:54 EDT

    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).

  14. Tobbe Fri, 25 Aug 2006 03:14:36 EDT

    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.

  15. Yariv Fri, 25 Aug 2006 03:21:01 EDT

    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.

  16. Yariv Fri, 25 Aug 2006 03:27:04 EDT

    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.

  17. Yariv Fri, 25 Aug 2006 03:31:22 EDT

    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.

  18. Yariv Fri, 25 Aug 2006 03:34:31 EDT

    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.

  19. Yariv Fri, 25 Aug 2006 03:39:55 EDT

    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.

  20. Byron Fri, 25 Aug 2006 03:49:21 EDT

    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#).

  21. Byron Fri, 25 Aug 2006 04:01:48 EDT

    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.

  22. KE Liew Fri, 25 Aug 2006 05:52:07 EDT

    I’m just wondering how Erlang fair against Zope.

  23. http://sander.dontexist.org/ Fri, 25 Aug 2006 14:19:01 EDT

    @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?

  24. sander Fri, 25 Aug 2006 14:53:23 EDT

    @Byron: An example is ejabberd: it uses C on some places where Erlang would be too slow.

  25. Jeremy Dunck Sun, 27 Aug 2006 15:27:50 EDT

    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. :)

  26. Jeremy Dunck Sun, 27 Aug 2006 15:28:05 EDT

    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. :)

  27. Jeremy Dunck Sun, 27 Aug 2006 15:28:33 EDT

    Gah. The AJAX comment post is massively unintuitive. :-/

  28. Yariv Sun, 27 Aug 2006 22:04:41 EDT

    Thanks Jeremy, I’ll fix the number in the posting.

  29. Anonymous Mon, 28 Aug 2006 01:21:57 EDT

  30. Alex Wed, 30 Aug 2006 01:29:18 EDT

    The PDF you link to has a funny mistake:

    “… up to 80,000 disturbing processes”

  31. Ed Mon, 18 Dec 2006 17:14:12 EST

    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.

  32. Logan Capaldo Mon, 18 Dec 2006 19:35:41 EST

    Period is from Prolog. (In which the first implementation(s?) of Erlang were written).

  33. Yariv Mon, 18 Dec 2006 20:50:40 EST

    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 ;)

  34. Slava Akhmechet Mon, 18 Dec 2006 22:35:32 EST

    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.

  35. Norbert Klamann Tue, 19 Dec 2006 02:42:08 EST

    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.

  36. Steven G. Harms Tue, 19 Dec 2006 11:26:42 EST

    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….

  37. Yariv Tue, 19 Dec 2006 11:36:34 EST

    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.

  38. Ed Tue, 19 Dec 2006 18:29:20 EST

    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).

  39. Yariv Tue, 19 Dec 2006 19:27:33 EST

    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 :)

  40. Steven G. Harms Thu, 28 Dec 2006 22:42:50 EST

    @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.

  41. imparare Sat, 14 Apr 2007 23:58:27 EDT

    Interesting comments.. :D

  42. Adam Hall Sun, 23 Sep 2007 05:32:10 EDT

    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).

  43. So Erlang It Is Sun, 20 Apr 2008 04:35:45 EDT

    [...] Yariv’s Blog, Ericsson’s Biggest PR Blunder [...]

Comments