Why I Program in Erlang
evanmiller.org
evanmiller.org
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.
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.
[1]: http://bondi.it.uts.edu.au/
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.
[2]: http://www.springer.com/computer/theoretical+computer+scienc...
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!
[1]: https://github.com/basho [2]: https://github.com/extend
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.
In my experience it also tend towards what you are trying to do.
Here are actual numbers:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
Downvoting, by the way, won't change the numbers or the relative verbosity of Erlang, even if it makes you feel better.
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.
But thanks for projecting your insecurities on me.
We're hiring [1]!
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.
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)
Really? I'd imagine Haskell's is even better being lazy.
Not to mention the sort of things Prolog is capable of.
Thinking about making a game recently, current choice for backend will probably end up being Clojure or Erlang.
We have mix (http://elixir-lang.org/getting_started/mix.html) that is very much inspired by leiningen.
If you like records, we have dynamic records with pattern matching and now exrecord (https://github.com/yrashk/exrecord) for record upgrades.
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)
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.
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 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.
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...
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.
http://hackage.haskell.org/packages/archive/dlist/0.4.1/doc/...
It's basically a tree, which is efficient (amortized O(1) per element) for many list appends followed by one iteration.
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.
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.
Sounds wacky to me.
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.
Why? I wouldn't think like that, but I do think he explains it well
"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."
Talking about Erlang after reading the thesis is useless.)
In the Adder() example on page 56, is the final line a typo (Adder(10). resulting in 15)? Should it have been Adder10(10). resulting in 20?
Also, this is a decent Erlang rant:
http://www.unlimitednovelty.com/2011/07/trouble-with-erlang-...
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.
Deleted comment
You can see the demos here:
http://youtube.com/clastrsystems
Unfortunately this is not a large enough market for a startup company.
We building a new exciting product using the same technologies.
Just check your /usr/lib/erlang/lib/stdlib-xxx/src/string.erl, and you'll find this:
concat(S1, S2) -> S1 ++ S2.
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.
Maybe here you can find a bit better explanation: http://erlang.org/pipermail/erlang-questions/2012-May/066590...
Also spec says that it will return list of either strings or binaries, not exactly iolist.
It's a proper subset of iolists, since it reads from flat data (a file) there isn't much sense in its adding arbitrary amounts of nesting to it.
writev() is hard to grasp.
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.
It's staggering how fun and easy it is to code in Elixir while leveraging the Erlang platform.
Does Elixir give you anything other than ruby-inspired syntax?
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 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'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.
* 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?
(Disclaimer: I've written only one service in Erlang, without OTP, so I can't evaluate all the claims.)
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.
I think Riak is a very successful product with features (distribution, simplicity, fault tolerance and scalability) that few (if any) others can match.
The core runtime and data structures are in C++. At this point, Erlang is mostly the negotiator between the nodes.
This schism in implementation is partly why I hated CouchDB back in the day. That and the fact that it's a data Roach Motel.
"Data goes in but never comes out"
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.
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.
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.
Even JITed(or just compiled to native code) erlang? I'm really curious.