I used to all kinds of syntax or absence of it, like in Lisp or Forth. So I have no problem with Erlang syntax itself, but with its verbosity and inconsistency.<p>1. Versbosity<p>Sorted by code verbosity level, Erlang is somewhere in between Java/C++/C# (more verbose) and Ruby/Python (less verbose). But closer to dynamic languages, since you don't need to specify the types.<p>OTP code is significantly more verbose than plain Erlang and adds some boilerplate code (which can be generated for you by tools, like emacs or rebar, but you still need to read it and maintain it).<p>When you adding dialyzer specs, code become even more verbose. Since you need to duplicate function and argument names in the specs. Even worse - you need to duplicate dialyzer specs in edoc specs, since edoc uses it's own specs.<p>You can write your own macros and parse-transforms to reduce verbosity, but they aren't 1st class citizens and will not work from shell.<p>Given said all that, you still can expect up to 1:10 SLOCs reduction, comparing to C++ or Java, for large real life distributed applications.<p>2. Inconsistency<p>Example of inconsistency:<p><pre><code> proplists:get_value(Key,Proplist)
dict:fetch(Key, Dict)
dict:find(Key, Dict)
gb_trees:get(Key, Tree)
gb_trees:lookup(Key, Tree)
ets:lookup(Tab, Key)
dets:lookup(Tab, Key)
element(Index,Tuple)
lists:nth(Index,List)
array:get(Index,Array)
</code></pre>
All this can be written in modern languages as:<p><pre><code> Data[Key]
Data[Index]</code></pre>
Excellent post.<p>As I broaden (and continue to deepen) my knowledge of programming languages - Ruby, Python, Objective-C, C, C++, Java, JavaScript, Prolog, Scheme, Racket, Common Lisp, Io, Haskell, Clojure, Smalltalk ...<p>... I've become very, <i>very</i>, <i>VERY</i> wary of programmers who are overly concerned about syntax.<p>I've also become wary of programmers who care too much about regex and string manipulation facilities.<p>This post does a great job of concretely explaining why I have misgivings about people who express these kinds of opinions.
<i>Remember this: “In OO-languages state is kept in objects; in Erlang, state is kept in processes”.</i><p>If you think of OOP as "objects holding state and passing messages to each other", it's not difficult to map that idea to the Erlang world.
Strange to see there are people concerning about different syntax in different languages. Kind of like expecting Chinese language to have the same grammar as English.
As someone who has been learning Erlang for a few months now, I mostly agree with the article. The only statement that rubbed me the wrong way was:<p><i>Many Erlang programs are running in companies with no open-source policy as well - don’t expect the programmers of those systems to even be able to talk about what they do. It is a competitive advantage to keep the mouth shut.</i><p>In fact, I see the shut mouths as a disadvantage in some cases: coming from the Ruby/Rails world, it was a shock for me to not find an open-source library, yet find a request for it back in 2000. Further investigation revealed some well-known authors having worked with the closed-source version. What we'll probably do is take the equivalent Ruby library, and make it work through Erlectricity.
I've no horse in this race, but the comment..<p>"I have written production level code in Erlang, namely a BitTorrent client good enough for everyday use"<p>...seems to be going some way towards proving the Acharya's point #4 for the following reasons:<p>1) No reference to any actual users of the code apart from the author himself.<p>2) No link to where the code is available.<p>3) Code is a single-user client, when Erlang's strength is usually considered to be in multi-user servers.<p>It's not obvious that the author understands what is meant by "production level", since the project mentioned does not even appear to meet the most liberal possible interpretation of this term, which would be "shipped".
What matters to me is that code never relies on one person or a small group of people to maintain/improve it.<p>If a senior Python/C++/Java developer can open up the source code to some Erlang program that is having problems and fix a bug, then awesome. I can hire them by the boatload.<p>If I have to spend 2 months searching for a replacement for an Erlang developer that quit, well, that's not good at all.<p>My feeling is that senior Erlang people aren't exactly abundant. I have a friend who is flown around the world for Erlang contracting jobs simply because he's a well known senior Erlang guy. That makes me nervous as an employer.
Great post! Let me just say that for a person like me, who hasn't really used Erlang in large projects (mostly on small projects for fun), this post (as a retort to the previous one) was a really insightful introduction to the mentality behind/in Erlang.<p>One comment I've wanted to make about the initial post by Sudarshan Acharya and his point about Erlang's syntax is the following: before delving into functional languages, I had mostly experienced imperative & OO programming. The syntax of any language doesn't really bother me: it's already unintuitive enough that I have to learn <i>a new language</i>, based on typed text, to tell the computer what to do, that worrying about it / contemplating its reason for existence isn't gonna help me in any way.
I get pissed when noobs diss lisp for its parens, and yet I complain about erlang's syntax. Mea culpa.<p>When I complain about its syntax I'm really thinking about its error messages. Leave out a comma, or replace a period with a semicolon, and prepare to be confounded. They take some getting used to, and I've never managed to get past them in several attempts.
<i>The trick of OO-languages is “abstraction is had by introducing another object”.</i>
...
<i>In Erlang, the mantra is “abstraction is had by introducing another process”.</i><p>OK, it is hard for me to imagine that creating another process wouldn't have a larger conceptual overhead than introducing another object. Perhaps I just haven't seen the magic yet.<p>--<p>For me OO is far from a panacea. But does get some jobs done.<p>A big thing is the ability to construct multiple entities that can all be treated effectively the same way because they all implement the same interface. Your function happens to take Y structure. Suppose X inherits from Y but does something differently - Voilà, you have abstracted away your dependence from X. What would the Erlang equivalent to this be?