Small Erlang: An answer looking for a problem

June 18, 2013 6:11 AM

What are some practical, small (meaning not necessarily enterprise scale) uses for Erlang?

I've been reading about Erlang lately, and I find it very interesting, and it makes me think fondly of coding in Scheme and Lisp in college (perhaps with a bit of rose-tinting). The immutable variables aspect is especially weird and fascinating.

I want to get into this, but I have to be really careful with my time these days. I don't want to invest time in something I'm not going to use.

I work mostly with JavaScript, Node.js, Meteor, the browser, and Objective-C on web and iOS apps. They are games and "personal productivity"-type apps. I figure I can handle any scaling issues these kinds of things may encounter with the tools that Node provides.

Erlang seems to be mostly applied to massive scaling problems on the server side. While that's cool, I'd like to know how it works in smaller personal projects, generally. Answers like, "no, it's just useful for massive high-traffic and quant problems" are fine.

posted by ignignokt to Technology (5 answers total)

We used to use Erlang Tables to determine how many phone lines a business had. We'd go for a P.01 grade of service on that. So about 10% of calls at the busiest time of day would either get a busy signal or wouldn't complete. We NEVER had complaints.

Another application is how many toilets does a venue need?

It's interesting, but not really applicable to your question of learning the language. But that's the concept on a small scale.
posted by Ruthless Bunny at 6:18 AM on June 18, 2013

Wings 3D, an open-source 3D modeller, is written in Erlang.
posted by rlk at 8:15 AM on June 18, 2013

Erlang is not much fun at the low end of the scale, where you don't care as much about reliability, latency, concurrency, or maintainability. It doesn't even have a decent native hash table implementation yet, so it can be pretty bewildering if you come from the scripting side.

That said, learning any functional language is a good idea. Learning erlang in particular is excellent because it exposes you to the hard, pragmatic, engineering-based world and shows you battle- and time- tested solutions to many of the problems you didn't know you even had.

From where you are I would suggest you pick up ruby -- not necessarily Rails, but ruby as a first class language that has some functional elements. From there, either look into erlang or clojure or haskell. Ruby is like a nonhacky, partially functional javascript; it's a good stepping stone before you start getting into the lisp families more seriously.
posted by felix at 11:02 AM on June 18, 2013

Chef is a configuration management engine. Originally written in Ruby, they rewrite the core API server in erlang. So, I deploy some erlang just to manager servers and desktops. But the motivation to makde it depend on erlang was Hosted Chef, their massive chef server that many users outsource to. So performance is part of the bottom line.

The problem with erlang for personal projects is that it while purely funtional languages are easier to make concurrent, they're harder than normal to write (compared with standard imperative languages). So your personal project would gain none of the high scale benefits, and all of the pain.
posted by pwnguin at 7:27 PM on June 18, 2013

Best answer: I've done a couple of web apps using Nitrogen, a web framework for Erlang. It leverages Erlang's actor model to very good effect for implementing COMET stuff. It's a bit of a frontier though -- I submitted a couple of patches to the Nitrogen developers while working on my stuff. IMO, it's easier to use than Node.js due to its functional paradigm, and the fact that you can use any and all of OTP in your backend, but then again I am primarily a Haskell developer.

Erlang's Mnesia/erts databases are fun to use and very easy to get up and running, with some cool features thrown in (replication). You also get extensive logging and online debugging "for free". These are pretty nice features for doing little web apps. In general, if when designing my app, the backend seems to fit into the actor model, I go ahead and code it in Erlang. (Haskell is slowly catching up in this regard, but Erlang is still #1 for providing a great actor-model implementation right out of the box.) It's easy to tack on a front-end using Nitrogen, or write the front-end in some other language entirely, since Erlang provides numerous easy ways of talking to other programs.

Other stuff I've done in Erlang includes a web-IRC gateway, an IRC bot, a couple of online board games, and a pharmaceutical app optimized for mobile devices. All of these were "small" projects in the sense that no massive concurrency was going on, but the actor model was a nice fit for the problems at hand.
posted by Maximian at 6:53 PM on June 27, 2013