Why I Program in Erlang

http://www.evanmiller.org/why-i-program-in-erlang.html

by tel • 14 years ago

215 92 14 years ago

tel5• 14 years ago

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)

rdw• 14 years ago

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.

tel5• 14 years ago

It must not have been Realm of the Mad God, whoops! I'll edit the above.

kevingadd2• 14 years ago

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

devinus3• 14 years ago

I highly recommend you check out Elixir (http://elixir-lang.org/). We also now have Relex (https://github.com/yrashk/relex) which makes making releases a breeze.

tel5• 14 years ago

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.

peerst3• 14 years ago

I can understand you need users desperately ... but are you going to fill every erlang thread here with elixir spam?

beemoe• 14 years ago

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.

nirvana• 14 years ago

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.

tel5• 14 years ago

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.

mediocregopher• 14 years ago

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.

codewright2• 14 years ago

>There's no pattern matching like erlang pattern matching

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.

fusiongyro3• 14 years ago

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.

tel5• 14 years ago

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.

masklinn7• 14 years ago

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

tikhonj• 14 years ago

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

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

paul-woolcock• 14 years ago

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/`.

devinus3• 14 years ago

I'll also recommend you check out Elixir (http://elixir-lang.org/).

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.

ismarc• 14 years ago

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.

hjalle• 14 years ago

You can perhaps check out https://github.com/basho/lager when it comes to logging.

timClicks• 14 years ago

Would say that Lager is the preferred approach to Erlang logging at the moment: https://github.com/basho/lager

yfyf2• 14 years ago

> 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!

[1] https://github.com/basho [2]: https://github.com/extend

davidw5• 14 years ago

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

Pkger• 14 years ago

> 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!

We're hiring [1]!

[1] http://bashojobs.theresumator.com/

fusiongyro3• 14 years ago

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.

sausagefeet• 14 years ago

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.

fusiongyro3• 14 years ago

Be constructive. Elucidate. I have some experience with Erlang and quite a bit with many other languages. I'd be curious to hear your side.

paupino_masano• 14 years ago

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

calibraxis• 14 years ago

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

masklinn7• 14 years ago

> * String concatenation: blatant misinformation.

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?

jlouis9• 14 years ago

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.

nagiek• 14 years ago

When he talks about about functional vs. OO-programming, it reminds me of why I like Drupal.

kevingadd2• 14 years ago

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

SenorWilson• 14 years ago

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

Sounds wacky to me.

jlouis9• 14 years ago

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.

masklinn7• 14 years ago

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

lurker14• 14 years ago

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:

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.

gizzlon• 14 years ago

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

rdtsc4• 14 years ago

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

mietek• 14 years ago

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.

[1] http://learnyousomeerlang.com/buckets-of-sockets

liancheng• 14 years ago

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.

defun• 14 years ago

I guess what he was meaning is that in Erlang in most cases you can work with strings as iolists.

Maybe here you can find a bit better explanation: http://erlang.org/pipermail/erlang-questions/2012-May/066590...

lukego• 14 years ago

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.

masklinn7• 14 years ago

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.

klibertp4• 14 years ago

I wonder how many times that's need to be said until it sinks in? This is the third time and I didn't even go through half of comments yet...

devinus3• 14 years ago

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.

klibertp4• 14 years ago

But, but... I actually LIKE the syntax of Erlang. It's neat. Consistent. Very simple. And it's modifiable with parse transformations.

Does Elixir give you anything other than ruby-inspired syntax?

masklinn7• 14 years ago

> It's neat. Consistent.

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.

peerst3• 14 years ago

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.

maaku• 14 years ago

For those who don't know, Evan Miller is the author of Chicago Boss, a Rails-like web framework for Erlang:

http://www.chicagoboss.org/

trustfundbaby• 14 years ago

money quote

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

p0nce• 14 years ago

Erlang looks great, but if it's slow is it still a general purpose language?

jlouis9• 14 years ago

It is not slow. This is a common misconception.

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.

papsosouid3• 14 years ago

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.

dschiptsov• 14 years ago

Talking about Erlang without reading Armstrong's thesis is stupid.

Talking about Erlang after reading the thesis is useless.)

http://www.erlang.org/download/armstrong_thesis_2003.pdf

contr-error• 14 years ago

Do you mean that this thesis is the definitive introduction to Erlang or that it demonstrates a key problem?

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?

davidw5• 14 years ago

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.

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.

Peaker• 14 years ago

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

jlouis9• 14 years ago

You are correct, Sir.

michael_h• 14 years ago

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.

nivertech3• 14 years ago

We built a Distributed Realtime Video and Image Processing Middleware for Blade and GPU clusters using Erlang/OTP and OpenCL.

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.

rdtsc4• 14 years ago

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

jpro• 14 years ago

Just don't write a database in Erlang.

rdtsc4• 14 years ago

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.

jeremiep• 14 years ago

CouchDB seems to disagree.

codewright2• 14 years ago

More and more of CouchDB gets converted from Erlang to C++ every year since its creation.

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"

jere• 14 years ago

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

masklinn7• 14 years ago

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)

noselasd• 14 years ago

This approach is used by Scala with its immutable vector, and many other functional languages have a similar thing.

pla3rhat3r• 14 years ago

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.

Why I Program in Erlang

Related Stories