Только я собрался прочитать «Learn You Some Erlang...

И не стыдно тебе лого лиспа ставить на аватарку?

Нет, я ж не говорю что лисп чем-то уникален и без него прям ну никак.

Пример где нельзя обойтись без макросов в студию?

А я где то говорил, что макросы это какое-то преимущество? Да, фанбои-неофиты носятся с этими макросами как дураки со ступой, хотя вообще говоря это в лиспе дело десятое.

ты вкурсе что до сих пор существует и поддерживается софт на коболе, фортране, и даже прости г-ди лиспе?

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

никто не стремится вбухать еще столько же и переписать его на сях, джаве или питоне

Вот именно. А уж на эрланге тем более. Зачем менять один полумертвый язык на другой?

жависты аж целую акку себе запилили

Вот именно, адекватные люди пишут библиотеку, а не новый язык на каждый чих.

Как там, в акке-то, память уже перестала течь?

Не знаю, не пользовался.

cowboy - вебсервер. что значи эрланга там нет?

А то и значит. Какой процент веб-узлов обслуживаются cowboy и какой apache/ngnix/IIS?

а если брать кластер на эрланге для задачи которая параллелится - то нет.

Апологеты Erlang-а отличаются редкостной узостью мышления. Задачи, которые параллелятся — это, в том числе, и высокопроизводительные вычисления, в которых рулят и бибикают OpenMP и MPI (и языки, вроде Fortran/C/C++).

Так что, чтобы в очередной раз при признавать, что вы высказались слишком общо, попробуйте заузить область. Например, для задач обслуживания большого количество Web-запросов... Тогда Erlang можно будет всерьез рассматривать.

как бы инкрементальная разработка, вначале берем удобный высокоуровневый язык, тем более с кластеризацией и OTP из коробки, а потом, когда станет ясно где узкие места - их отдельно переписать на чем-то более подходящем.

Только добавляем сюда еще и динамическую типизацию, отсутствие средств для поддержки сколько-нибудь сложных структур данных, неважное качество инструментов за пределами OTP (те же ORM)... И выясняется, что какая-нибудь Akka вполне зарулит Erlang в инкрементальной разработке.

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

В том виде, в котором есть в Erlang, не подтянуть. Только вот можно очень неплохо жить и без таких специфических для Erlang-а вещей, как горячая замена кода, легковестные процессы в vm с собственным хипом и вытеснением по количеству редукций, тотальной иммутабельностью... Что там еще такое специфическое для Erlang-а?

Нет, я ж не говорю что лисп чем-то уникален и без него прям ну никак.

В эрланге можно без процессов, но смысла мало. Но и любой современный софт, кроме скриптов на баше, трудно представить без процессов. Хотя это может эрланг на меня так повлиял.

Речь была про современные библиотеки и современные решения, которые никто для эрланга адаптировать не собирается

Что значит адаптировать? Написать обертку к либе или клиент к сервису не состовляет проблем, количество их не велико, но вот в эликсире, опять же, с этим все напорядок лучше.

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

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

Зачем менять один полумертвый язык на другой?

Ну и к чему тогда ты написал что никто не будет переписывать софт под акторы? Точно так же никто не будет переписывать под ООП или под монады.

Например, для задач обслуживания большого количество Web-запросов.

apache/iis/nginx. Все уже украдено до нас.

И выясняется, что какая-нибудь Akka вполне зарулит Erlang в инкрементальной разработке.

Ох ёпрст. Пора рестартануть томкат, permgen space сам себя не очистит! Хочешь сравнить деплой жаваприложений и деплой эрлангоприложений, серьезно?

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

Да некоторые без ног неплохо живут, тока что-то не агитируют никого на ампутацию. Видать, узкое мышление у них слишком.

А то и значит. Какой процент веб-узлов обслуживаются cowboy и какой apache/ngnix/IIS?

Понятия не имею.

Задачи, которые параллелятся — это, в том числе, и высокопроизводительные вычисления, в которых рулят и бибикают OpenMP и MPI (и языки, вроде Fortran/C/C++).

Ну покажи мне код, который палаллелит задачу на насколько нод в кластере, на фортране.

попробуйте заузить область. Например, для задач обслуживания большого количество Web-запросов

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

