Erlang — так ли он крут?

В этом году на конференции в Сан-Франциско был представлен ремейк на оригинальный ролик Erlang The Movie.

Заценить искусство можно здесь: www.youtube.com/watch?v=rRbY3TMUcgQ

Это пародия на то, как бы выглядела популяризация Erlang современными script-kid’ами, если бы Ericsson взялась сделать Erlang мейнстримным языком.

В Киеве в апреле пройдут Курсы, на которых кто угодно сможет научиться «создавать сайты на Erlang». Автор скандального поста ответит на ваши интересные вопросы.

Подробнее: dou.ua/calendar/3151

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Не рекомендую использовать Erlang. Очень мало конференций в отличии от ruby и javascript. Когда покупаешь новый iphone приходится ждать полгода и более чтобы пойти и зарисоваться с ним перед другими, к тому времени и остальные уже успевают купить себе даже ipad и футбоку с оленями.

Используя Erlang невозможно прокормить семью, в Ruby On Rails критические ошибки разработчики добавляют на постоянной основе, заказчики приходят к тебе за обновлениями и ты всегда можешь им впарить новый ненужный AJAX виджет, даже просто версии ruby устаревают чтобы можно было по новому переписывать все заново и брать за это деньги. Сайты клиентов превращаются в тлен быстрее чем вы успеваете поменять JavaScript фреймворк для AJAX виджетов. На Erlang система может работать годами, они просто разоряют разработчиков.

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

В этом письме я хочу предостеречь человечество от той роковой ошибки, которую совершил я; от той ошибки, которая привела меня к последним минутам моей жизни. Возможно вы подумаете, что я сошел с ума, но знайте — это не так. Все началось с того, что я вернулся вечером домой, вернулся уже слегка навеселе, устроился в любимом кресле у камина, закурил трубку и взяв в руки ноутбук открыл ДОУ. В первом попавшемся мне на глаза треде некий человек предлагал скачать Ерланг, что я и решил сделать; о, если бы я обратил внимание на комментарии вроде «ПОТСОНЫ НЕ КАЧАЙТЕ ТАМ ПАРАЛЕЛЬНЫЕ ПРОЦЕССЫ И АСИНХРОННЫЕ СООБЩЕНИЯ У МЕНЯ БРАТ УМЕР». Нет же, я не стал даже их читать, я смело скачал файл, распаковал его и... И я решил налить себе еще немного виски перед тем, как начать программировать. Пока я отходил за виски, за компьютер сел мой брат. О, это была его роковая ошибка: в Ерланге видимо сработала тайм-бомба и компьютер взорвался озарив дом светом ядерного гриба. Мой брат, царствие ему небесное, погиб сразу же. Сейчас я лежу в больнице, у меня лучевая болезнь и рак мозга. Жить мне осталось всего несколько часов, а может и того меньше. Сейчас я допишу это письмо и постараюсь его выкинуть в окно, я надеюсь его кто-нибудь найдет и разместить туда, откуда я скачал файл. Быть может оно спасет еще ни одну жизнь. Прощайте...

Erlang не крут. Мы сначала сделали всю бизнес-логику на нём, купились на обещания, что он позволяет сделать отказоустойчивый сервер, но при росте нагрузки всё стало падать, клиенты не могли установить соединение. В итоге переписали на Node.js+MongoDB, стало всё намного проще и стабильнее. Но писать на Javascript не очень приятно, так что выбрали Clojurescript. Проблемы все прошли.

Мне друг сказал, что на Элранге можно работать с сокетами. Я купил диск на базаре с Эрлангом, а он не запускается. Даже антивирус его не определяет. Вот Яваскрипт тема. Еле диск на базаре вернул...

Будучи ниспослан из аД͑ͥ͊̐а, эрланг несет в мир тьму и тлен.
Прольются реки крови искусившихся, те͠ќ̧у͘т џ̶з тв̡ои͟х гла͢з̸ ̛к̕ак жидкая боль, глас смертных со сферы я вижу ты видµшь ̲͚̖͔̙э̩́т̲͎̩̱͔́̋̀∆ последняя капля лжи людской ВСЕ ПОТЕ͖̩͇̗̪̏̈́РЯНО ВСЕ ПОТЕРЯНО пон̷и он грядет он гр̶̮ядет он грядет все МОЕ ЛИЦО МОЕ ЛИЦО бᵒже нет НЕТ Н∑Е̼∑Т ЊЂТ прекрат *̶͑̾̾​̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s Lorem ipsum п͏͔̠̖̟̞̦р̬̺̟̰̹ͥ̃о҉ͅс̫͍͊т̀̍̃ͦ̐ͅи̱̭̩̩̖͙̫͊ ͓̙ͩ̔̑̃ͮͣ͂͠j͉͕ͬ̑͌ͫaͧͮ̉̌ͫ̓̓va а͉͋̎̈́͢͝ͅӒ͇̝̾ͤ̓ͦа̠͙̱̟̲̳͇̩̲͆͊̋͗͋а̢̰̘̼̍ͧ̎͑͘ͅ...

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Erlang — так ли он крут?

ходят упорные слухи, что эрланг не так крут, как хаскель)

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

Время шло, Erlang dev. становилось все больше, но по итогу как-то нет, неужели выехали за нашу прекрасную границу?
Как вариант, они есть, просто недостаточного качества :)

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

Апнем темку, что ли..

«У меня пиковая нагрузка на сервере с apache — 300 запросов в секунду. [...] Сервер не выдерживает.»

rsdn.ru/...60.flat#5938060

ТС правильно ответили, что в его случае «можно много чего подкрутить». В частности nginx + php-fcgi работает «на ура».
Приложение на Erlang надо изначально задумывать на Erlang, основываясь на коробочных возможностях OTP.

У меня PHP5 FCGI с выдает 5000 connections/s с таймаутами

Erlang — так ли он крут?
Нет.

Еще про Erlang:

если из Erlang выпарить суть, то останется очень и очень старая вещь, о которой надолго забыли (потому что ресурсы не позволяли добиться сравнительной эффективности), и потом «внезапно» вспомнили.

plus.google.com/...sts/d5QhZrxK1Rf

реализаций актёров этих — что грязи.

То то я смотрю Viktor Klang, Director of Engineering at Typesafe Inc. доказывает мне в твиттере, что Akka не хуже Эрланга :-)

Насладившись красотой питон кода от мэтров ( dou.ua/...ums/topic/7732 ), предлагаю теперь насладится красотой эрланг кода от здешних мэтров.
Оставим за рамками дискуссии то что никакого two phase commit автору реализовать не удалось и близко, а просто полюбуемся логичностью, читабельностью и красотой эрланга.

maxim.livejournal.com/422351.html

-module(dtc).
-compile(export_all).
-define(TIMEOUT, 5000).

start() -> spawn(fun() -> coordinator() end).

coordinator() -> 
    receive
        {Result,State} -> io:format("Result: ~p with ~p",[Result,State]);
        ReqList when is_list(ReqList) -> spawn(fun() -> transaction(ReqList,self()) end);
        Req -> io:format("Unknown: ~p",[Req]) end, coordinator().

transaction(ReqList,Reply) -> map_reduce(ReqList,Reply,prepare).

map_reduce(ReqList,Reply,Command) ->
    Pid = spawn(fun() -> completion([],length(ReqList),Reply,Command) end),
    perform(ReqList,Pid,Command).
 
completion(State,Num,Reply,Command) ->
    receive
        {Node,Req,SqlType,Result,Command} -> 
            case {length(State) =:= Num,Command} of
                 {false,_}       -> completion([{Node,Req,SqlType,Result,Command}|State],Num,Reply,Command);
		 {true,commit}   -> Reply ! {ok,State};
		 {true,rollback} -> Reply ! {failed,State};
                 {true,prepare}  -> case lists:all(fun({_,_,_,{Answer,Id},_}) -> Answer =:= yes end,State) of
			                 true  -> map_reduce(State,self(),commit);
                                         false -> map_reduce(State,self(),rollback) end end
    after ?TIMEOUT -> map_reduce(State,Reply,rollback)
    end.

