Автор erlyvideo писал, что одна из наиболее частых задач - разобраться почему у клиентов софт сбоит. К ВМ эрланга можно легко подключиться удалённо и выяснить, в чём траблы. А вот с хаскеллем уже нифига так просто не получится.
Заточка под многопоточность. Эрланг хорошо ложится на задачи параллельной обработки множества соединений при этом сильно упрощая жизнь в реализации. Допустим обработка уже нескольких тысяч одновременных соединений на си или плюсах уже заставит об очень многом задуматься, ибо ядерные треды имеют свой немалый оверхэд, а эрланг тебе позволяет (тут я сильно упрощаю, но суть токова) просто наплодить на каждое соединение по треду и сильно упростить задачу проектирования. Ну и отсутствие мутабельных переменных приводит к резкому снижению количества критических секций в коде. Message passing во все поля. Бутылочные горла производительности решаются переписыванием узких кусков на си и прозрачному вызову их из эрланга.
В минусы я бы занёс отсутствие системы типов подобной хаскелевой, но это вкусовщина на мой взгляд, и так неплохо.
Короче, если передо мной встанет задача написания хорошо параллелящейся хрени, типа сетевого сервиса, я скорее всего выберу эрланг.
Подходом. Практически всё, что пишется на Erlang, содержит сайд-эффекты в каждой второй строчке, причём большая их часть не идемпотентны. Посмотри на OTP — что ты видишь в первую очередь? Наверняка gen_server или что-то рядом. А это означает — постоянные сайд-эффекты, изменяемое состояние и все прелести.
На основной работе (телеком) я пишу всякое на эрланге. На другой работе пишу обработку данных на скале. До этого писал систему сбора данных с пром оборудования на хаскелле (плюс сейчас небольшие вспомогательные утилиты пишу на нем же).
Помимо этого активно использую Coq и F# под виндавс.
нет, не ленив. просто я на С++ такие же приложения пишу много лет и не вижу явных выгод применения, например, Erlang.
по ссылке - обычный рекламный буклет, без обсуждения деталей и реализации, без приведения тестов сравнения, оценок производительности. это несерьёзно. опыт показывает, что любые виртуальные машины - это сразу падение скорости, причём в разы, по сравнению с компилируемыми программами.
я хочу не общих фраз, а конкретики: какие структурные особенности языка или компилятора (если он там вообще есть) существенно отличны от других языков и почему они лучше подходят для решения тех или иных задач. это может сказать только человек, имеющий действительно большой опыт разработки на данном языке.
всё-таки есть проблемы производительности, как я и подозревала.
вопрос не в лёгкости написания кода, а в том, что в итоге получится. опытный программист может написать код практически на любом языке. обычно всё упирается в ресурсы системы и скорость обработки данных.
а совместимость с С - хорошая фича для любого языка.
мы в телекоме пишем на С++. да, обработка тысяч соединений - довольно геморная вещь. но зато это работает очень быстро даже на дешёвых мелких серверах.
На C++ невозможно сделать такие дешевые и легковесные потоки, как в ебланге. Следовательно, недьзя применять и такую модель программирования. В типичном приложении на ебланге могут быть десятки тысяч потоков.
Почитай историю разработки CouchDB, автор вполне конкретно рассказал почему Erlang оказался лучше. Ну и не забываем, что можно работать быстро а можно - безотказно. В общем, в книжке Чезарини и Томпсона вполне точно описано когда использовать Erlang и какой от этого будет профит. А говорить об абстрактных опытных программистах толку нет.
написал программу расчета
усредненного коэффициента
массопереноса для бинарной
ректификации, сейчас пишу
программу расчета
оптимальной
последовательности
разделения
многокомпонентной смеси.
Но зачем? Легкие потоки еще половина беды - все это хозяйство нужно синхронизировать между собой, изолировать друг от друга, реализовать передачу сообщений между ними. Реализация подобного на С/С++ просто приведет к созданию своего Erlang'a, который еще не факт что будет быстрым.
Обоснуй. Я что-то не вижу причин ему теоретически быть быстрее Erlang'a («теоретически» - т.е. подразумеваю реализацию прямыми руками).
Ты имеешь в виду «не вижу причин ему теоретически не быть быстрее ...»? Теоретически - возможно, я просто выразил свое скептическое к этому отношение. Написать VM: планировщик, сборщик мусора, компилятор для языка под нее - задача крайне сложная и, имхо, куча времени уйдет просто на то чтобы пройтись по всем граблям и сделать хотя бы не медленнее VM Erlang'a.
Сам ты рамсы попутал. Для user-space потока context-switch - это замена в хостящем его kernel-потоке регистров, в первую очередь IP+SP. Переключения kernel-потоков нет.
Натив не подойдет: падение потока утащит за собой весь сервер, хотелось бы иметь изоляцию потоков друг от друга (невозможность шариться по адресному пространству других потоков).
безотказность - это лишь вопрос аккуратности и опыта. писали мы на С++ софт, который работает 24/7. и не раз. просто писать надо грамотно. и можно на любом языке писать. конечно, если говорить о простоте поиска сотрудников, то найти опытного С++ программиста гораздо сложнее, чем найти не совсем опытного программиста на java или ещё каком-то защищённом фреймворке. с этой точки зрения проще, да.
насчёт CouchDB: я как раз тестировала базы для нужд по работе относительно недавно. может, Erlang в CouchDB и оптимальнее для программирования, но ArangoDB на С++ всё-таки шустрее. там, конечно, тоже есть косяки и ограничения, но для небольших баз он эффективнее. а самый быстрый - MemSQL (хотя он и платный): он основан на компиляции запросов в сишный код.
зачем же так жосско? смотря как написан код.
вообще, поток - всего лишь поток. никто не запрещает отлавливать исключения и ставить таймеры на локи ресурсов. ну и какбэ для системы типа никсов трагическая безвременная смерть одного потока систему точно не убьёт.
Я про сервер который программа, а не железка с софтом. Если в потоке программы происходит segfault, то может для ОС в большинстве случаев и нет ничего ужасного, но вот решение поставленных задач она прекращает.
Между user space и kernel space переключение тоже не дешевое. У тебя потоки только в syscall-ах будут переключаться, а с VM где угодно, посреди долгих вычислений без единого ядреного вызова.
да всё пишется. я в телекоме сейчас работаю. пишем под Linux на С++. изредка бывает, что железо присылает фигню или начинает забрасывать сервер пакетами и могут происходить исключения. ну, упадёт поток, снова поднимется. есть процессы, которые следят за потоками. и даже если главный процесс вдруг хлопнется (чего пока не наблюдалось) уотчдог снаружи его поднимет снова. ничего особо хитрого тут нет. софт работает круглосуточно, с миллионами живых юзеров.