Ask HN: What have you built with Erlang?

This was a few years ago, so my memory is foggy and things might have changed, but I remember how uncomfortable erlang felt in a unix environment. I might have felt the same way about java, since its also sandboxy.

I think the first time I hit the mailing list was because I couldn't figure out how erlang can boot up and change its effective user id. (setuid). The reason being it needs to grab a privleged port as root. Well forget that, it has no idea what that means. The recommended way is to use iptables port forwarding. I think thats how couchdb does it (or one of those nosql things)

Logging also didn't seem to fit well with linux. You can manage to write some stuff to syslog, but erlang really prefers its confusing way of logging. See things like this http://www.erlang.org/doc/man/sasl_app.html.

Oh and if you decide to just write data to the error log in the simpliest way possible, like this error_logger:error_msg("An error occurred in ~p~n", [a_module]). Guess what, it doesn't open that log file in append mode, so it wipes it out every time you restart the erlang process. You have to write and install your own error log handler to open the file in append mode.

Want to do some dns lookups? Sounds simple. It starts up a gen_server thread... and starts caching the results! Talk about principle of most surprise. And it doesn't handle mx records. But if you get on the mailing list the guys will tell you there's an undocumented library deep in the distro that will handle this, and probably won't change. So you give up in frustration and just write a port to run dig.

It just went on and on.

You can really tell that erlang evolved to run self sufficient on special hardware and not in a supportive unix environment.

And of course there are the basic language frustrations. What bothered me the most was simply the lack of a 'return'. This meant you couldn't 'short circuit' a function, like "if something then return", and it often resulted in another level of nesting, even for the simpliest stuff. Yes I know that sometimes you could use function pattern matching to factor this out, but not as much as you hope. Having a 'return' statement in erlang is part of a religious war, which I'm not going to fight, but I'm strongly on the having side.

I found some erlang things worked great for my project, like the server and finite state machine 'behaviors', but when I realized the string processing was so slow I just switched to stackless python, wrote it in a fraction of the time, never used it, and ended up keeping the existing perl version :)

You can write a MTA in any language, so its probably not the best fit for erlang. The best fit for erlang would be something that only erlang could do, and just suffer through it ;-)

- a key-value stored modeled caching system that can run functions during set/get, have expiry, counters, counters that wait for N as a buffer before running transactions, and machine learning - all as primitives. the tail-recursive processes acting as mini-servers holding state and the best thing is that you have a mini-automatic scaling if you combine this well with expiring of processes. increase load when there's a need. they die when there's no more need/lesser traffic.

- a distributer crawler that works with python. from a typical rdbms approach that brought down creating inverted index's from more than an hour to few seconds. the euroka moment was when we stopped porting/writing for another language, sequentially, for-loop style approach to a more - processes and message passing. big 'why didnt i do this moment' a few years ago!

- a website , dashboard for the ad/content network using yaws on the LYME stack

- and btw - all that rumour about unicode is just bs. actually it was a blessing for us that content aka strings are just integers which when converted to binaries not only takes less space, pattern matches like a dream but all of a sudden your sytem can handle any language because to it - it's all just integers, english or swahili. that was a huge bonus even when getting investors, new untapped market opp's.

- an ad network, ( content network i guess without saying)

- a fire-and-froget thumbnail/screenshot system with queues & talking to imagemagick . i love writing and fire-and-forget tools, and with erlang, its so darn easy to write proceses's that have a life of their own. sure at some point you need to compromise on erlang's unique ability to handle RAM vs giving that up to research on how to handle large mnesia tables ( mnesia = inbuild db that has a limit on size of tables) . but it's worth the tradeoff.

case in point - our idea of scaling was...'reducing nodes' ie increasing efficiency

-2008 a million hovers in the year, 4 nodes

-2009 a million hovers every month, 3 nodes

-2010 a million hovers every week, 2 nodes i could bring it down to 1 node for doing the tasks as well, on just one 1 8gb RAM node.

the idea of reducing your costs, means that much lesser to profitability. ( we're now profitable, pretty much on auto-pilot on the backend, the 3-4 member team concentrating on increasing toplines,sales now )

in addition... - a wrapper to iui for nitrogen framework for building iphone webapps easily - wrappers to tokyocabinet ive contributed to called medici - remember writing wrappers to other things like rrd, aws utils, etc

all of the above have been used at hover.in, more at http://slideshare.net/bosky101

there's nothing i can think of that i wont/cant do in erlang anymore.

~B @hoverin

ErlyDTL, a Django Template Language compiler: http://github.com/evanmiller/erlydtl

Chicago Boss, an MVC web framework in progress: http://github.com/evanmiller/ChicagoBoss

This doesn't get mentioned enough, but Erlang has excellent compiler tools, so if you're willing to roll up your sleeves, you can usually hack the language to fit your problem. For instance, Chicago Boss ships with a nice but completely non-standard database querying syntax, described here:

http://www.chicagoboss.org/api-db.html

You will weep for joy when you rewrite a gnarly SQL query with a few well-chosen Unicode set operators.

The compiler tools also make it easy to generate Erlang AST and compile it to BEAM (Erlang bytecode). That's how ErlyDTL works. I haven't done performance benchmarks myself, but the folks at Zotonic report that their Django templates and controller code come out 10X faster than comparable PHP code.

I think a couple of things prevent Erlang from being a do-all language:

1. Lack of libraries. The situation has been steadily improving, but Erlang's VM and processing model makes it difficult to draw upon the "C tradition" in the same way that Perl, Ruby, and the others can take a popular C library and write a thin wrapper around it.

2. Inferior OS integration, at least with UNIX. For instance, custom signal-handling facilities are non-existent, and you have to jump through strange hoops to do simple stuff like close only the write end of a read-write pipe, or get the exit code of an exec'd process. Weak sauce for anyone who has spent a lot of time with Perl, Ruby, or C.

- we wrote the backend of http://bidit.eu in Erlang (front end in Rails) - we're writing the backend for a TV co-viewing chat application for the iPad in Erlang right now - we're rolling out a new Nitrogen-powered website for Inaka Networks this weekend