Только добавляем сюда еще и динамическую типизацию, отсутствие средств для поддержки сколько-нибудь сложных структур данных, неважное качество инструментов за пределами OTP (те же ORM)... И выясняется, что какая-нибудь Akka вполне зарулит Erlang в инкрементальной разработке.

Все так, но у эрланга теперь есть эликсир, он заруливает обоих =)

Только вот можно очень неплохо жить и без таких специфических для Erlang-а вещей, как горячая замена кода, легковестные процессы в vm с собственным хипом и вытеснением по количеству редукций, тотальной иммутабельностью

Может и можно, но с ними тупо удобнее и приятнее.

Написать обертку к либе или клиент к сервису не состовляет проблем

Да, вот только

заблокирует один планировщик, но ее можно изолировать в отдельный процесс, сделать из них пул

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

Понятия не имею.

А начиналось то-как: «Ну то есть опять же, все серверные задачи.» Но если взять что-то конкретное, то «Понятия не имею».

Ну покажи мне код, который палаллелит задачу на насколько нод в кластере, на фортране.

Т.е. про MPI не в курсе, вам обязательно нужно конкретный пример показывать? Поищите в Google. Там много примеров, например вот этот (ссылка на исходник пониже).

Может и можно, но с ними тупо удобнее и приятнее.

Кому-то удобно с динамической типизацией и убогими структурами данных. Кому-то нет.

Так можно сделать в любом языке, да и делают, а эрланг идёт лесом

Как и зачем это делают в других языках, если это специфично для эрланга, чтобы не блокировать планировщик?

проще таки взять и решить задачу без вытесняемых акторов

А приведи примеры задач, которые ты решаешь. Я вот все время сталкиваюсь с задачами, которые на акторах решаются проще.

А начиналось то-как: «Ну то есть опять же, все серверные задачи.» Но если взять что-то конкретное, то «Понятия не имею».

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

Т.е. про MPI не в курсе

Я не претендую на то, чтобы знать все на свете. Почитал про MPI, они с эрлангом в разных весовых категориях. Эрланг это херак херак и в продакшен, и работает и не падает. А если и падает - то локализованно и перезапускается. Для MPI надо действительно постараться подобрать и задачу, и железо, и специалистов, чтобы сделать 100k-процессорный кластер и это было бы больше чем proof of concept.

Erlang и MPI для принципиально разных задач mass concurrency vs mass parallelism. При этом в MPI нужно отличать протокол (который можно использовать в любых языках и совсем других задачах (напр. распределенные фс)) и саму библиотеку, про которую обычно говорят.

«рядовой пользователь ерланга не уверен в будущем ерланга, тревога, тревога, первыми в шлюпки садятся женщины и дети»

Еще раз повторяю

Да вы можете повторять сколько угодно. Когда у технологии в некой нише есть преимущество, она выносит всех конкурентов на раз. Как это в свое время сделала Java в server-side (и где потом Java подвинули Ruby-On-Rails и Node.js), как в свое время сделал JavaScript и т.д.

Erlang живет на свете достаточно долго, чтобы, при наличии в нем таких уж выдающихся киллер-фич, на нам было написано уже много всякого разного и разнообразного. Ан нет.

Я не претендую на то, чтобы знать все на свете.

А когда говорить «все серверные задачи» и «брать кластер на эрланге для задачи которая параллелится» складывается впечатление, что претендуете.

 Какой процент веб-узлов обслуживаются cowboy и какой apache/ngnix/IIS?

предположительно небольшой. и что, это каким-то образом характеризует cowboy? и кстати — cowboy/Rack/IIS/ASP.Net/Warp за nginxом считается nginxом или нет?

Только вот можно очень неплохо жить

Не сомневаюсь, учитывая суммы в счетах, выставляемых адептами Технологий, Освящённых Временем. Следует, видимо, понимать, что хотеть жить лучше, сэкономив когнитивные ресурсы — жуткая, недопустимая ересь.

Но если взять что-то конкретное, то «Понятия не имею».

да в общем-то любую, не упирающуюся в CPU.

это каким-то образом характеризует cowboy