perform(State,Reply,Command) ->
  [ spawn(cohort(Node,SqlType,Req,Reply,Command)) || {Node,Req,SqlType,Result,_} <- State ].

cohort(Node,Req,SqlType,Reply,Command) ->
    {Answer,Parameter} = SqlType:Command(Node,Req),
    Reply ! {Node,Req,SqlType,{Answer,Parameter},Command}.


Ну и интерфейс драйверов:

-module(oracle).
-define(API,[prepare/2,commit/2,rollback/2]).
-export(?API).

prepare(Node, Req) -> driver:prepare_query(Node,Req).
commit(Node, Req) -> driver:commit_query(Node,Req).
rollback(Node, Req) -> driver:rollback_query(Node,Req).

Функциональные, динамически типизированные языки являются де-факто узкоспециальными инструментами, а не крутыми языками.
Уменьшение синтаксиса, при фактическом переносе сложности не на плечи компилятора, а в мозг программиста, сильно увеличивает влияние качества этого мозга на конечный результат.

ИМХО Люди, смысл жизни которых состоит в автоматизации и упрощении жизни клиентов, но при этом презирающие ООП, статическую типизацию или синтаксический сахар, по-моему, выбрали не ту профессию. Нельзя одновременно любить автомобили и презрительно относится к коробке-автомату или обогреву заднего стекла.

зы Мнение составлено после недавнего прыжка с разбега в R после продолжительного и ровного сидения на C#. Фото горы кирпичей прилагаются.

Кстати, крутыми в данном контексте могут быть только яйца... Кстати так круто сформулированного утверждения «динамически типизированные языки являются де-факто узкоспециальными инструментами» тоже касается.

Із одного R, дійсно заточеного під вузькоспеціалізовану задачу, складати уявлення про ФП загалом?!

На Scala б подивились спочатку, перед тим як порівнювати інструмент для обробки статистичних даних із C#.

Будучи ниспослан из аД͑ͥ͊̐а, эрланг несет в мир тьму и тлен.
Прольются реки крови искусившихся, те͠ќ̧у͘т џ̶з тв̡ои͟х гла͢з̸ ̛к̕ак жидкая боль, глас смертных со сферы я вижу ты видµшь ̲͚̖͔̙э̩́т̲͎̩̱͔́̋̀∆ последняя капля лжи людской ВСЕ ПОТЕ͖̩͇̗̪̏̈́РЯНО ВСЕ ПОТЕРЯНО пон̷и он грядет он гр̶̮ядет он грядет все МОЕ ЛИЦО МОЕ ЛИЦО бᵒже нет НЕТ Н∑Е̼∑Т ЊЂТ прекрат *̶͑̾̾​̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s Lorem ipsum п͏͔̠̖̟̞̦р̬̺̟̰̹ͥ̃о҉ͅс̫͍͊т̀̍̃ͦ̐ͅи̱̭̩̩̖͙̫͊ ͓̙ͩ̔̑̃ͮͣ͂͠j͉͕ͬ̑͌ͫaͧͮ̉̌ͫ̓̓va а͉͋̎̈́͢͝ͅӒ͇̝̾ͤ̓ͦа̠͙̱̟̲̳͇̩̲͆͊̋͗͋а̢̰̘̼̍ͧ̎͑͘ͅ...

это меседж из гетто джавистам(пони)

он грядет он гр̶̮ядет он грядет
лямбды уже скоро

Перекочевавший на StackOverflow Tony the pony из статьи Jon Skeet (msmvps.com/...epic-fail.aspx. А сам по себе коммент по стилю очень напоминает самый популярный ответ на SO: (stackoverflow.com/.../1732454/625594)

Erlang — так ли он крут?
Nobody cares
у нас есть Java для хардкора, и Groovy/Scala для всего прочего, зачем наступать на те же грабли, и идти непонятно в какую сторону? ну разве что б очередной топик «Erlang-программист последние полтора года ищет работу» содать разве что )

В целом качество статьи вполне соотвествует твоей грамотности :)
Гетто ДОУ :)

Не так с тобой, потому что судя по твоим ответам

ЛОЛ, а не кажется ли тебе что эту функцию замечательно выполняет OS scheduler?

мне с болью в сердце приходится признать, что образовательный процесс тролей на ДОУ затянется. Ты, к моему великому сожалению, не понимаешь, как скедулятся скала акторы и даже не понимаешь какие ограничения в ExecutorService. Куда тебе анализировать статьи по Эрланг, разберись сначала как в JVM скедулятся сущности.

Тут был мальчик 19 лет в математический проект, он перспективный.

Ну если на твой взгляд я не понимаю, то обоснуй свою точку зрения, обьясни каким макаром ты приплел актеры scala к дискуссии и что не так с OS scheduler, а то пока сплошные пуки в лужу, не гоже ЦТО таким заниматься.

Я же тебе уже всё расказал. ОС планирует скедюлеры пулов. В ОС ограничение обычно на 2000 потоков. Скедюлер пулов может применять разные страгетии переключения тасков. Таски — это обычно просто функции которые ты передаешь для планирования. Суть проблемы в том, что бы разработать механизм передачи (yield) управления обратно в скедюлер (который работает в потоке ОС) для того что бы он переключил на другую таску. В любых канкарент системах на одном потоке сидит много процессов\задач\актеров: JVM, Go, Rust, D, CLR, Erlang, whatever.

Так вот среди всех систем только у эрланг кванты времени можно более-меннее точно вычислить и контролировать. Это происходит потому, что ВМ Эрланга считает инструкции виртуальной машины для определения того, когда переключить на следующий процесс (это все происходит в рамках одного и того же потока ОС). Все остальные системы применяют различные стратегии yield, <b>отличные</b> от вытесняющей многозадачности (кванты времени), а значит не являются такими, которые поддерживают вытесняющих планировщиков.

Так тебе понятно, мой милый друг?

В ОС ограничение обычно на 2000 потоков.
Ясно, вся вера адептов эрланга как обычно строится на мифах.

Раздели размер доступного виртуального адресного пространства на размер контекста потока и ты получишь максимальное количество потоков в ОС.

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

Мы пришли к твоему еще одному фейлу, создать 20000 потоков ОС.

Раздели размер доступного виртуального адресного пространства на размер контекста потока и ты получишь максимальное количество потоков в ОС.
Расскажи мне, что ты именно подразумеваешь под «контекст потока»?
Ты же даже себе приблизительно не представляешь какова цена каждого потока в ОС, и его переключения контекста со вмеми страницами виртуального адрессного пространства. И почему их нужно создавать соизмеримо-равное количеству ядер.
Вопрос не в цене переключения потока, а в сравнении этой цены с планированием потоков в эрланге. У тебя есть бенчмарки? Или опять пуки в лужу?
Мы пришли к твоему еще одному фейлу, создать 20000 потоков ОС.
Мы пришли к тому что ты опять специализируешься по пукам в лужу, т.к. у меня вот прямо сейчас есть сервис который ранает 5к потоков в одной JVM.
5к потоков в одной JVM.

Неудивительно что ты ранишь 5К потоков, дали бы тебе 128 бит пространство, ты б и их потоками ОС забил :)

Такие кадры как ты до сих пор на собеседованиях спрашивают про lock(this) и остались в POSIX 1003.1c.

Открой уже для себя мир исчисления процессов и попробуй пописать на Scala, раз уже приковали к батарее JVM.

А что именно не так с 5к потоков? Может ты все таки соизволишь как нибудь хотя бы один раз ответить за свои слова, или будешь и дальше плодить пуки в лужу и фейлы(как например невозможность поднять больше 2к тредов)?

5000 потоков ОС. Да ты я смотрю крафтсман :)

Я ж тебе формулу вычисления написал, ты что делить не умеешь и не понимаешь что такое размер контекста потока ? Он в линуксе по дефаулту 8М кстати. Возьми 32 бита VAS радели на это число, возьми 64 бита тоже раздели. Измени это число в меньшую сторону запусти свою программу, поиграй с размерами в ulimit и увидишь, что ты в жопе, после того как это все померяешь на пропускную способность сообщений :)

