Функциональщикам ЛОРа

Автор erlyvideo писал, что одна из наиболее частых задач - разобраться почему у клиентов софт сбоит. К ВМ эрланга можно легко подключиться удалённо и выяснить, в чём траблы. А вот с хаскеллем уже нифига так просто не получится.

а в чём его сильные стороны?

Вкусные штуки типа failover и тому подобной фигни из коробки. Хотя как язык - полная дрянь.

Пишу на haskell студенческие семестровые поделки, связанные с разработкой языков. Написал компилятор си-подобного недоязычка в язык ассемблера ARM.

Вот и я говорю - незачем. Поэтому хаскель и не нужен.

Несколько веб скраперов на хаскелле и всякие подделки для себя.

А чем эрланг не функциональный?

Заточка под многопоточность. Эрланг хорошо ложится на задачи параллельной обработки множества соединений при этом сильно упрощая жизнь в реализации. Допустим обработка уже нескольких тысяч одновременных соединений на си или плюсах уже заставит об очень многом задуматься, ибо ядерные треды имеют свой немалый оверхэд, а эрланг тебе позволяет (тут я сильно упрощаю, но суть токова) просто наплодить на каждое соединение по треду и сильно упростить задачу проектирования. Ну и отсутствие мутабельных переменных приводит к резкому снижению количества критических секций в коде. Message passing во все поля. Бутылочные горла производительности решаются переписыванием узких кусков на си и прозрачному вызову их из эрланга.

В минусы я бы занёс отсутствие системы типов подобной хаскелевой, но это вкусовщина на мой взгляд, и так неплохо.

Короче, если передо мной встанет задача написания хорошо параллелящейся хрени, типа сетевого сервиса, я скорее всего выберу эрланг.

Подходом. Практически всё, что пишется на Erlang, содержит сайд-эффекты в каждой второй строчке, причём большая их часть не идемпотентны. Посмотри на OTP — что ты видишь в первую очередь? Наверняка gen_server или что-то рядом. А это означает — постоянные сайд-эффекты, изменяемое состояние и все прелести.

Тем, что некоторые отождествляют функциональщину с чистой функциональщиной. Для таких Эрланг — ООП-язык с лямбдами.

есть ли ФЯП кроме хацкеля?
RedPossum

хацкедь не ФЯП а ЯФП! Стыдно не знать такого! :)

Изменяют. Они скатывают глобальное состояние.
Pavval

Ну палишься же! Скатывают императивщики, функциональщики - фолдят! Две большие разницы ... :)

Так я ж и говорю, что каменты императивны.

На основной работе (телеком) я пишу всякое на эрланге. На другой работе пишу обработку данных на скале. До этого писал систему сбора данных с пром оборудования на хаскелле (плюс сейчас небольшие вспомогательные утилиты пишу на нем же).

Помимо этого активно использую Coq и F# под виндавс.

нет, не ленив. просто я на С++ такие же приложения пишу много лет и не вижу явных выгод применения, например, Erlang. по ссылке - обычный рекламный буклет, без обсуждения деталей и реализации, без приведения тестов сравнения, оценок производительности. это несерьёзно. опыт показывает, что любые виртуальные машины - это сразу падение скорости, причём в разы, по сравнению с компилируемыми программами.

я хочу не общих фраз, а конкретики: какие структурные особенности языка или компилятора (если он там вообще есть) существенно отличны от других языков и почему они лучше подходят для решения тех или иных задач. это может сказать только человек, имеющий действительно большой опыт разработки на данном языке.

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

мы в телекоме пишем на С++. да, обработка тысяч соединений - довольно геморная вещь. но зато это работает очень быстро даже на дешёвых мелких серверах.

На C++ невозможно сделать такие дешевые и легковесные потоки, как в ебланге. Следовательно, недьзя применять и такую модель программирования. В типичном приложении на ебланге могут быть десятки тысяч потоков.

Труд программиста стоит на порядки больше чем ресурсы сервера. Поэтому Java и erlang рулят, а C++ сосет.

Почитай историю разработки CouchDB, автор вполне конкретно рассказал почему Erlang оказался лучше. Ну и не забываем, что можно работать быстро а можно - безотказно. В общем, в книжке Чезарини и Томпсона вполне точно описано когда использовать Erlang и какой от этого будет профит. А говорить об абстрактных опытных программистах толку нет.

С++-программистам бесполезно пытаться что-то объяснять: «Кококо, производительность, кококо, 10 лет опыта, кококо»

На C++ невозможно сделать такие дешевые и легковесные потоки, как в ебланге.

Уверен?

Почти всё, что писал. Ведь Python это функциональный ЯП, не то, что некоторые.

Уверен?

Ну только если ты напишешь свою VM, аналогичну еблангу, но тогда писать-то все равно не на C++ будешь.

написал программу расчета усредненного коэффициента массопереноса для бинарной ректификации, сейчас пишу программу расчета оптимальной последовательности разделения многокомпонентной смеси.

а по-русски можно, пожалуйста?

Причем тут VM? Легкие треды либой много где есть.

невозможно

да ну, user-mode scheduling даже в винде есть

