I have used erlang in a number of large projects over the last couple years and for the most part I'm in agreement with the author about both the benefits and drawbacks of erlang (when people ask me about erlang I always say "erlang is great for anything that requires a lot of moving pieces and doesn't require the code to actually look nice or be readable"). I have a couple of other drawbacks I think should probably get mentioned:
Logging is..... strange. The recommendation is to use SASL, which writes your logs in a binary format that only another erlang library can properly read. SASL has some nice features, like auto-rotation and such, but I'd much rather have my logs get spit out in plaintext and just logrotate like I do with everything else. One of these days I'm going to write a proper erlang logger.
Rebar is strange. It's erlang's deployment tool thing, kind of like leinengen but much less intuitive. I tried getting used to it but found it just made testing more difficult and made setup a chore. I opted instead to just steal the makefiles from the mochiweb project and call it a day.
Records have easily the most annoying syntax of any language construct I've ever used. And god forbid you want nested records, have fun with your full solid line of selection syntax. Bleh.
Which isn't to say it's all bad, here's some other awesome things about erlang that I don't see pointed out often:
Polymorphic anonymous functions
The pattern matching is amazing. When I go back to other languages that claim to support pattern matching it feels like I've lost both your feet and replaced them with suction cups. There's no pattern matching like erlang pattern matching.
Hot-swapping of code. Somewhat unintuitive, and has weird behavior in certain cases, but still definitely better then restarting the server that thousands of clients have long-running connections on
Records. Their syntax is horrible, but their usefulness is infinite. They're basically just syntactic sugar on top of tuples that make them easier to manage and extend.
There's more for both sides, but I'll leave it at that. It's a great language, I highly recommend everyone take a stab at it. Even if you hate the syntax it's good exposure to thinking about how to code concurrently.
There is one massive thing that I picked up from using Erlang that you failed to mention and I think should be pointed out. I have applied it in various ways outside of Erlang with a large amount of success (and the habit has caused no end to frustrations when dealing with external libraries, particularly on the JVM). If there is an error of some sort, but it can be recovered from, is a potentially anticipated scenario, etc. and can be handled at the point of occurrence, handle it. If it can't be handled, return a response indicating an error. If it is an exceptional condition, blow up and let the next level higher deal with it if it can, and so on. You can enumerate any number of ways that something can fail, but you will never catch all of them. However, exceptions are not an error communication device, they represent a condition that cannot be handled where they occurred.
It didn't really sink in fully for me until I had to write my first full non-trivial Erlang application from start to finish. However, once it clicked, every piece of code I wrote was significantly more predictable, easy to reason about and had significantly less bugs.
If you want to see pattern-matching taken to its logical extreme, check out bondi[1]. This is a rather researchy language based entirely around pattern matching; the core idea is to use pattern matching as "a new foundation for computation".
Patterns are extended in several important ways. In total, this lets patterns be extremely generic; you can write code that is polymorphic over virtually any data you care to throw at it.
The language is heavily influenced by OCaml and supports both functional and OO-style code. It has static typing, which I think is very nice.
As a disclaimer, I've never used the language itself. I did read a book[2] about its design and played around with some variations on the lambda calculus leading up to the language itself. I also completely skipped over the OO sections of the book because I am a little tired of OO these days :P.
This is probably the second or third time I have come across this language in an HN comment. Every time I see it, I click the link, and try to click the links on bondi.it.uts.edu.au, only to get 403 FORBIDDEN responses from any link whose path starts with `~/cbj/`.
> erlang is great for anything that requires a lot of moving pieces and doesn't require the code to actually look nice or be readable"
Sorry, but this is such a BS claim. Yes, there are bits of Erlang syntax which are ugly. Yes, you can write absolutely unreadable Erlang code, just like in any other language. But the whole point is that Erlang is extremely expressive for the problems in question - distribution and fault tolerance. It allows you to write code which is multitudes shorter than in (almost) any other language. Your code ends up being very succinct which is a huge benefit because of clarity/maintenance/etc.
For some extremely elegant code go look around at basho[1] and 99s[2] code. In particular, riak_core and cowboy. These are works of art!
> It allows you to write code which is multitudes shorter than in (almost) any other language.
It's not clear if you're making that claim only for 'distribution and fault tolerance'. In that case, I don't know enough to say. For pretty much anything else, I'm sure that Erlang is much more verbose than Ruby.
Yes, I am only claiming that it results in shorter code for the code which deals with problems in that specific domain. In general -- obviously not! But the overall gain is still significant. I don't care if e.g. some library dealing with some specific type of string manipulation is longer in Erlang than in other languages. This is a completely isolated modular component of the whole system. It does not prevent me from understanding the important bits. I do care if the core components are bloated, but are only describing some very simple behaviour.
Depends a lot on what you are trying to write, how much fault handling code you need and the size of your program. Programming languages which are "verbose" for small programs may not necessarily be it for large complex bodies of code.
In my experience it also tend towards what you are trying to do.
The "actual numbers" are numbers for a lot of numerical code like computing pi digits, spectral norms, n-body simulation. That fact that you show those representative as typical Erlang programs shows that you don't know what typical Erlang programs are used for or just trolling. (And either one of those could result in downvoting).
I know what Erlang is used for (my name appears in the acknowledgements here: http://www.amazon.com/dp/B002L4EXHY/?tag=dedasys-20#reader_B... as a reviewer ), and the language shootout is a convenient benchmark site, nothing more. I never claimed it was anything else, did I?
Ruby isn't exactly a whiz in the number crunching department either: it's significantly slower than Erlang and certainly not 'meant for that', and yet, its code is more concise.
If you are saying Erlang is only concise for problems that it was meant for (and excels at), fair enough.
I'd also say that my preference is for languages that do lots of things pretty well rather than one thing really well and other things not so great. It's frustrating in some ways, because for some things Erlang is absolutely brilliant.
I didn't downvote you, I asked you a question. I have an opinion on the relative verbosity of Erlang, and was interested in hearing an explanation of yours.
But thanks for projecting your insecurities on me.
I second the love for code hot-swapping. That's a beautiful part of the soft-realtime OTP environment that I miss a lot. Lager also helps to mitigate the logging pain a bit.
I constantly missed Haskell's pattern matching whenever I used Erlang's. Same idea, but H-M typing and laziness make me feel less like every pattern match is a bomb that triggers on every refactoring.
Edit: Oh! And how can I forget the joy that is Erlang's binary type DSL! That thing should be everywhere regexes are.
> And how can I forget the joy that is Erlang's binary type DSL!
They're definitely awesome. Many people are weirded out when I note that bit-munging in C looks like dog vomit, and so do the Perl-inspired pack and unpack (imported by Ruby and Python)
Erlang does have binary patterns on the both of those. Of course you could put something together (I'd especially be curious to see what you could come up with in Prolog) but the go-to solutions in Haskell are binary and cereal, which lack the terse clarity. Beyond that I'd say they're pretty par, maybe a slight advantage to Haskell for the under-utilized view patterns extension.
I personally have fallen quite significantly out of favor with Erlang. There are many reasons for which I would absolutely use it---soft realtime being key---but it is an absolute bear to work with.
Erlang's reliance on spawning processes as a central abstraction conceit leads to conflating a lot of best practice OTP ceremony with your domain logic. You end up with a Service Oriented Architecture at the application level---people rarely write pure libraries, but instead bootable applications that you communicate to handle needs asynchronously. Additionally, launching processes is not as simple an interaction as beginner Erlang tutorials have you believe. Instead, there's a lot of reason to wrap in the OTP boilerplate leading you to split out things into multiple files and applications.
Dialyzer/Typer is a mess. They're crucial tools for using Erlang successfully, I believe, but they're also only mildly tied into the language and have weird, difficult to understand error messages. That said, they're really good at discovering the myriad errors you'll make passing tuples around.
There's also an enormous amount of black magic surrounding rel creation and management. Using Rebar and reverse engineering Riak I was able to figure (most of) it out. It is, as the author states, a very smart system, but it's also very difficult to get all the pieces firing together.
I would today use Erlang for creating simple, bombproof server architecture. It's a joy for doing lots of independent, network things in parallel. Mochi Media seems to be an obvious example, and I remember reading that [forgotten game name that isn't ROTMG, thanks!] is an MMO game which models every interacting player as an independent Erlang process. Those examples are both beautiful, as an infrastructure language I think it's unparalleled and begets great technology like Riak---I'm seriously itching to use Riak Core sometime. I just wouldn't want to be the guy who wrote the player logic to run one of those processes.
(Edit: to qualify, a lot of these flaws are more my own than Erlang's, but despite spending 3-4 months with it I put it in the box with C as a Right Knife for the Job kind of language)
That's interesting that you mention Realm of the Mad God. My understanding was that it was pretty standard App Engine. I just checked the traffic with Wireshark, and it's still hosted on App Engine. This job posting for developing the server codebase doesn't mention Erlang, either. http://www.gamejobhunter.com/job/2021/software-engineer-c-ka...
Not to take away from your larger point. I also enthusiastically embraced Erlang and then grew annoyed with its shortcomings. Tsung is a great load testing tool, but it appears that only myself and Yoda have the patience to actually set it up.
When did ROTMG move to Erlang? I spoke personally with one of the game's original developers at GDC before the title launched and he said the game servers were written in C++.
It is no secret that BSGO(Battlestar Galactica Online) uses erlang for the game-servers. If you were talking about some other MMO I would be very interested to know.
I definitely wanted to take a look the whole time I was using Erlang, but kept feeling like it was more important to really get a handle on Erlang/OTP before branching out. I imagine it's hard to play in the same waters as OTP's "real, tested engineering" with a new language, though I definitely support any language that targets the ERTS.
What you describe, I think, is simply one of the Stages Of Being An Erlanger. It is unfortunate that this language has that stage, as other languages don't, but giving it another 3-4 months will get you thru it.
For me, I was in that stage for the middle 3 months of the first 6 months I used erlang. Then working with other languages for a couple years and not erlang, put me back in it when I had to relearn the language.
Still, of all the languages I've learned or looked into, none of them have the key features of erlang or compare.
For instance, people talk about ruby, and I might consider ruby for something then I start thinking "ok, for this one part of my application, I'm really going to need a pool of processes... how will I do that" and realize that I really want to be in erlang.
I traded happily to Haskell where I get my category theory, my light pool of processes, my HM type checking, my functional programming. I miss OTP and soft-realtime and would go back to Erlang in a heartbeat if I needed those---I may, indeed, use it to write one of our API servers, but I just don't see using it for projects where soft-realtime and asynchronous processing isn't the central conceit.
I would, for instance, never write an embedded language or parser in Erlang, but I do it constantly in Haskell just to play around with ideas. I also think there are opportunities for other kinds of powerful parallelism in Haskell such as the Par monad or the Data-Parallel stuff. Those things would obviously be possible in Erlang, but I think not worth the trouble.
The author mentions how he thinks representing all strings as linked lists is the 'right thing to do', and later complains about the language's runtime performance. These two things should immediately seem connected to anyone who has ever heard the term 'L1 Cache', and it makes me wonder if the author has heard of it. There are in fact many runtime environments with support for representing strings as linked lists (I believe V8 and SpiderMonkey both do this) but it is never a universally correct choice. If you compose a long string out of a linked list of single character strings your performance will be miserable.
Then again, when I reached the part where he says "I actually like the fact that there are not many Erlang libraries available" I started wondering whether this entire article is a giant troll...
> The author mentions how he thinks representing all strings as linked lists is the 'right thing to do'
No. He wasn't talking about strings-as-linked-list there: list concatenation is O(N) of the first list, not O(1).
OP was talking about Erlang's iolists which are arbitrarily nested lists of binaries (~bytestrings) and strings (list of integers) which the IO port will iterate and serialize when it needs to: http://prog21.dadgum.com/70.html. Concatenating two lists (or two binaries, or a list and a binary) by creating an iolist merely requires allocating 2 cons cells, regardless of the size of the items being concatenated.
And because you misunderstood this, your whole comment falls down.
> and later complains about the language's runtime performance. These two things should immediately seem connected
They aren't and have nothing to do with one another. His complaint is about the erlang interpreter/VM being fairly slow. Because it is. Not strings being slow, the interpreter itself.
Point of information for this thread: Erlang's iolist are similar (in data structure and complexity) to Haskell's bizarrely named Difference List, which is explained a bit more here:
> "I actually like the fact that there are not many Erlang libraries available" I started wondering whether this entire article is a giant troll...
It's an opinion piece. It is a disadvantage that helped him learn the language better. But he also let you know about it. So if you are into writing your own libraries for some things, it is not the language for you.
In the same vein I could say the different than C syntax is an advantage as well. It tells my brain to shift gears and stop writing C/Java/C#/C++ code and start thinking in terms of processes and patterns. Is that a trolling comment? If you feel so go ahead and click the down arrow.
> The author mentions how he thinks representing all strings as linked lists is the 'right thing to do
I think the author just likes that the runtime for string concatenation is fast; not sure why he ignores the fact that you'd need to chase pointers for every other string op.
He then goes on to talk about openCL and how he can use his erlang code to use the benefits of the openCL compiler, but of the 25 years of using this language, he's only had this benefit for a couple of years.
Remember that Erlang is a functional language with a persistent heap. You often create your concatenation only once and if you need to process strings, you process your strings in another, symbolic, representation.
Thus the raw string-processing speed isn't important in usual programs. The iolist() primitive is there to make it fast to just gather up data that has to go over a socket and essentially writev() it to the socket (guess what happens internally in the VM...)
So it is usually not the case you pay the pointer chasing in typical Erlang programs.
Then again, when I reached the part where he says "I actually like the fact that there are not many Erlang libraries available" I started wondering whether this entire article is a giant troll...
Why? I wouldn't think like that, but I do think he explains it well
There is a great explanation of IO lists in Learn You Some Erlang [1], but in short — an IO list is functionally equivalent to a string builder, allowing you to accumulate individual strings in O(1) time.
This is one of the most nuanced and gentle pieces of language advocacy I've seen. We should all be so calm and forthright about our language's shortcomings.
I thought it was a good bit of propaganda combined with lack of understanding of other languages and failing to give the whole story. I say that has a long time Erlang developer.
"Whenever I've wondered about how something in Erlang works, I have never disappointed in the answer. I almost always leave with the impression that the designers did the “right thing.” I suppose this is in contrast to Java, which does the pedantic thing, Perl, which does the kludgy thing, Ruby, which has two independent implementations of the wrong thing, and C, which doesn't do anything."
I like Erlang, but the lack of libraries to me just means more things that other people have already done (for other languages) that I may have to do myself, rather than taking those pieces, and putting them together to accomplish something unique and interesting in the real world. I can appreciate the fun involved in hacking on something for the sheer joy of writing new and (hopefully) beautiful code, but the business side of my personality that I am trying to cultivate wants to get shit done, not write yet another whatever.
I do like the language, just that it's ... something like a high power chainsaw rather than a swiss army knife. It does what it does really well, but cutting the steak you cooked for dinner with it would probably result in a big mess.
Man, are you serious when you said that "The result is that concatenating two strings takes O(1) time in Erlang, compared O(N) time in other languages"? Yes, you are right that Erlang represents strings with lists, and that's the VERY reason that Erlang must take O(N) time to concatenate two strings (N is the length of the first string).
Just check your /usr/lib/erlang/lib/stdlib-xxx/src/string.erl, and you'll find this:
concat(S1, S2) -> S1 ++ S2.
and "++" is obviously a O(N) operator.
But yes, string concatenation is somewhat faster than other languages that represent strings with arrays of characters. Because in Erlang, it's O(N), while in others it's O(N+M), where N is the length of the first string and M is the length of the second.
Right. This is like the POSIX features writev() and 'struct iovec'. Essentially all of Erlang's binary output primitives are happy to take an iolist/iovec instead of a plain string and this means fewer concatenations and/or system calls. Good feature.
He's talking about iolists (concatenating strings for IO, which is the most common use case and the one needed for e.g. templates), not straight strings.
> the only truly bad news about Erlang is that it is slow. For the server applications I have written, the speed of the language has not been an issue;
Speed is usually at odds with scalability and fault tolerance. The machinery that aids both of those things (isolation, sending messages, breaking things into communicating processes) will take way some from speed.
In the end it is just a trade-off in this particular tool.
If you're interested in getting all the benefits of the Erlang VM and OTP, but very little of the bad, please check out Elixir (http://elixir-lang.org/).
It's staggering how fun and easy it is to code in Elixir while leveraging the Erlang platform.
That's quite debatable, ",", ";" and "." definitely have a logic about them but I wouldn't use "consistent" to describe them. fn/named functions is rather similar (the syntaxes are rather different).
But the syntax is rather small (if noisy and with more keywords than you'd expect), which is good. Still, it's no Smalltalk.
It's funny, because I was thinking exactly about ';', ',' and '.' when writing about consistency. ';' separates clauses - in functions, 'case', 'if' and 'receive' alike. ',' separates expressions - everywhere. And '.' ends definitions. I find this consistent, but - this being syntax - it's purely subjective, so it's not like I'm disagreeing with you - I just like it the way it is.
It's not Smalltalk with it's six (IIRC) syntax constructs nor is it Lisp, but compared to the syntax of C++ or other rather baroque syntaxes it is simple :)
I agree, besides ruby based syntax (which I don't consider a plus over Erlangs) you get pseudo mutable variables (they are not really but mimic them with a invisible sequence of Erlang like variables). The style that needs this ended up having variables like R1, R2, R2 ... in functions for sequences of operations. Its only it doesn't occur if you write in Erlang style. It might ease the transition for Ruby programmers but it is the second approach already to have Ruby syntax on the Erlang VM. The first one was abandoned probably because nobody used it. We'll see where this one will be going, its pretty young still.
>Erlang does not use a contiguous chunk of memory to represent a sequence of bytes. Instead, it represents a sequence of bytes as nested lists of non-contiguous chunks of memory. The result is that concatenating two strings takes O(1) time in Erlang, compared O(N) time in other languages.
I've often wondered if this was being used anywhere. It seems like such an easy win, but now I'm curious if it would causes problems with cache misses or something.
Other commenters have noted that writev(2) is quite similar (although from reading the man page, it does not seem you can put iovecs inside an iovec, so there's only one level of nesting)
Warning: I'm not usually overly critical on articles: but this one I can only think is a little bit of flame bait - a little bit of truth from various languages turned into fact?
* String concatenation: blatant misinformation. The only reason the default implementation of Strings is slow is because they're made immutable for a reason. This if for speed and predicability - if you're wanting to build a String then funnily enough: use a String Builder.
* Garbage collection: rubbish. It can run on it's own thread (which can ultimately run on it's own processor). In languages such as Java and .NET the garbage collector has been written so that it collects only what is disposed. Of course you need to be careful about the number of objects your "disposing" (too many can cause the processor to be collecting more than running) but the same is with any language: Erlang included.
* Refactoring... seriously? What happened to compilation errors? Isn't it worse if the structure sends less at runtime?
* Data Structures - I'm not sure what he's worked with before, but modern languages allow the transparency he mentions. He mentions "easy to manipulate undocumented data structures" - of course he is asking for trouble there. There are ways around this in OO languages, and worst come worst: roll your own. Don't mess with the internals where you need to "worry about the original author renaming variables ".
I seriously doubt the authors experience in the languages he mentions. Even so, I doubt his understanding...
He was talking about iolists, and he's perfectly correct: an iolist is O(number of strings to concatenate), you need a single cons cell per element to concatenate regardless of their size.
> Garbage collection: rubbish. It can run on it's own thread
That adds an enormous amount of complexity to the GC in your generic unsafe language (java, go, C#, python, what have you), and requires hugely extensive work on it.
> Of course you need to be careful about the number of objects your "disposing"
You completely missed the point, which is that through the VMs design as a set of heaps (per process) with very little shared memory from Erlang's fairly simple m&s GC emerges a highly concurrent garbage collector. Not only that, but short-lived process can be tuned to never trigger a GC pass on their own heap. Java's concurrent GC strategies are still hit-or-miss and a dark art.
PS: and yes, if you put everything in the same erlang process, the GC completely breaks down to a pretty shitty M&S.
> * Refactoring... seriously? What happened to compilation errors?
I have no idea what you're trying to say here.
> Data Structures - I'm not sure what he's worked with before, but modern languages allow the transparency he mentions.
He listed them, was it really so hard to actually read the post?
Let me add: The key point of the GC per process is that when heaps are small, pause times are also small. And since GC is counted against a process reductions frequently GCing processes get swapped out all the time and will not hurt the latency of other processes.
Actually, the Clojure world has a good critique against using objects when datastructures are generally better. Rich Hickey has all sorts of talks where he explains why datastructures beat objects. One reason is that datastructures let you write more generic code, and you have all sorts of powers which the original author didn't need to plan in advance. For example, you can use any operators which operate on mapping types. And anything built on top of those operators, like set operations over tuples.
(Disclaimer: I've written only one service in Erlang, without OTP, so I can't evaluate all the claims.)
"in this way, the performance penalty of garbage collection is amortized, and so a long-running application will not mysteriously stop responding from time to time while the garbage collector runs."
I think he meant to say un-amortized? Usually amortization in algorithms means that we gather up lots of little chunks of work into one big chunk of work. Here he means that the GC does the exact opposite.
It also means 'gradually reduce a liability in small increments', which I would assume is how he is using it here. Although, that usage is generally used in reference to finance.
Five9 recently hired Eric Merritt in an effort to take the entire platform and redesign it using erlang. They are also hiring a lot of Erlang Engineers in prep for the transition. Hopefully this means the platform will be much more stable.
Like Riak you mean? Is that pun or valid criticism.
I think Riak is a very successful product with features (distribution, simplicity, fault tolerance and scalability) that few (if any) others can match.
Erlang is slow, if your problem has a certain structure. Your problem must be CPU bound. And constant factors must matter. In almost all other cases it is more capable than most other systems. And the Erlang solution to CPU bound problems is to punt it to a separate program built for that purpose. Ericsson has done this for years by pushing CPU bound things into hardware because C is too slow for what they are doing.
Erlang does, however, target latency over throughput. This means that to the Erlang system, it is more important to provide low latency than to provide high throughput. Usually it is very fast, but this choice can in certain situations hurt throughput.
The primary reason that Erlang is targeting a JITed VM right now is that it will make it possible to write more of the Erlang VM in Erlang itself, rather than C. This in effect means that Erlang will be easier to port, so that is a very good thing.
In my experience, larger systems run extremely fast in Erlang. This is due to faster development cycles and that you don't have the luxury of optimizing your C code in larger projects.
It is fallacious to pretend erlang is slow because otherwise you have to write bad, unoptimized C code. First of all, unoptimized C is still an order of magnitude faster than erlang (or more!). Second, there are other languages besides just erlang and C. For example, compared to erlang I can write the same thing in haskell instead, have it written faster, have fewer bugs make their way into production, and have it run faster.
If your C code is doing linear scans over arrays where a dictionary style lookup is really needed, then there is no way in hell the C code is going to beat the Erlang code. I've seen this again and again in C programs.
As for your Haskell program, you are right. But you will spend the next 3 months trying to fix memory leaks due to lazy evaluation :)
I think the bottom line, one we can agree on, is that a program written is not the end of development. It needs maintenance and where certain programming languages makes it easy to do something, other languages have a harder fare, and vice versa.
Erlang has a state-of-the-art interpreter. And a runtime written in C. It is not a slow language if you have a program that spends most of its time waiting for other things to complete or in the runtime. In fact, that is where it shines.
That said, don't write CPU-bound jobs where constant factors matter in Erlang. It is a bad fit for this, because of its interpretation overhead.
So now we're not just comparing optimized erlang to unoptimized C, but optimized erlang doing X to unoptimized C doing Y. You can write the wrong code in erlang too, C does not have any special (mis)features that encourage doing the wrong thing. It dishonest to say "erlang isn't slow" and use "I can write slower C code if I do it on purpose" as evidence.
The thing is that "slow" is naturally relative. I hate it when people claim that a tool is slow. By far the most important factor in getting programs that work isn't the technology but the mind behind the code. This is true for any programming language.
I guess the succinct answer is: No, Erlang isn't slow if you know what you are doing, barring the Caveat about CPU-bound problems. The message I am trying to convey is that there is more to fast programs than the execution speed of the technology at hand. It is a factor, admittedly, but it is not the sole factor.
Logging is..... strange. The recommendation is to use SASL, which writes your logs in a binary format that only another erlang library can properly read. SASL has some nice features, like auto-rotation and such, but I'd much rather have my logs get spit out in plaintext and just logrotate like I do with everything else. One of these days I'm going to write a proper erlang logger.
Rebar is strange. It's erlang's deployment tool thing, kind of like leinengen but much less intuitive. I tried getting used to it but found it just made testing more difficult and made setup a chore. I opted instead to just steal the makefiles from the mochiweb project and call it a day.
Records have easily the most annoying syntax of any language construct I've ever used. And god forbid you want nested records, have fun with your full solid line of selection syntax. Bleh.
Which isn't to say it's all bad, here's some other awesome things about erlang that I don't see pointed out often:
Polymorphic anonymous functions
The pattern matching is amazing. When I go back to other languages that claim to support pattern matching it feels like I've lost both your feet and replaced them with suction cups. There's no pattern matching like erlang pattern matching.
Hot-swapping of code. Somewhat unintuitive, and has weird behavior in certain cases, but still definitely better then restarting the server that thousands of clients have long-running connections on
Records. Their syntax is horrible, but their usefulness is infinite. They're basically just syntactic sugar on top of tuples that make them easier to manage and extend.
There's more for both sides, but I'll leave it at that. It's a great language, I highly recommend everyone take a stab at it. Even if you hate the syntax it's good exposure to thinking about how to code concurrently.