У меня есть нехилые подозрения что твоя формула несовместима с жизнью, и я даже пытался тебе сказать почему, но Ок, в x86-64 возьмем виртуальную память в 16ТБ(цифру взял из википедии), я теряюсь понять что ты имел в виду под «контекст потока», но предположим это стек + какие то еще копейки — 10МБ, итого получается что можно запустить 1.5 миллиона потоков. Че сказать то хотел?

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

Узнай для начала сколько бит под это число отводиться в ядре, что бы казуса не вышло, архитектор ты наш )

Ясно, с формулой очередной пук в лужу получился. Так что там теперь с битами в ядре?

Ну запусти на нем 1.5 миллиона потоков :)

Что бы понять, что ты этого не сможешь сделать.

Может и не смогу, и что это доказывает?

Ты, что вообще упоролся там или просто бухой ?

Я лично понял, что чувак троль на ДОУ упоролся потоками не на шутку :) И это весело само по себе.

Ну повеселись своим недалеким фантазиям.

Признайся ты просто пизданул про 5K неподумав. Ибо если у тебя действительно есть хотя бы система-прототип с 5K потоков, то ты заслуживаешь реально отметиться в истории :) по премии Дарвина.

Гугл со своими Гошечками и Мозилла с Растом очевидно двигаются в тупик, вместе с Скала и Эрлангами всякими :) бгг

Та нет, 5к потоков реально крутятся на продакшн серваке. Я правда не улавливаю связь между 1.5 млн и 5к потоков.

Отлично, а скажи ты сам наархитектил такую мега-гипер-поточную-систему или уже получил от какого-то индуса ?

А ты не против если я скажем напишу статью про тебя, что некий чувак на ДОУ под ником реалити_хакер напидерасил систему на 5К потоков и считает, что это трушно. А потом дам тебе отзывы почитать про то что напишут люди.

Чисто что бы проверить, а вдруг не ошибся ли ты в своих расчетах ?

Я до последнего момента надеялся что ты таки получил это поделие от индуса. Но нет, хотя вообщем не странно ;)

А как бы ты задизайнил такую систему?

Нужно бы задачу поподробнее узнать. Но явно не с 5к потоков. Не скажу что железо не справится, если написать proof of concept, то работать будет. Но задача решается и более легковесно. Практически никогда не бывает валидных сценариев чтобы использовать 100500 потоков вместо, например, event-driven модели.

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

Для event driven системы тебе пришлось бы написать свой неблокирующий two phase commit драйвер к ораклу, mysql и адаптер к ИБМ MQ, а так же неблокирующий менеджер распределенных транзакци, который будет всем этим рулить, я же собрал все из готовых компонентов.. А теперь вопрос, нахера это нужно? Что бы ты выиграл перейдя к event driven архитектуре?

Даже если допустить что с нашим любимым ентерпрайзом не получится получить неблокируемые вызовы там где нужно, то все равно зачем 5к потоков одновременно? Executor Services не работает? У вас именно висящих потоков на блокирующей операции одновременно 5к?

Я уже здесь писал, что да есть ExecutorService у которого в пуле крутится 5к потоков, меньше нельзя потому что не хватает throughput что бы прожевать все мессаджи.

чё за мега реалтайм система?

Та ниче особенного, читает кучу сообщений из некоторого messaging middleware и пишет транзакционно в несколько баз данных делая при этом некоторую бизнес логику. В день получается 500млн транзакций.

Ну да, в котором 5к потоков, при этом есть 10 таких серверов которые делают работу в 3-ех датацентрах в разных концах планеты.

double blockingCoefficient = 0.9; //интенсивное I/O
int poolSize = (int)(numberOfCores / (1 — blockingCoefficient)
там или сверхпроц или явный расход ресурсов
как ты пришёл к выводу что 5K надо

Там большое latency при обращении к БД, потому что много запросов и БД географически раскиданы, для одной транзакции все запросы может занять выполнить пару секунд, если я буду держать мало тредов то просто будет недостаточный throughput что бы прожевать все сообщения. 5К я определил экспериментально, последовательно запуская систему.

Я ж тебе формулу вычисления написал,
Формулы это хорошо, в теории. А на практике: bit.ly/15a0PVW
Синтетика 2011 года.

UPD.

Он в линуксе по дефаулту 8М кстати.
Таки да, этот ваш линукс такое гуано, поставьте солярку, у нее с потоками все веселее.

Как то не очень радужно даже на 64 битах. Это если просто капасити мерять.

А если замерить переключение между тредами, то можно попасть в ад наверное :)

Как то не очень радужно даже на 64 битах.
Кстати, пример из реальной жизни. При прогонке тестов на 1 виртуальном проце + 4Гб памяти из них под джаву 2Гб, текли потоки (не убивались):
— линукс (подкручены юлимиты): краш ДжВМ на 3-4К джава потоков
— солярис: 8+К потоков, ДжВМ не лягла, но время сборки с 1 часа увеличилось до 1 час 30-50 мин.

Тоже мне бином Ньютона... Всем кто знаком с UNIX известно, что солярка по умолчанию под джаву заточена. Благо и то и другое продукты Sun. С Линухом надо же повозиться- мне кажеться не надо горячиться с выводами только на основании своего опыта, если конечно Вы не великий учитель всея IT..

Отвлечемся от срача.

Так вот среди всех систем только у эрланг кванты времени можно более-меннее точно вычислить и контролировать.
А зачем? Если ваш "поток"/"таск" (называйте как угодно) выедает много процессорного времени — это баг, его и исправляйте.
Все остальные системы применяют различные стратегии yield, <b>отличные</b> от вытесняющей многозадачности (кванты времени), а значит не являются такими, которые поддерживают вытесняющих планировщиков.
Как по мне это таки хорошо. Если у вас задачи содержат бизнес-логику, то путь выедают проц, будет проще заметить что тормозит, меньше затрат (в теории) на переключение и тд, то есть быстрее обрабатывается задача. Снова же если все упирается в количество потоков (а оно в любом случае упрется, даже Эрланг запускаетсо на железе с ограниченными ресурсами), ставим больше железок.
Упирается в ожидание в очереди, уменьшаем время работы тасков и/или добавляем обработчики.
Конечно же для коротких задач (тот же роутинг) это может быть по другому, но речь о бизнес-приложениях.
Ты кто, Бизнес-логик ? :)
Вообще-то я серьезно спрашивал, а вы так уныло сливаете :(

Шо сливать, ты даже до этого клоуна реалити хакера не дотягиваешь.

А ты еще и быдло оказывается.

Да ты расслабся, ты же круче Боди :)

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

Шо сливать, ты даже до этого клоуна реалити хакера не дотягиваешь.
Печально, сударь. Будет желание поговорить по теме — обращайтесь. А про 15К запросов можете и в ЖЖшечке повтирать.
Вам засчитан унылый слив, сударь.

Статья правдива и адекватна более чем наполовину. С большинством описанных факторов мы столкнулись на практике.
Структуры данных — да, они, наверно, расширились с тех времён, но всё равно для достаточно сложного состояния они сильно неудобнее аналогов.
Память — как уже сказал рядом, каждый достаточно толстый, но слабо нагруженный процесс эрланга это чудовищное прожорство. Реальную работу надо втискивать в малое количество сильнонагруженных процессов, иначе будут проблемы. А так втискивать — значит вводить неестественность в проекцию модели на реализацию.
JIT’а по факту нет. Иногда удаётся чуть-чуть сэкономить (процентов 20, когда ожидалось — в разы). Внутренняя VM плохо проецируется на реальные за счёт странных решений типа “а давайте у нас будет 1024 регистра”.
Случаи типа описанных с {ok,Foo}=... у нас происходили с завидной регулярностью.
От себя добавлю проблемы с синхронизацией нод (модуль global это аццкій адъ); с управлением входным потоком, без явного управления впадаешь в положительную обратную связь выедания всей памяти; с отсутствием приоритизации mailbox’а, приводящей к необходимости передавать срочные сообщения через ETS; и много прочего по мелочам. Плюс к тому кривизна всех имеющихся средств деплоймента, каждого по-своему.