А не уссышься код аккуратно под кооперативную многозадачность писать? VM за тебя все сама хотя бы сделает.

Но зачем? Легкие потоки еще половина беды - все это хозяйство нужно синхронизировать между собой, изолировать друг от друга, реализовать передачу сообщений между ними. Реализация подобного на С/С++ просто приведет к созданию своего Erlang'a, который еще не факт что будет быстрым.

В минусы я бы занёс отсутствие системы типов подобной хаскелевой, но это вкусовщина на мой взгляд, и так неплохо.

это вкусовщина

Фигасе.

А, допустим, миллион потоков виндовый user-space scheduler осилит? Деталей реализации его не знаю, сразу предупреждаю.

виндовый

Суть в том, что его нет, он же _пользовательский_. Как напишешь, так и осилит

Хм, освежил в памяти API, так что хрен его знает

Я думал что это готовая конструкция с некоторой политикой планирования, а руками писать шедулер дело неблагодарное и сложное.

А не уссышься код аккуратно под кооперативную многозадачность писать?

Я - нет. За других не скажу.

Да, никто не говорит про то, что я вот возьму и начну это на плюсах велосипедить. Просто вброс был про «невозможно».

Реализация подобного на С/С++ просто приведет к созданию своего Erlang'a,

Ну да.

который еще не факт что будет быстрым.

Обоснуй. Я что-то не вижу причин ему теоретически быть быстрее Erlang'a («теоретически» - т.е. подразумеваю реализацию прямыми руками).

На самом деле готовые конструкции там и есть, но вот в миллионе я уже не уверен

Ну-ка расскажите, как вы сделаете вытесняемые user-space треды в С++?

Обоснуй. Я что-то не вижу причин ему теоретически быть быстрее Erlang'a («теоретически» - т.е. подразумеваю реализацию прямыми руками).

Ты имеешь в виду «не вижу причин ему теоретически не быть быстрее ...»? Теоретически - возможно, я просто выразил свое скептическое к этому отношение. Написать VM: планировщик, сборщик мусора, компилятор для языка под нее - задача крайне сложная и, имхо, куча времени уйдет просто на то чтобы пройтись по всем граблям и сделать хотя бы не медленнее VM Erlang'a.

Ну-ка расскажите, как вы сделаете вытесняемые user-space треды в С++?

Сигнал прерывает ядерный тред, а его обработчик переключает user поток.

Или ptrace для модификации ядерного потока и переключения его с одного user потока на другой.

Тоже мне проблему нашел.

Зачем VM? Для чего VM? Все в нативе.

Але, ты рамсы не попутал? Надо БЕЗ context switch-ей.

Невозможно сделать семантически эквивалентно тредам erlang-а. Максимум что осилишь - громадных размеров невменяемую state machine.

Сам ты рамсы попутал. Для user-space потока context-switch - это замена в хостящем его kernel-потоке регистров, в первую очередь IP+SP. Переключения kernel-потоков нет.

Обоснуй. А то «невозможно» - слово уж больно красивое.

Натив не подойдет: падение потока утащит за собой весь сервер, хотелось бы иметь изоляцию потоков друг от друга (невозможность шариться по адресному пространству других потоков).

безотказность - это лишь вопрос аккуратности и опыта. писали мы на С++ софт, который работает 24/7. и не раз. просто писать надо грамотно. и можно на любом языке писать.
конечно, если говорить о простоте поиска сотрудников, то найти опытного С++ программиста гораздо сложнее, чем найти не совсем опытного программиста на java или ещё каком-то защищённом фреймворке. с этой точки зрения проще, да.

насчёт CouchDB: я как раз тестировала базы для нужд по работе относительно недавно. может, Erlang в CouchDB и оптимальнее для программирования, но ArangoDB на С++ всё-таки шустрее. там, конечно, тоже есть косяки и ограничения, но для небольших баз он эффективнее. а самый быстрый - MemSQL (хотя он и платный): он основан на компиляции запросов в сишный код.

Аргумент, принято.

падение потока утащит за собой весь сервер

зачем же так жосско? смотря как написан код. вообще, поток - всего лишь поток. никто не запрещает отлавливать исключения и ставить таймеры на локи ресурсов. ну и какбэ для системы типа никсов трагическая безвременная смерть одного потока систему точно не убьёт.

Я про сервер который программа, а не железка с софтом. Если в потоке программы происходит segfault, то может для ОС в большинстве случаев и нет ничего ужасного, но вот решение поставленных задач она прекращает.

Между user space и kernel space переключение тоже не дешевое. У тебя потоки только в syscall-ах будут переключаться, а с VM где угодно, посреди долгих вычислений без единого ядреного вызова.

да всё пишется. я в телекоме сейчас работаю. пишем под Linux на С++. изредка бывает, что железо присылает фигню или начинает забрасывать сервер пакетами и могут происходить исключения. ну, упадёт поток, снова поднимется. есть процессы, которые следят за потоками. и даже если главный процесс вдруг хлопнется (чего пока не наблюдалось) уотчдог снаружи его поднимет снова. ничего особо хитрого тут нет. софт работает круглосуточно, с миллионами живых юзеров.