Yes, the use case is usually for highly concurrent system. There just happen to be quite a few of those in recent years. Multiple things happening at the same time colloquially speaking. Now it won't be good for fast concurrent problems, like say multiplying matrices, or computing FFT, you'd use a GPU and Fortran for that perhaps. But think of large game server with multiple worlds, and players trading with each other. Think of a large distributed database (like Riak). Think of the backend of large VOIP systems with multiple calls happening at the same time. Or maybe a large chat system (Ejabberd).
Erlang as a general purpose programming language is also interesting. It forces you to think about problems in a different way. Actually 2 ways: -- functional and using actors.
Also, its primary characteristic and design goal is fault tolerance. That was #1 item on the TODO list when it was designed. It is one of the very few languages and systems that has that as the primary goal. Many of the other features -- concurrency, isolation, run-time code upgrade, immutability of data structures, kind of fall out of that. So that is another general area that you might consider where using it makes sense.
On types -- many criticize Erlang for not having a static type system. Not all is lost. Erlang has a way to analyze its types using dialyzer. It is a success typing system. http://erlang.org/doc/reference_manual/typespec.html . The more you annotate the code the better it gets. Dialyzer will not catch all the errors BUT when it complains, it is guaranteed to be an error.
To go hand in hand with that. It has very neat (3rd) party testing tools available. One of the most interesting ones are for Property Tests. These allow you to specify model constraint on your code and it will automatically generate tests to try to find failing use cases that break the constraint.
Anyway, hopefully this gives a bit more of an idea.
To go hand in hand with that, on the testing side it has
Yes, the use case is usually for highly concurrent system. There just happen to be quite a few of those in recent years. Multiple things happening at the same time colloquially speaking. Now it won't be good for fast concurrent problems, like say multiplying matrices, or computing FFT, you'd use a GPU and Fortran for that perhaps. But think of large game server with multiple worlds, and players trading with each other. Think of a large distributed database (like Riak). Think of the backend of large VOIP systems with multiple calls happening at the same time. Or maybe a large chat system (Ejabberd).
Erlang as a general purpose programming language is also interesting. It forces you to think about problems in a different way. Actually 2 ways: -- functional and using actors.
Also, its primary characteristic and design goal is fault tolerance. That was #1 item on the TODO list when it was designed. It is one of the very few languages and systems that has that as the primary goal. Many of the other features -- concurrency, isolation, run-time code upgrade, immutability of data structures, kind of fall out of that. So that is another general area that you might consider where using it makes sense.
On types -- many criticize Erlang for not having a static type system. Not all is lost. Erlang has a way to analyze its types using dialyzer. It is a success typing system. http://erlang.org/doc/reference_manual/typespec.html . The more you annotate the code the better it gets. Dialyzer will not catch all the errors BUT when it complains, it is guaranteed to be an error.
To go hand in hand with that. It has very neat (3rd) party testing tools available. One of the most interesting ones are for Property Tests. These allow you to specify model constraint on your code and it will automatically generate tests to try to find failing use cases that break the constraint.
Anyway, hopefully this gives a bit more of an idea.
To go hand in hand with that, on the testing side it has