Разумеется, и вкусности есть — и очень много. Но мои впечатления от состоявшихся проектов — очень смешанные. Минусов в сумме где-то столько же, сколько плюсов.

Да да, теперь я знаю от кого эти рассуждения. Когда Массив солюшинс развалились к нам приходили ваши люди и тоже расказывали про разваливающиеся кластеры и глобал. Говорили что RabbitMQ гавно, а Gproc ересь. При этом 2 месяца фигачили 45КБ бессмысленный ген_сервер пустышку. Я потом это на гпроц локальном переписал в 10 строчек. Для справки на Эрланге в 45КБ можно написать имплементацию Амазон Динамо.

{ok,Foo} = ... создают проблемы и ’query’ кейворд :)

Слышал, что ты неплохой специалист, но читая тебя такого впечатления не возникает. 1000 потоков на ядро :)

к нам приходили ваши люди
При этом 2 месяца фигачили 45КБ бессмысленный ген_сервер пустышку.

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

Слышал, что ты неплохой специалист, но читая тебя такого впечатления не возникает. 1000 потоков на ядро :)

О чём именно речь про «1000 потоков на ядро»? Чего именно потоков?
А твои наезды на чужой уровень оставь кому-то другому.

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

Это хотелось бы прояснить :)

Ну тема то про то что некто заспавнил 1000 потоков операционной системы на ядро

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

а ты вроде как пришел сюда защищать такой подход

Я вижу, ты очень быстро отвечаешь — настолько, что не остаётся времени подумать над тем, на что отвечаешь. Иначе я не могу объяснить такой вывод из моих слов.

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

и более того рассказал что делал что-то похожее.

Действительно, делал. Нарвался на описанные выше последствия, пришлось переделать.

В переделанной версии — основных рабочих процессов как раз по количеству ядер. Есть и другие, но не в безумном количестве и с дополнительными мерами (хранители конфигов, например, получают явный приказ сделать hibernate). Зато красота реализации пропала — «хотели, как лучше, а получилось, как всегда».

Тот коллега, о котором я говорил в соседнем комментарии, кстати, потом сказал «я предупреждал заранее, что так будет». Я уже к тому времени не помнил, предупреждал он или нет, но свою часть он написал (хоть и медленно) заранее с учётом описанных проблем, и его часть не тормозила.

А ну ок, все проянили. Я все неправильно понял. Та статья кстати гавно, ’query’ и еще претензии на отсувствие map, нельзя матрицы считать :) Это смешно просто.

Жаль что у тебя не получилось получить вау эффект от эрланга, думаю это оттасти произошло в вашем проекте Кластрикс потому, что у вас не было подобного опыта, вы наступали сами на грабли, не было docker, и все это было в основном построение инфраструктуры, а ее разрабатывать всегда не весело. Это не правила роутинга накидывать и делать конкретные проекты и видеть что вот оно идет и получается как все лихо.

У нас именно так, потому что мы слепили из стандарного эрланг стека все и оказалось что вау эффект пришел в том месте где его не ждали, в вебе. У вас тоже админка была, но у вас как-то все грусно было с ExtJS контролами и т.д. А так конечно писать свои очереди и DHT уже тоже поднадоело, а эрланг же как раз про такое.

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

Да, это так. Проект сильно вышел за пределы традиционно предполагаемых применений Erlang, несмотря на то, что при первом взгляде он очень точно им соответствовал. Это как раз и оказалось самым неприятным результатом — получить по носу там, где не ожидали. Вычистить последствия просто не успели.

А у вас получилось наоборот — вроде бы и не его исходно область (ну какой веб в телекоме?), но идеально попало на оптимальный путь для внутренних механизмов.

У Лапшина и у Валкина получилось как-то средне между нами — умудрились нащупать правильный путь без особых разрушений.

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

Dear Netch@ , посмотри на n2o. Вполне вменяемый фреймворк для веба. Мне реально очень понравилось.

К слову, проблема размеров стеков уже несколько лет как решается через так называемую «split stack» технологию. Если это было твоё основное возражение против ведения большого количества системных тредов, то его пора снимать.

А вот процесс Erlang, который при попытке аллоцировать при ресайзе своей кучи полтора гигабайта одним куском (потому что он иначе не умеет хранить основную часть своих данных) такого облегчения не получает. И вылететь полученному за пределы vsize полного процесса ноды оказалось ой как тривиально...

(Охотню верю, что у тебя нет такой специфики. Но она от этого не исчезает)

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

Но понтов при этом столько и непонимания что становится забавно. Классика :) Ты ему про канкаренси, а он тебе про свой гавнопроект.

Бабки на аренду сервака который держит 5к тредов это 200 баксов в месяц на OVH.

Ну это как со стюардессой и матросами на острове.

Очень хорошее сравнение. В целом ДОУ именно такой остров :)

Разобрались уже с ExecutorService ? :)
Теперь понятно почему JVM подсасывает ?
Есть еще вопросы, или закончился бред ?

Да нет, спасибо тебе, все встало на свои места, доу — это остров, мы — матросы, эрланг — стюардесса, добавить нечего.

Создавай потоки, ExecutorService.
Теперь по крайней мере понятно в чем ты лох.
5000 потоков архитектура — это достойно ДОУ :)
Следующий.

Теперь по крайней мере понятно в чем ты лох.
5000 потоков архитектура — это достойно ДОУ :)
Лох — это судить о архитектуре не зная даже зачем это нужно. Мою задачу ты бы на эрланге не решил в принципе скорее всего.

Ну так расскажи о своей задаче, которая требует 5000 потоков ОС, Мистер, ExecutorService.

5000 потоков — надежная и оправданная архитекура для 16 ядерных систем :)

Клоун.

Пишу на Erlang чисто для себя всякую фигню, потому что мне просто нравится, декларативный подход к написанию ПО, единождое присваивание, функциональщина, распараллеливание да и вообще это понятная и простая штука Erlang/OTP+Geany+Ubuntu и можно афигеть как интересно в нём копатся ! Если бы в нашей стране была бы в нём востребованность, хоть не большая, смело бы ушёл в Erlang разработчики ещё на втором курсе универа, и пофиг на то что он крут или не крут или падает у него виртуальная машина (это уже давно исправили) просто занимался бы тем чем нравится !

Отвечу вам как есть с мой точки зрения : Scala — НА МНОГО СЛОЖНЕЕ чем Erlang, у неё примесь ООП+функциональщина, очень много заумных вещей, она не заточена как Erlang (язык параллельных процессов) для создания распределённых вычислительных систем, работы с SMP, многоядерности и (лично мне) понятного декларативного подхода ! Вот где-то так ...

Scala — НА МНОГО СЛОЖНЕЕ чем Erlang, у неё примесь ООП+функциональщина, очень много заумных вещей
Ну тебя ведь эти заумные вещи никто не заставляет юзать, я вот не юзаю и чувствую себя сухо и спокойно.
она не заточена как Erlang (язык параллельных процессов) для создания распределённых вычислительных систем, работы с SMP, многоядерности и (лично мне) понятного декларативного подхода !
Это ерунда какая то, jvm намного более заточена под эти дела, начиная от производительности, happens before behavior consistency и заканчивая в десять раз большим количеством примитивов, структур данных и либ.
Это ерунда какая то, jvm намного более заточена

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

В Akka, Clojure, Go, Rust, D тоже самое.
Эрланг уникален не этим.

Чем уникален эрланг знают только адепты эрланга.

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

Эрланг скелюдит актеров используя модель вытесняющей многозадачности основываясь на подсчете выполненых инструкций. Остальные системы используют разлиные стратегии yield в скедюлер. Akka например делает yield после определенного количества обработаных сообщений актером. Есть и другие стратегии: Haskell, например, делает yield при выделении памяти в heap.

Другая уникальная особенность Эрланга заключается в том, что на каждого актера свой уникальный heap и GC производится независимо и паралельно, вследствии чего в Эрланге не только мягкое планирование, но и плавная сборка мусора всегда.

Спасибо ! Довольно познавательно, будем разбиратся дальше ...

