Backstory: I spent a great deal of time writing and extending a thread-safe, fault-tolerant enterprise framework for my current employer. The lead architect designed something of beauty, and it has been a real joy to work with it every day for the past two years. End of backstory.
When I started toying with Erlang as a side endeavor, I was instantly surprised to find it did almost exactly what we built… Except Erlang beat us to the punch by many years and, admittedly, Erlang did it better. For one thing, shared memory concurrency is flat-out broken, even in languages that make it “easy,” like C#. Sure it’s possible to make shared memory concurrency work, work correctly and it’s (generally) VERY fast… But it can be too difficult to introduce new developers to shared memory concepts… It’s difficult to debug and it’s generally very hard to get “right.” Erlang, by comparison, uses message passing concurrency… And it’s awesomazing to work with if you’re used to locking/unlocking your shared resources and spending three days trying to figure out why something deadlocked in production a year after your wrote it ’cause you never noticed the problem during the development process…
But I digress.
Erlang is a language and runtime environment that — right out of the box — supports concurrent, distributed, fault tolerant applications, including hot code swapping, a complete database system (Mnesia) and a very robust underlying framework called OTP (for the Open Telecom Platform, but it’s so general it can be used in other spaces besides telecommunication).
Looking at Erlang as just another language is incorrect, though. It’s really a runtime environment, language and framework (and it’s HUGE!): It has less in common with C++/STL or C#/.NET than it has commonalities with bash or the Windows CLI with a full-blown concurrent language built in (yes, I realize bash and the CLI both have built in languages!). In other words, you launch instances of erl, the Erlang command line interpreter and issue commands or run programs directly through it. It may sound like a pain, but in practice it’s quite nice: You can watch your running application receive and process messages, issue commands directly to your application, even (re)build your application in a separate terminal window and watch the Erlang environment instantly pick up the new code. No starting/stopping required in most cases.
The problem with Erlang is getting started. There aren’t generally a lot of resources for new Erlang developers, and what does exist is often complicated or geared toward experienced functional or Erlang programmers. So I’m hoping that — as I learn Erlang — I can impart a little bit of wisdom to you, if you’re interested. This is just the first of several planned Erlang tutorials and goodies, and I hope you enjoy ‘em!