Это каким-то образом характеризует пользователя loz, который сделал заявление о том, что Erlang подходит для всех серверных задач. Только вот на первой же серверной задаче, HTTP-сервера, оказывается, что Erlang является явной маргинальщиной.

да в общем-то любую, не упирающуюся в CPU.

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

Тогда как сама тема посвящена статье, в которой говорится, что спектр сам по себе не широк, да еще и уменьшается со временем.

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

Какое-то сомнительное утверждение. Пруф?

Erlang живет на свете достаточно долго, чтобы, при наличии в нем таких уж выдающихся киллер-фич, на нам было написано уже много всякого разного и разнообразного. Ан нет.

Не должно.

Это каким-то образом характеризует пользователя loz, который сделал заявление о том, что Erlang подходит для всех серверных задач. Только вот на первой же серверной задаче, HTTP-сервера, оказывается, что Erlang является явной маргинальщиной.

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

Только упертые Erlang-еры продолжают (как выясняется, по узости кругозора) утверждать, что Erlang хорош для широкого спектра задач.

У нас разные представления о ширине. Эрланг хорош для серверов и его там используют. Для меня это широкий спектр задач.

Пруф?

Научитесь читать то, что вам пишут.

У нас разные представления о ширине.

Очевидно.

Для меня это широкий спектр задач.

Ок.

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

Там же иммутабельность во все поля, массовые кодеры такое не осиливают. Поэтому много всякого никогда не будет. И elixir тут не сильно поможет, те же яйца по сути, ну только синтаксис не такой инопланетный (хотя тоже мозг может расплавить типичному индусу).

раз уж меня спросили про перфоманс, отвечу.

Мы делаем видеостриминговый сервер, это штука, которая принимает пол-гигабита в секунду, разбирает до байтика, собирает обратно и раздает 10 гигабит в секунду.

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

Софт на яве со всеми настроенными джитами и прочими хитростями типа off heap memory еле еле сравнивается с нашим софтом на эрланге по перфомансу и памяти.

В большинстве случаев народ не может раскочегарить джаву до 10 гигабит и проблема тут прежде всего в мьютексах. Можно сколько угодно задирать нос на тему мультитредного программирования, но в 999% случаев те, кто разглагольствуют о необходимости прямых рук, не смогут даже блокирующую очередь напрогать на мьютексах и тредах.

У эрланга очень крутая VM для ограниченного набора случаев, связанных прежде всего с потоковой обработкой данных в многоядерном режиме. Вся ирония в том, что его чумовая мультитредность появилась на сдачу от других выбранных концепций типа обмена сообщениями и share nothing подхода. Потом к этим концепциям просто приделали получше реализацию и всё сложилось.

Сравнивать яву с эрлангом по перфомансу это в целом признак школоты. Если мы говорим про перемножение матриц, то надо сравнивать тормозную туповатую джаву, nvidia cuda и intel sse4. Успехов джаве в таком сравнении. Если мы сравниваем кодирование видео, то опять же сравниваем с intel sse4. Успехов всем остальным вместе взятым в таком сравнении.

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

Можно привести веселый пример про реализацию std::string в gnu и у микрософта. В линуксе быстро сделали copy on write, а в микрософте ниасилили и оставили копирование сразу. По прошествии 10 лет внезапно второй подход оказался быстрее, потому что в copy on write напихали мьютексов и они внезапно стали адски тормозить всё.

Мы делаем видеостриминговый сервер, это штука, которая принимает пол-гигабита в секунду, разбирает до байтика, собирает обратно и раздает 10 гигабит в секунду.

Простите мне мой ламеризм, но неужели у вас Erlang прям вот на голом железе работает? У вас драйвера сетевых карт на Erlang-е написаны? ОС под вами никакой нет? Вы вот эти 10GiB/s прям с секторов диска поднимаете и прям в по I/O портам сетевухи запихиваете? И все вот это вот на чистом Erlang-е?

Чтобы сделать ваш комментарий достаточно фееричным, вы забыли попросить, чтобы VM erlang была написана на erlang.

Да, не додумал.

Однако, если всей I/O механникой ведает ОС, которая кроме всего прочего, умудряется еще и другие процессы диспетчировать (а насколько я помню, продукт, о котором идет речь, под обычными Linux-ами работает), то дело не в том, что низкоуровневые языки чего-то не умеют.