Эрланг скелюдит актеров используя модель вытесняющей многозадачности основываясь на подсчете выполненых инструкций.
ЛОЛ, а не кажется ли тебе что эту функцию замечательно выполняет OS scheduler?
Другая уникальная особенность Эрланга заключается в том, что на каждого актера свой уникальный heap и GC производится независимо и паралельно, вследствии чего в Эрланге не только мягкое планирование, но и плавная сборка мусора всегда.
Не на актера а на процесс, и как это делает сборку мусора плавнее?
ЛОЛ, а не кажется ли тебе что эту функцию замечательно выполняет OS scheduler?

OS Thread має space & time overhead.
У вінді це: Context size, x64 -> ~ 1240B
User-mode data: 1 page, exception handling chain, etc
User-mode stack — 1MB, kernel-mode -> 24KB (x64)
DLL attach&detach notifications

Врахуй ще context switch при зміні процеса.

Не вчитувався у вашу дискусію, але здається що тут є простір для оптимізаціі

User-mode stack — 1MB
Это можно выставить руками какой захочешь. В моем сервисе в котором крутится 5к потоков кажется выставлено в 200кб и этого вполне хватает. Остальное все — копейки.
Врахуй ще context switch при зміні процеса.
Все бенчмарки которые видел включая боевые джобы говорят что он не кретичен если речь идет о тысячах потоков.

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

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

Собственно переключение потоков — совершенно без проблем. Проблемы в другом месте — в GC на раздельных кучах — про это я писал рядом.

User-mode stack — 1MB,

Там, где это проблема (обычно на 32 битах) — split stack поможет.

На 64 битах на сейчас VM можно считать неограниченной.

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

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

Столкнувшись с таким, мы вынуждены были отказаться от персонального процесса на сущность и повторить тот же «подвиг», что Erlang по отношению к pthreads — сделать несколько толстых процессов (по количеству ядер) с деревьями состояний в них. Этот вариант оказался устойчивым.

Задачи обслуживания кратковременных соединений по вебу действительно не способны показать эту проблему — за короткоживущими процессами очистка происходит таки вовремя.

И что у вас тоже система 1000 потоков на ядро ? :)

В Erlang виртуальная машина не создаёт отдельного потока вычислений операционной системой для каждого процесса, процессы создаются и выполняются внутри самой виртуальной машиной и не зависят от операционной системы, в результате чего создание процесса занимает микросекунды и время создания не зависит от числа уже запущенных процессов, по этому в Erlang процессы очень легковесны (байты), а вы мне тут рассказываете про ваши Джавы в которых для каждого процесса выделяется ---отдельный поток--- операционной системой ...
В джаве заменой легкому потоку из эрланга выступает ExecutorService и куча надстроек над ним, например в скале когда делаешь: val l = future { ... } вычисление выполняется паралельно в заблаговременно заготовленном пуле потоков без создания нового.

Вы слишком крут, мне с вами не тягатся ...

Scala’s actor-based concurrency library was
heavily inspired by Erlang.© by Martin Odersky, Lex Spoon and Bill Venners из книги Programming in Scala

Но к вышеупомянутым futures, легким потокам и ExecutorService актеры отношение имеют очень отдаленное.

Упоролся своей джавой ? Уже 100 сообщений про ExecutorService :)

Потоки пула потоков планируется ОС, а легковесные сущности планируются в цикле везде. Иди почитай документацию на свою джаву, неуч.

Про фючерсы еще что-то рыпаться :) Ох.


Я так и не понял что именно тебе не понравилось, наверное батхерт.

Если бы в нашей стране была бы в нём востребованность
Эээээ, то че выходит, что жаба у нас популярна внутри страны?
Те бодишопы продают внутрь страны?

Внутри страны у нас только делфи неплохо продается.

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

Я уже молчу про долину, где все уже давно на скалу перешли.
Которая работает в той же ДжВМ, на тех же либах :)
Был 21 августа на конференции в Люксофт, уже даже Дойче Банк переходит на скалу.
Шо таки переходит? Весь ДойчеБанк?
А почему на унылую скалу, а не на кошерный ерланг?

Богдан, если вам не нарвится Эрланг, пишите на Скала.
Вы будете зарабатывать больше и писать меньше.
Вам будет более приятно.
Мы хотим что бы вы были счастливы.
Если вы не обретёте счастья с Эрланг, обязательно его
попытайтесь отыскать в Скале :)

если вам не нарвится Эрланг,
«Не нравится» тут не очень подходит, скорее «не проникся»
пишите на Скала.
Вы будете зарабатывать больше и писать меньше.
Вам будет более приятно.
От пока не более приятно.
Про зарабатывать — это совсем отдельная история.
А от про писать меньше. В 2013 году-то? В мире где есть ИДЕА? В мире где есть снипеты? Шо на скале, шо на джаве, шо на эрланге написание кода занимает «1-4 буквы и Таб» :)

Одного архитектора любителя POSIX 1003.1c мы уже раскусили. Нужно будет еще с тобой провести разговор про 1-4 буквы :)

После стольких эпик фейлов это ты самораскусился. Не удивлюсь если окажется что ты и на эрланг только хелловорлды писал.

ExecutorService, POSIX 1003.1c, 5K Threads in JVM! :) Только олдскул, только хардкор. Угораем по семафорам, разделяемой памяти и переключению стеков :) JVM! Java! ExecutorService! lock(this)!

троллебот совсем сломался похоже.

Нужно будет еще с тобой провести разговор про 1-4 буквы :)
Ну разговаривайте. 3 буквы могу озвучить сразу: n-e-w

Это был сарказм.
Жаба мне побоку.

Ну и хватит тут доказывать, что эрланг не верблюд. Тут хайлоад люди держат на 504 ошибке и им норм. Обратное они не показали, пока что.

Да для Украины с ее тысячними аудиториями и PHP достаточно. Просто на ФП языках даже сайты быстрее делать.

не, я честно таки долго пытался не ржать

но тут

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

уже не выдержал

вы заходите почаще, Максим
пишите побольше, а то банальные leenjux фрики — это так пошло

и уйутненькая у вас прекрасна, не забрасывайте, пишите

Ну вы же понимаете о чем я ? Или нет ? Я разве сказал внутри страны ? Откройте work.ua, rabota.ua, вакансии на DOU и посмотрите вакансии :

Java — 1000
C# - 800
Ruby, Python — 600 (вместе)
Erlang — 1

Так вот 1000 > 1, тоесть уже видно что Java популярней чем Erlang ?
— Это значит что в нашей стране работодатель больше заинтересован в Java разработчиках !

Тоесть хотят у нас !!! Java !!! (это и есть востребованность) и кандидату глубоко насрать на кого работать на Россию, США, ЕС, чурок с автоматами, ибо кандидат будет работать у себя в городе в офисе где ему дали задание сиди и трахайся, потрахался получи деньги ...
Причём тут ваше: «внутри страны» ???

Да Сергей, вы правы, не доглядел я, всё таки ДВЕ вакансии по Украине ! Аж две по ВСЕЙ стране ! Erlang набирает популярность :)

