A pretty decent definition of bound vs. unbound variable. A very good Erlang book is at http://learnyousomeerlang.com/; the author of the book hangs around at #erlang@freenode and overall, he's a great guy who helps folks with problems in Erlang.

On that note, Erlang is a powerful functional language with the following features:

• Shared-nothing memory architecture - we don't have to worry about resource locking scheme (deadlock/livelock) since nothing is shared. If you need to name a variable twice use a different variable name.
  
• Asynchronous message-passing - means decent performance on multiple cores within an Erlang cluster and worry free variables (they don't need supervisory locks to monitor their state because again it's not shared! :)
  
• Functional language properties - A high-order function for control abstractions, anonymous functions and lambda expressions(in spirit of Python)
  
• OTP and libraries - Running network applications with about 10 lines of server code and about 6 lines of client code is awesome. I've never seen something like it honestly; Or what about full-on binary IP packet matching (what some folks call packet sniffing) in less than 10 lines?
  
• Full-on Exception model - try/catch/throw semantics (like Java)
  
• Hot-swappable code on live systems - That code path shouldn't excecute after these conditions are met. Instead load a new set of code that I am updating right-now (say a new set of beam files).
  
• Mnesia - Database for Erlang. It was actually called "Amnesia" but Joe's boss at the time in Ericsson didn't particularly like a database name that forgets things so they renamed it.
  
• Networking - It's convenient to write BSD-style socket apps in Erlang.

During my university days, I did a bit of Prolog and Lisp too, so i've found that it fits really well with my mental model especially the concept of head and tail while running pattern matching on an function argument classic. It's like saying - "oh well, i did that at school but i almost completely forgot. Why didn't I think of that before?". About a year ago, an Erlang programmer said to me something like this on the #erlang@freenode - "You know you've found Erlang at an early age, you're lucky!". I think I somewhat know why now. I have yet to learn the "fault-tolerant" part of it as I am still going through the book but surely in due time I'll have figured out this as well.

Joe Amstrong's example on Concurrency from the Erlang book is:

We don't have shared memory. I have my memory. You have yours. We have two brains, one each. They are not joined together. To change your memory, I send you a message: I talk, or I wave my arms. You liten, you see, and your memory changes; However, without asking you a question or observing your response, I do not know that you have received my message.

I think Joe is proving more right. Erlang is coming up quickly as the top 20 programming language on TIOBE list and the reasons are pretty clear - we can not just keep adding more hardware and expect a sane performance with concurrency and management. Even with that hindsight in mind, not all the programming languages support running code on multiple cores. Python has trouble with threads deep within it's core - the GIL or the Global Intepreter Lock and I think Ruby even resorts to native threads (oh no!). Contrast that with Erlang - a nice set of green thread that run on VM (like Java). You want 1,000,000 threads? No problem. How about 2,000,000 threads? Yep no problem either! I am not an SQL guru but it seems a lot could be weilded if Erlang was met with NoSQL. I have no experience whatsoever in that department so i'll leave it upto fellow readers of this post.