И все вот это вот на чистом Erlang-е?

При чём тут чистый или не чистый и на чём написана ОС?

Если на той же самой ОС и прочем, у автора поста еле справляется Java и нормально — Erlang, то как отсюда можно сделать вывод, что Erlang не при чём?

Нигде не говорилось, что Erlang не при чем.

Взять вот это:

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

Все эти проблемы есть не только у Лапшиновского Флусоника, они есть и у ОС. И ОС с этими проблемами вполне справляется. Так что из истории успеха конкретного продукта сложно делать вывод о том, что ключом к успеху стал именно Erlang (хотя сам Лапшин в этом может быть убежден на 100500%). Ну и, собственно говоря, сложно делать выводы о производительности именно Erlang-а, если есть подозрения, что в функциональности Флусоника изрядная доля нагрузки выпадает именно на низкоуровневый код (как в ОС, так и в VM Erlang-а и его библиотеках).

Как это в свое время сделала Java в server-side (и где потом Java подвинули Ruby-On-Rails и Node.js), как в свое время сделал JavaScript и т.д.

Я потратил три года на Ruby и Rails. Первый оказался запутанным посредственным недоязычком а-ля Перл; второе по итогу оказалось хуже даже symfony 1.4. В связи с этим я склонен считать 90% пользователей RoR (и Node.js, кстати, тоже) полуграмотными леммингами, которым в целом всё равно, на чём писать гостевухи. А success stories проектов на помянутых технологиях, насколько я могу судить, скорее истории достижения требуемого результата вопреки отличительным особенностям этих технологий, а не благодаря.

здесь начинаются комплексные проблемы, связанные с таймерами (трижды хаха)

А в чем проблемы с таймерами?

Можно привести веселый пример про реализацию std::string в gnu и у микрософта. В линуксе быстро сделали copy on write, а в микрософте ниасилили и оставили копирование сразу. По прошествии 10 лет внезапно второй подход оказался быстрее, потому что в copy on write напихали мьютексов и они внезапно стали адски тормозить всё.

Что-то мне подсказывает, что CoW из GNU-шной реализации std::string совсем недавно выпилили из-за несоответствия стандарту C++11.

В связи с этим я склонен считать 90% пользователей RoR (и Node.js, кстати, тоже) полуграмотными леммингами, которым в целом всё равно, на чём писать гостевухи.

Насколько я могу судить, в 2005-2006-м, когда RoR вышел из беты, у «полуграмотных леммингов» для написания «гостевух» выбор был из J2EE, PHP и Perl/Python CGI. Что было слишком накладно для проектов такого калибра. Тут появляется RoR и выносит всех на раз.

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

с таймерами просто большая проблема.

у тебя есть 100 000 подключенных сокетов, на каждом из которых минимум по одному таймеру. Как вести учет ста тысяч таймеров — это большой вопрос, который где-то решается хорошо, где-то не очень.

Есть какие-то хитрости из серии: поместить в блоки по 1000 акторов и оповещать их пачкой. В этом случае получаем волны нагрузки вместо ровной размазанной нагрузки.

В связи с этим я склонен считать 90% пользователей RoR (и Node.js, кстати, тоже) полуграмотными леммингами

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

у тебя есть 100 000 подключенных сокетов, на каждом из которых минимум по одному таймеру. Как вести учет ста тысяч таймеров — это большой вопрос, который где-то решается хорошо, где-то не очень.

Сами по себе 100K таймеров — это не проблема, практически от слова совсем. Вопрос с таймерами вовсе не в самих объектах-таймерах, а в том, успевает ли приложение выполнить прикладную обработку возникающих таймерных событий с нужным темпом. Т.е. если в приложении срабатывает 10K таймеров каждую секунду, то приложение должно быть способно обработать эти 10K событий в течении секунды. Если не успевает, то значит в следующую секунду приложению придется обрабатывать 10K новых таймерных событий + остаток от предыдущей секунды. И этот остаток будет все время накапливаться.

Так что вопрос не в том, как порождать большое количество таймерных событий.

Есть какие-то хитрости из серии: поместить в блоки по 1000 акторов и оповещать их пачкой. В этом случае получаем волны нагрузки вместо ровной размазанной нагрузки.