У нас вообще ни одной вакансии по asia-Pacific region...Украина модная :(

Попробуйте создать 300 000 канкаренси примитивов и послать броадкаст используя вашу любимую виртуальную машину (CLR, JVM) уложившись по времени в 1 секунду на вашем ноутбуке:

www.youtube.com/...Y3TMUcgQ#t=400s

не надо быть гением математики, чтобы поделить 50 миллионов на 48 и сравнить результат с 300 000

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

Это при том что производительность с количеством ядер обычно растет не так что бы линейно

Я знал что на эрланге пишут нищеброды

На эрланге работает свич Эриксона, который держит 10 миллионов полных LTE потоков. Этого свича достаточно, что бы покрыть пол Европы. Таких штук на планету нужно несколько. Поищи в инете, сколько он стоит.

Я так понял есть пару таких свичей на которые эрлангеры молятся? В то время как джаверы менеджат тысячи серваков.

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

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

В теории ты можешь получить теоретическую эквивалентную производительность TCP. Но за счет более софтового и риал-таймового GC эрланг плавнее показывает динамику перформанса, чем пилообразный график JVM. Поэтому в реальности все наоборот, просаживается Java. Но JVM быстра — это есть. Но не во всех языках JVM есть продукты способные потягаться с Erlang. Только http-kit в качестве Веб-сервера и akka как процессо-заменитель.

Но за счет более софтового и риал-таймового GC эрланг плавнее показывает динамику перформанса, чем пилообразный график JVM.
cmon, в джава наплодили целую кучу гарбадж коллекторов под совершенно разные нужды. Пилообразный GC это trade off в сторону row performance & throughput, есть и другие, совершенно не прерывающие работу ВМ, и даже с хардварной поддержкой.
Но не во всех языках JVM есть продукты способные потягаться с Erlang. Только http-kit в качестве Веб-сервера и akka как процессо-заменитель.
Тягаться в чем? Передавать 100тысяч абстрактных мессаджей в секунду это сильно узкая задача, в каких то других областях ерланг в бенчмарках либо не учавствует либо сливает

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

maxim.livejournal.com/392587.html

Трепаться смысла нету.

Я в отличии от тебя лично замерял многие современные веб сервера
А могу я поинтересоваться какие java сервера ты замерял перед тем как трепаться? Не кажется ли тебе что мегатормозная кложа как то не репрезентативна для того что бы судить о производительности JVM?

Это какие Томкат, Джетти, Нетти и сервлеты ? :-)

github.com/...rver-benchmarks

Подсасывает у Кложи все, кроме Ковбоя.

И что сказать хотел? Там весь код на кложе, с джава/скала сравнения нету.

Какая разница на каком языке написан этот код:

github.com/...ty8/servlet.clj

javax.servlet.http

Еще есть троллинг-материал ?

Тут несколько аспектов, первый — это микробенчмарк — то о чем я говорил, никому нахер не интересно сколько тысячь хелловорлдов выстрелишь за секунду. Людям интересно за сколько будет делаться какая то работа, и тут кложа с эрлангом сасут.
Во вторых ты уже сравнил генерируемый байт код и убедился что он идентичен?
В третьих и ежу понятно что асинхронный фреймворк будет выстреливать больше хелловорлдов в секунду чем синхронный, т.е. реально здесь было интересно посмотреть только на нетти, но кода для него я не вижу, цифры непонятно из какого пальца высосаны, а ты видишь?

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

Одни могут взять и все сами проверить, а другие не могут, потому что не умеют; нет времени; не хотят; не та область интересов. Поэтому их удел — это отрицание всего в интернете.

Если тебе интересен Веб и ты занимаешься ним, ты разберешься и сделаешь для себя выводы на чем уходить в продакшин исходя из: навыков своей команды; приверженности к языку или платформе; или сугубо субъективным показателям — количество скобочек на квадратный сантиметр монитора.

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

maxim.livejournal.com/392587.html
Померять то такое. В другие системы вы, я так понимаю, не углублялись, но вот про ковбой интересно:
Чем объясняется зубец 26-29-30?

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

Многие нужные вещи из Erlang реализованы в последнем .NET, например механизм task msdn.microsoft.com/...tasks.task.aspx

Синтаксис чуть другой, легкость использования и результат тот же.

А в Java только сторонние фреймворки позволяют это сделать, в стандарте Java этого нет.

каг бы он не 15 лет в Java. до этого все свой java.util.concurrent
.* писали.

Это больше к вот этому msdn.microsoft.com/...y/2e08f6yc.aspx

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

Это больше к вот этому msdn.microsoft.com/...y/2e08f6yc.aspx
Та нет, это небольшой костылек на тему семафоров, а в джаве это полноценный механизм вроде эрланга с пулами потоков и разными стратегиями их менеджмента.
А граф тасков элементарно получается с помощью futures.

Можно подробней кто будет рассказывать миру о чудо Эрланге. И кто сказал что он достоин, что то рассказывать кому либо..

Либо ты редактируешь каммент, либо я одной строкой siege -c50 из Турции ложу твой Армянский Веб-магазин написанный на PHP :-)

Редактировать не буду:), ДДОСить ты меня конечно можешь. Жаль, что в ответ не выйдет. Уже проверил, 25 wmz в час. Радует, что деньги вернули:)

Немного про крутость Эрланга.
Картинка до i.imgur.com/9KZocPS.jpg и картинка после i.imgur.com/oCIXxaU.jpg

А что по ординате?

На тому сайті 1С зарулює JavaScript )))))

На тому сайті 1С зарулює JavaScript )))))
Что вполне логично.

Так, як графік показує кількість ваканцій з HeadHunter.ru, то так, логічно.

Це як порівнювати старе вино і дешеве пиво.

а ещё я слышал, что бывают плохие года в плане урожая винограда и что вино превращается в уксус

Эти графики не репрезентативны, ибо:
а) самый популярный язык это 1С
б) отсутствует Си

Эти графики не репрезентативны, ибо:
а) самый популярный язык это 1С
А какой вы думали будет на просторах СНД?
б) отсутствует Си
Его просто сложно считать. На репрезентативность не влияет, ибо там не в процентах, а в абсолютных числах.

Java и C#. А знание 1С пишет каждый второй продавец, каждый бухгалтер, логист и прочее. По этому методика подсчета вызывает у меня некоторые сомнения.

«Я понимаю фанатов «C#» или той же «Java», но поймите: ваши языки, при всем уважении к их влиянию на девеловпер-культуру ХХ века — это, де факто, голая развлекательность, не имеющая под собой реального подтекста. Да, код джавы типизирован и «цепляет», «С++» техничен, что дает т.н. «драйв», но эти языки не идут дальше простой «услады для глаза». Их задача была — развлекать публику, но никак не воспитывать программиста, не «пробивать» его до глубины души, пробуждая в нем индивидуальность. Erlang же — совсем другое дело. Это действительно УНИКАЛЬНЫЙ язык, синтезирующий, с одной стороны, простоту и понятность для целевой аудитории, с другой — невероятную глубину мысли и чувства. Творчество Joe воспринимается и на подсознательном уровне, когда, загрузившись много раз, ты незаметно начинаешь открывать в ней все новые и новые смысловые и эмоциональные слои. Вместе с таким языком ты открываешь и себя самого, и мир вокруг себя; ты растешь, ты начинаешь смотреть на вещи хоть чуть-чуть, но по-новому. И я убежден, что именно такие языки и нужны современной молодежи, у которой рост тела зачастую опережает рост души. Времена «голых развлекателей» вроде «java» и «C++» прошли. Нам действительно необходим новый ЯП. Такой, который поможет сохранить и приумножить культурное достояние каждой юной личности и всего народа. Такой, как Erlang.

Какая нахрен разница, какой язык? За него не платят на Украине НЕ-ПЛА-ТЯТ!

Для души же...

Ну а вдруг наступит просветление и ты увидишь код Матрицы?

А кстати кто нибудь рассматривал такие нердо языки типа хаскеля, лиспа и т д? Ну просто для расширения кругозора/ознакомления с другими практиками?

Я вот кложуре пинаю по тихоньку...

Для души же...

Для души лучше пойти в музей, имхо. Или решить пару — тройку задач по математике.

на seek.com.au 1(!) упоминание ерланга. в вакансии гугла. В списке возможных скилов
vs 3,196 jobs containing java

воспитывать программиста
Несколько десятилетий этим занимался LISP, а точнее Scheme.

ох щи, видимо не обошлось без полиягод...

Нам действительно необходим новый ЯП. Такой, который поможет сохранить и приумножить культурное достояние каждой юной личности и всего народа. Такой, как Erlang.
стихи на Erlang’е пишут? — нет? — тогда какое нафиг культурное достояние :)

PS: UPS, не там нажал «ответить»

Зачёт) Но всё наоборот: C# и Java — это, де факто, и есть настоящие промышленные языки, что и доказывать то особо не надо. А всякие Хаскели и Эрланги — это для узкоспециализированных и задач и джас фо фан.

Хочется верить, что это просто цитата вырванная из какой-то «эрланго-библии», а не реальное мнение и мысли живого человека.

