Erlang

Не бывает достоинств без недостатков.

Достоинства:

• функциональный язык с простым синтаксисом;
• удобный синтаксис для записи математических функций;
• ленивое исполнение;
• событие ориентированный;
• замыкания;
• обширная библиотека OTP;
• легковесные потоки;
• удобная система фильтрации в условных операторах и разбора данных  по шаблону.

Недостатки, если смотреть излишне критично, вытекают из достоинств:

• необычный синтаксис; 
• никогда во время исполнения не чистит память, очистка вызываться только после завершения N-количества потоков;
• во время очистки блокируется полностью вся виртуальная машина;
• только недавно появилась поддержка многоядерных процессоров;
• изначально написан для телефонных станций (ориентация на необычную специфичную сферу деятельности);
• легковесные потоки - миф - при появлении ожидания  сообщения переключается на другой поток и при появлении новых сообщений ставим в очередь (возможно ее переполнение);
• полностью функциональный язык со всеми неудобствами - нужно реализовывать большинство алгоритмов полностью рекурсивно (и кто его знает сколько оно будет думать?) и не использовать переопределение значений переменных(непривычно и иногда неудобно);
• сложные вещи реализуется просто, простые очень сложно;
• строки представлены списками, где используется не экономный формат данных для хранения 1 байта используется 8;
• базы данные мнезье - все хорошо пока у вас памяти больше, чем данных, а потом или все читаем с диска или ядро убьет вас(не умеет оптимально кешировать запросы используя достоинства обоих типов хранения данных);
• сложение строк дает разные значения в зависимости перемены мест слагаемых.

Риторические вопросы:

• хотим чтобы не не использовали небезопасное выделение памяти и глобальные переменные - может стоит объяснить людям почему это плохо или дать удобный интерфейс для использования, а не полностью запрещать в синтаксисе?
• ленивое выполнение - а вы всегда уверены когда это все выполниться и не зависнет ли? Как посчитать время исполнения? И все современные компиляторы стараются в месте с суперскалярной архитектурой (внеочередное выполнение, параллельное исполнение нескольких участков с применением уже рассчитанных результатов при благоприятном стечении условий) пытаются оптимизировать поток выполнения. И не стоить заменять логику надеждой - среда исполнения сама разберется  что уже не нужно исполнять дотянув реальное выполнения до последнего момента;
• замыкания - если вы боитесь за стек включите оптимизации в компиляторе он давно умеет это избегать(в gcc - уже есть оптимизация при которой для рекурсивного выполнения стек если это возможно не растет).
• если так уж хотим выделяться - берем гугловсий Go и получаем все тоже, но компилируемое... Не хотим? Есть куча библиотек по контролю за памятью и обменам сообщениями, все равно он преобразует в байткод исполняемый в виртуальной машине написанной на с, и если немного подумать можно сделать возможно и лучше и быстрее.

Но все же попробовать стоит... Язык хороший и если использовать по назначению, удобный с хорошей продуманной системой фильтрации и событие-ориентированой средой исполнения.