Это уже обратная сторона модели акторов. Неофиты с горящими глазами быстро натыкаются на такие вещи, когда создают актора на каждый чих, а потом обнаруживают внезапные спорадические всплески нагрузки. Которые иногда рассасываются сами собой, а иногда приводят к деградации приложения.

Кроме таймеров такой эффект еще хорошо проявляется, например, если каждый актор пытается самостоятельно работать с БД.

Кроме таймеров такой эффект еще хорошо проявляется, например, если каждый актор пытается самостоятельно работать с БД.

Следует понимать, что Джо Армстронг и Роберт Вирдинг в каждой еженедельной энциклике предают анафеме тех, кто работает с БД через пулы соединений.

Вот это интересно, а что не так в работе с бд через пулы? И что предлагается вместо этого?

да, мне тоже интересно, как ещё это возможно

Я так понимаю, он намекает на аналогию с таймерами — когда пул исчерпан - очередь запросов растет, и никогда не будет выполнена. Но да, хотелось бы знать, что там Армстронг на эту тему пишет, я в мейлинг-листах не встречал «преданий анафеме».

Впрочем, «никогда» - это я поспешил, просто суперлаг будет.

поначалу да, если приложение вырастает — начинаются страдания и унижения

нене, тут просто eao197 неявно предполагает, будто пулы соединений к БД из ерланга запрещены, вот я ему и подыграл. неудачно попытался подыграть то есть.

Только я собрался прочитать «Learn You Some Erlang... (комментарий)

как ещё это возможно

Как у дидов: на каждый запрос новое соединение. Глобально и надежно!

Мда… стоит только в треде появиться человеку, реально разбирающемуся в обсуждаемой теме, как все «спецы» сразу «сливаются»… :)

тырпрайз-илитки

Сейчас как бы 2016, а не 1997.

Не-не-не, дело не в пулах подключений. Дело в независимых друг от друга транзакциях. Если акторы не координируют работу с БД между собой, в один прекрасный момент треть от 100K акторов могут захотеть сделать update для одной и той же таблицы в БД и вот тогда самая-то веселуха и начинается.

я всё таки считаю, что первое столкновение с уровнями изоляции транзакций в БД — это болезненный опыт, который всё равно прийдется пережить.

Пул соединений с БД всё равно нужен, без него никуда. Это так же, как пул процессов читающих и пишущих на диск, без пула не справиться.

Лично я например не сталкивался с необходимостью выбирать степень изоляции транзакций.

Лично я например не сталкивался с необходимостью выбирать степень изоляции транзакций.

Макс, по-умолчанию там вроде уровень read committed, его хватает в 90% случаев. Так что все окей. И да посмотрел твое выступление на fpconf. Круто!

всё, что было уникального в Erlang

Не, не все. ИМХО, рантайм эрланга как был самым концептуально крутым, так и остается.

Рантайм Го уже неплох, но там by design шаг вправо-влево приводит в жопу типа неконтролируемого размножения OS-тредов или пожирания памяти и как следствие - крэшу сервера, который хз как чинить. Ну и прочих by design хватает, пользоваться им не сильно хочется.

.NET выглядит довольно интересно, особенно с учетом существования F#, но самые интересные аспекты, кажется, плотно завязаны на винду и IOCP. Когда в языке есть что-нибудь в духе async/await - IOCP невероятно офигенен, но на линукс, говорят, не портируется by design. Вообще, я не очень в этой теме, не могу сказать уверенно.

JVM - ну я хз, что там такого есть более высокоуровнего, чем OS-треды. Да, там есть пачка библиотечных примитивов, но это именно что библиотечные примитивы, не больше. Да, поверх них сделали кучу всяких примочек, но база - Java/JVM - не имеет к этому никакого отношения и остается весьма тупой. Там даже аналога async/await нет, в каждом языке своя реализация рерайта байткода.

В итоге, никто из перечисленных до эрланга так и не дотягивается в плане рантайма. А вот все, кроме рантайма и OTP - стдлиб, изкоробочная экосистема(деплоймент, конфигурация) - в эрланге действительно то еще говнище.

Очередная статья «Х всё»