Само по себе знание продвинутого языка не делает тебя лучшим программистом, когда-то я тоже дрочил на крутые языки, LYAH прочитал, потом начинал RWH, вот только от языка самого по себе очень мало толку, поэтому забив на изучение «крутых» языков начал изучать алгоритмы, базы данных ( оптимизацию запросов, индексы и прочая магия), протоколы, когда-нибудь доберусь и до серьезной математики. Так вот, я уверен что знание этих дисциплин сделало меня лучшим программистом чем когда я занимался функциональным онанизмом.

p.s. Поговорил с пастой

3-й раз на форуме вместо раскрытия комм. нажимаю Поддержать. Но так красиво написано, что я бы не отозвал выбор, даже если бы была возможность :)

Есть возможность отозвать выбор — нажмите поддержать ещё раз :)

Спасибо, это у меня дома у Firefox настройки слетели, а я и поверил. Да, действительно все работает.

у меня двоякое отношение к erlang. с одной стороны про него все время пишут, какой он весь из себя устойчивый. с другой стороны , при использовании rabbitmq с , ну средней загрузкой, возникали ситуации «залипания» — сервер работает, законнектиться нельзя. оказалась нечистая реализация сокетов (хотя вроде бы не студенты писали) .
ну в общем поставили из транка, вроде все нормик уже больше года, но осадочек остался

Кроль это не та штука, что бы взяли и работать. Он капризный, с ним нужна экспертиза.
Вот тут, например, показано, почему мы остались на 2.7.1:

doxtop.livejournal.com/189336.html

и да. как ЯП он мне не нравиться. сильно уж «неправильно» там с фигурными скобочками

их там вообще почти нет, если брать по отношению к тому же php :)

Тема (и комменты к ней) выглядит как набег диких ЖЖ-троллей на трололо-заповедник (форум ДОУ).
No pasaran! :)

Мы решили потролить ДОУ и устроили уникальные Эрланг курсы в Киеве.

Мы решили потролить ДОУ
Пока уныло, сударь. Мало лулзов.

Кастую сюда призыв эрланг-фанбоев с последующим срачем о Erlang vs Всё остальное, Функциональщина vs Императивщина и прочими кошерными вещами!

Вброс: Erlang не нужен.

Erlang недостатньо чистий. Haskell, тільки Haskell.

Haskell для детей, объяснять что такое System F. Настоящие бородатые дядьки доказывают корректность своих программ с помощью Agda, Coq, Epigram и Idris.

OCaml, Haskell, Scala — все это прекрасные ML-подобные языки, которые могут помочь избавиться от гнета и депрессии императивщины. Всем, кто хочет перестать писать лапшу и начать жить, следует обратить на них внимание.

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

Erlang и Scala — эта два динамично развивающихся рынка ФЯП.

Всем, кто хочет перестать писать лапшу и начать жить, следует обратить на них внимание.
Я пишу на джаве и не пишу лапшу. Что я делаю не так? Переходить на эрланг все равно?
OCaml, Haskell, Scala — все это прекрасные ML-подобные языки, которые могут помочь избавиться от гнета и депрессии императивщины. Всем, кто хочет перестать писать лапшу и начать жить, следует обратить на них внимание.
F# тоже ничего, не считая скрещевания .net типов с oCaml типами, по началу сложно понять где что использовать (по факту оКамловские использовать кошернее).

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

А если задроты-программистишки работают в инвестбанках ?

Сравнил Кадырова и программиста из инвестбанка.

На аудиторию какого уровня рассчитан курс, а-то ну совсем не понятно. :)

Любой кто знает, что это такое и знает в общих чертах как этим пользоваться:

— Компьютер: Windows, Linux или Mac
— Почтовый клиент: Outlook Express aka Live Mail, Apple Mail, Claws Mail
— Web Browser с поддержкой WebSockets
— vi, emacs или FAR
— git
— GitHub.com аккаунт

Для уточнения и полной уверенности — уровень теоретической подготовки в Эрланге значения не имеет?

Абсолютно ненужно. Клац, клац и впродакшен :-)

На эрланге, к сожалению, не так много вакансий. Поэтому, смысл его изучать?

а также мало предложения -> больше денег, например

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

карточную игру или нарды за месяц на флеше нереально.
Смотря какого качества код будет, на омнокодить можно и за две недели
Фактически Flash умирает,
Давно умер, по крайней мере у меня на десктопе
Поэтому мы решили разрабатывать игры на JavaScript,
А как защищаете код от посягательств ?
программисты менее пафосные
В точку. Все флешеры которых я видел считают себя рок звездами от программирования
найти вменяемого человека способного написать карточную игру или нарды за месяц на флеше нереально
Ну почему — же нереально..40баксов/час и я тебе порекомендую несколько вменяемых желающих. С опытом.
Фактически Flash умирает, программисты на Flash просят слишком много денег
Два противоположных по смыслу высказывания в одном предложении. Если флеш умирает, почему программисты просят больше денег. Вакансий то мало, гораздо меньше, чем джаваскриптовых.
программисты на Flash просят слишком много денег
Разве три несчастные штуки баксов в месяц это много? Попробуй тогда Java — программиста нанять. Там где с флешером обсуждение з.п. заканчивается, с Java программистом только начинается разговор.
разрабатывать игры на JavaScript, программисты менее пафосные, делают быстро, работает лучше и везде.
Без обид, но я видел очень мало достойных внимания игр на JS. Ужасный язык сам по себе + отсутствие вменяемых средств для разработки. Абсолютно то же, что коллега делал несколько месяцев на JS, я сделал на Flash за месяц.

p.s. Признаком менеджера игровых проектов в частности и продуктовых вообще, является рассказ о зажранных программистах.

В этом письме я хочу предостеречь человечество от той роковой ошибки, которую совершил я; от той ошибки, которая привела меня к последним минутам моей жизни. Возможно вы подумаете, что я сошел с ума, но знайте — это не так. Все началось с того, что я вернулся вечером домой, вернулся уже слегка навеселе, устроился в любимом кресле у камина, закурил трубку и взяв в руки ноутбук открыл ДОУ. В первом попавшемся мне на глаза треде некий человек предлагал скачать Ерланг, что я и решил сделать; о, если бы я обратил внимание на комментарии вроде «ПОТСОНЫ НЕ КАЧАЙТЕ ТАМ ПАРАЛЕЛЬНЫЕ ПРОЦЕССЫ И АСИНХРОННЫЕ СООБЩЕНИЯ У МЕНЯ БРАТ УМЕР». Нет же, я не стал даже их читать, я смело скачал файл, распаковал его и... И я решил налить себе еще немного виски перед тем, как начать программировать. Пока я отходил за виски, за компьютер сел мой брат. О, это была его роковая ошибка: в Ерланге видимо сработала тайм-бомба и компьютер взорвался озарив дом светом ядерного гриба. Мой брат, царствие ему небесное, погиб сразу же. Сейчас я лежу в больнице, у меня лучевая болезнь и рак мозга. Жить мне осталось всего несколько часов, а может и того меньше. Сейчас я допишу это письмо и постараюсь его выкинуть в окно, я надеюсь его кто-нибудь найдет и разместить туда, откуда я скачал файл. Быть может оно спасет еще ни одну жизнь. Прощайте...

Не рекомендую использовать Erlang. Очень мало конференций в отличии от ruby и javascript. Когда покупаешь новый iphone приходится ждать полгода и более чтобы пойти и зарисоваться с ним перед другими, к тому времени и остальные уже успевают купить себе даже ipad и футбоку с оленями.

Используя Erlang невозможно прокормить семью, в Ruby On Rails критические ошибки разработчики добавляют на постоянной основе, заказчики приходят к тебе за обновлениями и ты всегда можешь им впарить новый ненужный AJAX виджет, даже просто версии ruby устаревают чтобы можно было по новому переписывать все заново и брать за это деньги. Сайты клиентов превращаются в тлен быстрее чем вы успеваете поменять JavaScript фреймворк для AJAX виджетов. На Erlang система может работать годами, они просто разоряют разработчиков.

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

хочешь, чтобы ДОУ внесли рейтинг рос реестра запрещеных сайтов?

Erlang, это путь в никуда, лучше самоубийство.

На Доу так много пользователя из Рашки?

Лол, это таки случилось.

