Erlang has the steepest learning curve of any programming language I've ever studied and Frank Hebert does an excellent job of grading that curve to the point where mere mortals can walk upwards. I'm tremendously grateful for all the work he's put into his books if you're going to spend time on Erlang start with 'Learn you some Erlang' and work your way into the libraries from there.
OTP makes good sense to me because I built something along the same lines (in C, blasphemy) two years ago.
Erlang the language has me tearing my hair out on occasion. That's not Erlangs fault, it's clearly mine, I grew up with 'BASIC' and moved on Assembler and from there to 'C' and a whole bunch of other imperative languages besides so functional languages are always harder for me to learn.
That said I'm making good progress and Freds book was instrumental in that.
Have you tried learning Prolog sometime? From experience: after a week or two with Prolog jumping back to Erlang was such a joy and relief that I picked it up very quickly :)
Well, it's not that bad - the side-effect from learning Prolog is knowing a bit of Prolog, which is definitely much more useful than being hurt in the foot...
No, seriously: Erlang shares some features with Prolog and learning Prolog lets you learn those features in isolation, without unnecessary distractions (like, say, processes and sending messages, or gen_server/gen_fsm/supervisors or rebar, applications, releases...). For example "=" not being an assignment, and pattern matching in general, starts making a lot of sense. Looping via tail-recursion (only), single assignment variables, and even some of Erlang syntax stops seeming intimidating quickly.
I think the best metaphor for this would be learning to swim via jumping into a deep water, nearly drowning but learning the most important parts (like don't try to breathe underwater) and then going to shallow water to leisurely practice swimming there. It's certainly not for everyone, but for me it sped up the Erlang learning process by many weeks, if not months. (And also, I learned a bit of Prolog along the way.)
If you're a driver then you know that steep curves are taken slowly. (Unless you're going downhill, and in that case it's probably a sign that your brakes have failed...)
The term is often used in common English with the meaning of a difficult initial learning process. Nevertheless, the Oxford English Dictionary, The American Heritage Dictionary of the English Language, and Merriam-Webster’s Collegiate Dictionary define a learning curve as the rate at which skill is acquired, so a steep increase would mean a quick increment of skill.
Arguably, the common English use is due to metaphorical interpretation of the curve as a hill to climb.
Ok, so let me make it graphical for you: If the 'Y' axis of the graph is expenditure of energy or time and the 'X' axis is progress in understanding then a steep curve indicates a lot of expenditure for relatively little progress.
That's the 'informal use', as in, everyday communications such as, but not limited to comments in online communities.
This is the Missing Advanced Manual. Another great work by Fred Hebert, the author of http://learnyousomeerlang.com .
I like the exercises at end of chapters. Most of it is Erlang specific. But some chapters like "Planning For Overload" are interesting in general if you are running distributed system at scale.
This should be required reading for anyone building systems in which subcomponents can fail independently, Erlang or otherwise! The techniques are not always implementable in other languages, but the concepts behind them can and should be translated.
Then maybe it's time to expand your horizon a bit, he also has another book about Erlang that's a bit more beginner level: http://learnyousomeerlang.com/ , I promise you that if you stick to it for a couple of weeks that you will not regret investing your time even if you never use Erlang professionally. Some of the philosophy behind it and the methodical way of attacking a problem will rub off and will make you a better programmer in the longer term.