«Апчхи! Извините, у меня аллергия на чушь» :) Время, эмоции и энергию затрачиваемые на переживания по поводу того, что программистам не останется больше чем заняться, можно направить в в более конструктивное русло.

В высоконагруженных проектах, часто упоминаемая надежность Erlang/OTP — не прихоть, а необходимость. Не Erlnag, так какая-то другая зверушка.

И вообще — как можно сравнивать RoR и Erlang?

Первое, с чем сталкивается новичок в Erlang — совершенно непонятно, как на экторах код распараллелить. И еще непонятно, зачем было делать вызов методов посылкой сообщений, типа Smalltalk. Да и непонятно вообще, зачем Erlang нужен, ведь экторы в 1973 году еще были придуманы, их их можно вообще и на Java реализовать. Очереди сообщений ведь легко реализуются — поднял ActiveMQ на отдельном хосте, подключил java библиотеку, заиспользовал JMS стандарт через Spring Integration, и поехали. И тоже на разных ОС будет работать. Изоляция между тредами есть, ну в одной виртуальной машине исполняются, ну и что. Это же треды, не процессы, тоже легкие. Нафигачил большой пул тредов — и вперед. И еще Erlang VM медленнее, чем JVM, а тут еще эта посылка сообщений. В общем, сомнительно это, не знаю, кто таким сможет пользоваться. Они еще, говорят, как-то от состояний избавились. Есть у меня ощущение, что они что-то не то делают...

Уже все есть — akka.io

Хоть либа изначально скаловская, но биндинг к яве поддерживается паралельно.

Ага, а JMS вообще очень давно был, и никуда и не девался.

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

Ну расскажите в чом же там разница.

Мне почему-то кажется, что если бы ответ на этот вопрос интересовал больше чем обычный форумный трололо. Его было бы проще найти в гугле по запросу akka vs jms или вот тут doc.akka.io/...ocs/akka/2.1.2

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

Очередь сообщений сама по себе это просто часть модели актеров. Кроме того там управление потоками, fail-over и т.п.

Например — создавая инстанс актера программист может не заботится об синхронизации инкапсулированных в него структур (инстанс актера всегда однопоточен, хоть в принципе к конкретному потоку и не привязан), может не заботится о потоках которые будут выполнять код запущенных актеров (сколько потоков запускать, в каких из них выполнять код конкретного актера — это дело akka).

Была у меня как то задача — приходят сообщения и их надо разбросать по потокам обработчикам, но у каждого сообщения есть определенный ключ, так вот сообщения с одинаковым ключем должны обрабатываться в той же последовательности как и пришли (то есть всегда в одном каком-то потоке). Решилось это с помошью экзекуторов, ConcurentLinkedQueue, wait-notify — вобщем ничего ужасного но много буков было.

А можно было бы использовать akka и строчек 5 конфигурации роутера сообщений.

Мне друг сказал, что на Элранге можно работать с сокетами. Я купил диск на базаре с Эрлангом, а он не запускается. Даже антивирус его не определяет. Вот Яваскрипт тема. Еле диск на базаре вернул...

Erlang не крут. Мы сначала сделали всю бизнес-логику на нём, купились на обещания, что он позволяет сделать отказоустойчивый сервер, но при росте нагрузки всё стало падать, клиенты не могли установить соединение. В итоге переписали на Node.js+MongoDB, стало всё намного проще и стабильнее. Но писать на Javascript не очень приятно, так что выбрали Clojurescript. Проблемы все прошли.

В итоге переписали на Node.js+MongoDB, стало всё намного проще и стабильнее
А как же SMP? :)
mtreskin.metalkia.com/post/115
А как же SMP? :)

Это «ад и содомия»

SMP не панацея. На каждом ядре запускается Node.js и имеем ту же самую загрузку всех ядер.

Вот именно. Чего все так к этому SMP прицепились.

>>> mtreskin.metalkia.com/post/115
О боже, хочу писать на Ерланге! Слава Ерлангу!

Facebook использует для своих чатов при миллионах пользователей, мы написали систему реального времени(см am.ua) работает на примитивном PC держит нагрузку порядка 1000000 запросов в день( не помню, чтобы после отладки когда падал) и т.д. Может все таки проблемы в умении и знании?

12 сообщений в секунду. Стыдно такие цифры называть.

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

У нас вебсайтик держит 15 тысяч сокет соединений в секунду.

Афигеть, это ваш сайт компании ?

А какая это дневная аудитория примерно? Миллион уников? Что за сайт, если не секрет?

И что, содержимое кошелька тебе своего еще показать ? :)

И что, содержимое кошелька тебе своего еще показать ? :)
Ну тада ясно. У сайта ровно один уник, ab называетсо :)
И что, содержимое кошелька тебе своего еще показать ? :)
хамство :-)

А эти 15 тыс. соединений из кошелька идут? Не уловил связи.

:( там человек вступил в реалити_хакера и сейчас злой.

Я тоже не уловил как ты связываешь капасити и посещаемость :)

Я просто пытаюсь добраться хоть до какой-то конкретики. А то мой булшитометр зашкаливает в этой теме.

Ты ж был на конференции и видел и слышал про цифры. Какие цифры тебе еще нужны ?

Ну хорошо, в пике будет 120 (на самом деле намного меньше, но пусть так). Всё равно мало.

Чего мало:)? По сравнению с чем? Ответе пож. на простой вопрос: сколько у Вас конкурентных запросов в секунду обрабатывает база MongoDB.

Достаточное количество запросов

Да, полностью.

Так переходите на Эрланг и во фронтэнде ;)

Не совсем понял ,что Вы имеете ввиду? Вся бизнес логика, формирование кода(html, json и т.д.) для клиента управляется Erlang-ом. Основной веб-сервер yaws написан(не нами :)) на Erlang и С. Собственно Erlang/OTP — это Erlang и С. Я даже не знаю как обойтись полностью без С при работе с системными вещами:)

А, так вы вообще молодцы. Не хотите написать статью как у вас эрланг в вебе и про свой опыт внедрения Эрланга, а мы будем эту статью и вашу компанию и вас пиарить ?

А я уже написал:) одну., типа hpc-ua.org/...ceedings/28.pdf, она наверно частично отвечает на вопрос как в Вебе. А вот опыт внедрения, наверно скоро напишу-частично уже написал. Счас пишу в основном презентации для инвесторов.

Эту статью я читал. Напишите про опыт внедрения Эрланг в am.ua.

Написано, что JSON у вас отдает Server:Jetty(9.0.0.M1). А веб страницы Server:Apache/2.2.15 (CentOS).

Вообще то, если Вас интересует удаленно узнать как у нас там реально устроенно, скорей всего не выйдет. Мы же не дети в песочнице играть — там все специально выглядит довольно запутано :). Если у Вас серьезный интерес узнать как все устроено, то это надо обсуждать не здесь и не так..

Вам не кажется что проблема не в технологии, а в поварах которые готовили с помощью нее? Погуглите про NINE nines reliability.

Проблема может быть и в пресловутой тормознутости эрланга.

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

Но ведь от этого эрланг тормозным быть не перестанет?

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

Всегда любил доу за то что какой-то Страуструп здесь не авторитет, так теперь еще и инженеры Ericsson похожи на мошенников ;)

Инженеры не эриксон, а бритиш телеком, а инженеры эриксон как раз в эти цифры не верят:

The 99.9999999% availability figure is an often-quoted but fundamentally misleading statistic. Mats Cronqvist, one of the AXD-301 team members, gave a presentation (video) (which I attended) at the 2010 Erlang Factory conference in San Francisco, discussing this precise availability statistic. According to him, it was claimed by British Telecom for a trial period (I believe from January to September 2002) of "5 node-years" using the AXD-301. There were 14 nodes carrying live traffic by the end of the trial.

Cronqvist specifically stated that this is not representative of the entire AXD-301 history, or Erlang in general, and that he was not happy that Joe Armstrong kept quoting this, leading to overblown expectations of Erlang's reliability. Others have written that five nines is a more realistic figure.

Презентация: www.slideshare.net/...rysf-bay2010matscronqvist

Снимаю шляпу, был неправ

Подписаться на комментарии