> Зачем вам ребар и мейкфайлы, если есть микс? Они не нужны.
Да тут как посмотреть. Я, например, не уверен, нужен ли мне микс, когда есть ребар и мэйфайлы. Они же абсолютно эквивалентны.
И вот именно этот подход «зачем X и Y, если есть Z, который наш» в эликсире и его комьюнити совсем не нравится. Например, «зачем нам старый source file layout, мы запилим свой, абсолютно несовместимый». «Зачем нам встраивание в pure erlang проекты» туда же. Мне гораздо ближе подход clojure — «мы сделаем язык в обе стороны интероперабельный с хостовым и все будет прекрасно», это гораздо прагматичнее на мой взгляд.
Про ноду и экто — ну тут ведь как. Вот есть у меня готовое приложение на эрланге, здоровенное. И главная проблема в нем — в базу ходить больно и убого. И хочется чего-нибудь, что походило бы на нормальный генератор запросов, и вот есть ecto, но прикрутить его не получится, кроме как поднять отдельную ноду, где будет жить эликсирный код общения с БД.
Нет, у меня нет пока эликсира в проектах, мне нормально с эрлангом. Mix — а что мне тот mix, если я на rebar-е и мэйкфайлах могу изобразить такое, что потом сам рад не буду. =)
Было бы интересно поиграться с ecto, но вывешивать в отдельную ноду работу с БД — это на мой взгляд несколько чересчур.
cowboy — низкоуровневый HTTP-сервер. n2o работает поверх него.
Elixir — довольно неоднозначная штука. С одной стороны — протоколы и макросы это отлично. С другой — от всей темы вокруг Elixir настолько невыносимо пахнет наихудшим хипстерством, что как-то боязно подходить.
Ну и да, как его интегрировать в эрланг-проект до сих пор неясно.
> Авторы не видят красивого решения, которое даст пользователям возможность совать дженерики по поводу и без повода и не превратит язык в унылое Г.
> не политическое, а техническое решение
Rust это вообще не для нас. Rust решает проблемы людей, которые пишут на C/C++. Зачем его пытаются тащить в веб-дев, мне непонятно.
> обмена сообщениями между процессами через потоки
Это отдельная тема, CSP против акторов. Тут, кстати, есть забавный нюанс — в статически типизированных языках CSP выражается гораздо проще, мы просто делаем Channel и используем их везде, хотя это и повышает когнитивную нагрузку на разработчика. «receive» актора в этом плане гораздо более нетривиальная штука.
> А если мы создадим несколько воркеров, которые будут отдавать ответы одному процессу — у него на каждого будет поток?
По идее, для many-to-one должно быть возможно обойтись одним каналом. Но это уже зависит от реализации.
> работает, даже если Pid на другой машине в кластере.
До определенного момента работает. Изкоробочный interconnect штука не такая уж и простая, со своими подводными камнями. Впрочем, об этом я только слышал, сам не сталкивался. Детали нужно спрашивать у людей посерьезнее меня.
Да, серьезная, но единственный чисто эксплуатационный критерий, в котором go выигрывает. И то, это не окончательное решение вопроса доставки приложения в продакшн.
Если у вас, скажем, сервис запускается в docker-контейнере, какая вам разница, там внутри бинарник или снапшот кода из репозитория?
Я все думаю написать сравнительный пост про эксплуатационные качества э-га и go, руки не доходят.
Disclaimer: мой ответ может показаться чересчур восторженным, но у меня на часах почти 5 утра и я не сильно хочу заморачиваться избыточными уточнениями.
> для чего же эдакого может применяться такой монстр в веб проектах
Основной профит эрланга — можно не заморачиваясь писать сомнительный(запросы в сеть, в фс, ожидание сторонних процессов) код прямо в коде обработки пользовательских запросов и все будет ништяк, рантайм все честно разрулит, вся система не упорется(ну если только вся ОС). Пара акторов умрет в худшем случае, ну и черт с ними, все остальные продолжат работать, а в логах останется информация к размышлению — и это все из коробки, вместе с вылизанным за годы рантаймом.
Одна кодовая база и общее адресное пространство для request-responce и long living connections, in-process кэши и очереди задач и прочие подобные мелкие удобства ощутимо меняют жизнь и процесс разработки. Волосы реально становятся мягкими и шелковистыми.
Но тем не менее — не стоит писать на эрланге что-то, для чего вам хватит голого Rails. Вот когда вам захочется переписать свой код на Go, потому что вам не хватает вашего application server с блокировками воркеров на запросы в отдельные сервисы — вот тогда вот тогда очень внимательно и вдумчиво посмотрите на Erlang.
> Ведь разрабов пишущих эрланге, как амурских тигров, почти нет.
Ну, с этим сложно спорить. С другой стороны, толковых людей вообще мало и проблема скорее в этом, чем в языке.
А так эрланг очень простой. «Эрланг учится за две недели, за год можно выучить до 26 эрлангов.»
Тот же go активно продают простотой — а ведь go сильно сложнее.
BTW, IMHO, язык вообще не должен рассматриваться как проблема при поиске людей, кроме совсем запущенных случаев, вроде C++ или Scala+scalaz или Haskell, или еще чего-то в том же духе. В адекватном случае человек будет дольше вникать в проблематику проекта, язык — малая доля проблем при налаженном рабочем процессе.
> И стоит эта разработка не мало.
Вот тут мне сложно судить объективно, у меня всяческий positive bias — я уже три года пишу почти на чистом э-ге, изредка на go и python.
Да, наверное, выходит несколько дороже, но выхлоп сильно больше. Я сомневаюсь, что то, у нас есть, было бы сделано за то же время и столь же работоспособным, если бы мы не взяли эрланг со старта.
Ну и да, привет whatsapp и его 35(или 50?..) инженерам на дохреналион пользователей.
> да тот же go куда дружелюбней.
Ну вот не надо, а. Erlang очень простой, если не сказать топорный, язык, только выглядит страшно. Сильно проще Go и, кстати, не пытается прятать незнакомую семантику под внешне знакомым синтаксисом.
Реально, в эрланге есть 2.5 вещи, которые нужно понять — pattern matching, processes — акторы, high-order functions. Дальше познакомиться с application/supervisor/gen_server из OTP, усвоить meta code style — как вообще писать на языке без переменных, и можно хуяк-хуяк в продакшн.
Если кому-то хочется синтаксического сахарка — есть хипстерский и набирающий моду сейчас Elixir, есть питонообразный Efene, есть лиспы — lfe(который я не люблю, потому что он common lisp, а не clojure) и joxa(который, увы, заброшен). Если хочется метапрограммирования — в Elixir и lfe есть вполне пристойные макросы.
Go реально выигрывает только в двух вещах — статические бинарники дают простоту деплоймента, плюс там есть нормальные строки. Ну, и в его рантайме можно разобраться за считанные дни. И то, первый аргумент нивелируется отказом от релизов в Erlang-проекте, без них можно сделать достаточно простыми деплоймент и конфигурацию.
> из эрлангового в json
Достаточно простой record-to-json(через proplist) делается в одну функцию при использовании exprecs (https://github.com/uwiger/parse_trans/blob/master/doc/exprecs.md) — parse transform, который генерит много функций для работы с рекордами. Дописать exprecs для генерации to_map/from_map должно быть не так уж сложно.
Простой пример из моего продакшн-кода
https://gist.github.com/nwalker/816618e162fc2f5010af
Результат функции to_proplist/1 должен спокойно прожевать любой JSON-энкодер.
Конечно, с композитными типами данных, типа дат, будет сложнее — но так оно и нигде не просто, JSON так себе формат для этого.
Формально, конечно, особой разницы нет, потому что каналы легко выражаются через акторы, а акторы — чуть сложнее через каналы.
Фактически же разные подходы — читай, разные first-class citizens — приводят к разным решениям в итоге, и если сравнивать имеющиеся реализации, акторы все же выразительнее и позволяют иметь из коробки больше.
Нет в Go никаких акторов. Модель акторов подразумевает first-class исполнители, обменивающиеся сообщениями адресно.
В Go CSP, где first-class объектами являются каналы, по которым исполнители обмениваются сообщениями.
>> youtube не достаточно, чтобы хоть кто-то использовал
Я не уверен, что у него внутри полноценный DASH, а не только MSE со своими плейлистами, как и в том, что там строго соответствующие стандарту сегменты. Нужно проверить, как оно в Firefox работает сейчас.
Алсо, про youtube и MSE у меня есть conspiracy theory, что Google этот самый MSE в Chrome реализовали до его продвижения как веб-стандарта и youtube HTML5 плеер работал на нем уже давно.
>> за которые Adobe получает royalty
Очень сильно сомневаюсь, что Adobe получает роялти за H264, скорее платит. Но про вопросы лицензирования лучше спрашивать у Макса Лапшина( erlyvideo ), он более в теме.
Я же за H264/H265 только потому, что они стандарт де-факто. Если бы декодер другого кодека был уже в тостерах, а энкодер в любом софте для публикации видео — я бы голосовал за него. Но только за один, потому что фрагментация ничего хорошего не несет.
>> но на его основе (вместе с ORTC) Microsoft разрабатывает web-версию скайпа без плагинов.
Это единственное, для чего он более-менее подходит. Для приличного few-to-many лайва хотя бы формата вебинара — уже не годится, нужен промежуточный сервер, желательно с транскодером и TURN relay.
А если у нас уже есть сервер — на кой черт нам стек, заточенный на p2p?
Кстати, про интересные особенности WebRTC свежий пост от Voximplant — http://habrahabr.ru/company/Voximplant/blog/271921. Ощутите ту боль, которая читается между строк.
DASH — это стандарт chunked доставки видео как HLS/HDS/SmoothStreaming, только с абсолютно диким форматом плейлистов. Использует ли его уже кто-то — вопрос. Для стриминга VOD — однозначно ГОРАЗДО лучше Adobe RTMP, но все перечисленные транспорты лучше его.
С live video — тоже лучше, если не нужна latency меньше пары секунд.
MSE — веб-стандарт, который описывает как и какие куски данных пихать в HTMLMediaElement. Его занесли в w3c те же люди, что придумали DASH, чтобы этот DASH вообще работал. В принципе, неплохая штука, но пока очень ограниченно поддерживается. flash.net.NetStream.appendBytes ИМХО как-то проще и очевиднее.
WebRTC — это кошмарный SIP-телефон без собственно SIP, занесенный в браузер, слабо подходящий для чего-либо кроме p2p. Невероятно монструозное поделие, еще и сомнительной применимости, потому что набором поддерживаемых кодеков не совпадает с стандартами де-факто стриминга.
Да тут как посмотреть. Я, например, не уверен, нужен ли мне микс, когда есть ребар и мэйфайлы. Они же абсолютно эквивалентны.
И вот именно этот подход «зачем X и Y, если есть Z, который наш» в эликсире и его комьюнити совсем не нравится. Например, «зачем нам старый source file layout, мы запилим свой, абсолютно несовместимый». «Зачем нам встраивание в pure erlang проекты» туда же. Мне гораздо ближе подход clojure — «мы сделаем язык в обе стороны интероперабельный с хостовым и все будет прекрасно», это гораздо прагматичнее на мой взгляд.
Про ноду и экто — ну тут ведь как. Вот есть у меня готовое приложение на эрланге, здоровенное. И главная проблема в нем — в базу ходить больно и убого. И хочется чего-нибудь, что походило бы на нормальный генератор запросов, и вот есть ecto, но прикрутить его не получится, кроме как поднять отдельную ноду, где будет жить эликсирный код общения с БД.
Было бы интересно поиграться с ecto, но вывешивать в отдельную ноду работу с БД — это на мой взгляд несколько чересчур.
Elixir — довольно неоднозначная штука. С одной стороны — протоколы и макросы это отлично. С другой — от всей темы вокруг Elixir настолько невыносимо пахнет наихудшим хипстерством, что как-то боязно подходить.
Ну и да, как его интегрировать в эрланг-проект до сих пор неясно.
> не политическое, а техническое решение
Это не деление ли на ноль?
> обмена сообщениями между процессами через потоки
Это отдельная тема, CSP против акторов. Тут, кстати, есть забавный нюанс — в статически типизированных языках CSP выражается гораздо проще, мы просто делаем Channel и используем их везде, хотя это и повышает когнитивную нагрузку на разработчика. «receive» актора в этом плане гораздо более нетривиальная штука.
> А если мы создадим несколько воркеров, которые будут отдавать ответы одному процессу — у него на каждого будет поток?
По идее, для many-to-one должно быть возможно обойтись одним каналом. Но это уже зависит от реализации.
> работает, даже если Pid на другой машине в кластере.
До определенного момента работает. Изкоробочный interconnect штука не такая уж и простая, со своими подводными камнями. Впрочем, об этом я только слышал, сам не сталкивался. Детали нужно спрашивать у людей посерьезнее меня.
Если у вас, скажем, сервис запускается в docker-контейнере, какая вам разница, там внутри бинарник или снапшот кода из репозитория?
Я все думаю написать сравнительный пост про эксплуатационные качества э-га и go, руки не доходят.
> для чего же эдакого может применяться такой монстр в веб проектах
Основной профит эрланга — можно не заморачиваясь писать сомнительный(запросы в сеть, в фс, ожидание сторонних процессов) код прямо в коде обработки пользовательских запросов и все будет ништяк, рантайм все честно разрулит, вся система не упорется(ну если только вся ОС). Пара акторов умрет в худшем случае, ну и черт с ними, все остальные продолжат работать, а в логах останется информация к размышлению — и это все из коробки, вместе с вылизанным за годы рантаймом.
Одна кодовая база и общее адресное пространство для request-responce и long living connections, in-process кэши и очереди задач и прочие подобные мелкие удобства ощутимо меняют жизнь и процесс разработки. Волосы реально становятся мягкими и шелковистыми.
Но тем не менее — не стоит писать на эрланге что-то, для чего вам хватит голого Rails. Вот когда вам захочется переписать свой код на Go, потому что вам не хватает вашего application server с блокировками воркеров на запросы в отдельные сервисы — вот тогда вот тогда очень внимательно и вдумчиво посмотрите на Erlang.
> Ведь разрабов пишущих эрланге, как амурских тигров, почти нет.
Ну, с этим сложно спорить. С другой стороны, толковых людей вообще мало и проблема скорее в этом, чем в языке.
А так эрланг очень простой. «Эрланг учится за две недели, за год можно выучить до 26 эрлангов.»
Тот же go активно продают простотой — а ведь go сильно сложнее.
BTW, IMHO, язык вообще не должен рассматриваться как проблема при поиске людей, кроме совсем запущенных случаев, вроде C++ или Scala+scalaz или Haskell, или еще чего-то в том же духе. В адекватном случае человек будет дольше вникать в проблематику проекта, язык — малая доля проблем при налаженном рабочем процессе.
> И стоит эта разработка не мало.
Вот тут мне сложно судить объективно, у меня всяческий positive bias — я уже три года пишу почти на чистом э-ге, изредка на go и python.
Да, наверное, выходит несколько дороже, но выхлоп сильно больше. Я сомневаюсь, что то, у нас есть, было бы сделано за то же время и столь же работоспособным, если бы мы не взяли эрланг со старта.
Ну и да, привет whatsapp и его 35(или 50?..) инженерам на дохреналион пользователей.
> да тот же go куда дружелюбней.
Ну вот не надо, а. Erlang очень простой, если не сказать топорный, язык, только выглядит страшно. Сильно проще Go и, кстати, не пытается прятать незнакомую семантику под внешне знакомым синтаксисом.
Реально, в эрланге есть 2.5 вещи, которые нужно понять — pattern matching, processes — акторы, high-order functions. Дальше познакомиться с application/supervisor/gen_server из OTP, усвоить meta code style — как вообще писать на языке без переменных, и можно хуяк-хуяк в продакшн.
Если кому-то хочется синтаксического сахарка — есть хипстерский и набирающий моду сейчас Elixir, есть питонообразный Efene, есть лиспы — lfe(который я не люблю, потому что он common lisp, а не clojure) и joxa(который, увы, заброшен). Если хочется метапрограммирования — в Elixir и lfe есть вполне пристойные макросы.
Go реально выигрывает только в двух вещах — статические бинарники дают простоту деплоймента, плюс там есть нормальные строки. Ну, и в его рантайме можно разобраться за считанные дни. И то, первый аргумент нивелируется отказом от релизов в Erlang-проекте, без них можно сделать достаточно простыми деплоймент и конфигурацию.
Достаточно простой record-to-json(через proplist) делается в одну функцию при использовании exprecs (https://github.com/uwiger/parse_trans/blob/master/doc/exprecs.md) — parse transform, который генерит много функций для работы с рекордами. Дописать exprecs для генерации to_map/from_map должно быть не так уж сложно.
Простой пример из моего продакшн-кода
https://gist.github.com/nwalker/816618e162fc2f5010af
Результат функции to_proplist/1 должен спокойно прожевать любой JSON-энкодер.
Конечно, с композитными типами данных, типа дат, будет сложнее — но так оно и нигде не просто, JSON так себе формат для этого.
Фактически же разные подходы — читай, разные first-class citizens — приводят к разным решениям в итоге, и если сравнивать имеющиеся реализации, акторы все же выразительнее и позволяют иметь из коробки больше.
> Features hurt readability. We want readability.
Пфф. Нет, с Пайком мне не по пути, и в Go я никогда не буду видеть того, что нужно мне. «Simple made Easy» Рича Хикки гораздо сильнее впечатляет.
В Go CSP, где first-class объектами являются каналы, по которым исполнители обмениваются сообщениями.
Я не уверен, что у него внутри полноценный DASH, а не только MSE со своими плейлистами, как и в том, что там строго соответствующие стандарту сегменты. Нужно проверить, как оно в Firefox работает сейчас.
Алсо, про youtube и MSE у меня есть conspiracy theory, что Google этот самый MSE в Chrome реализовали до его продвижения как веб-стандарта и youtube HTML5 плеер работал на нем уже давно.
>> за которые Adobe получает royalty
Очень сильно сомневаюсь, что Adobe получает роялти за H264, скорее платит. Но про вопросы лицензирования лучше спрашивать у Макса Лапшина( erlyvideo ), он более в теме.
Я же за H264/H265 только потому, что они стандарт де-факто. Если бы декодер другого кодека был уже в тостерах, а энкодер в любом софте для публикации видео — я бы голосовал за него. Но только за один, потому что фрагментация ничего хорошего не несет.
>> но на его основе (вместе с ORTC) Microsoft разрабатывает web-версию скайпа без плагинов.
Это единственное, для чего он более-менее подходит. Для приличного few-to-many лайва хотя бы формата вебинара — уже не годится, нужен промежуточный сервер, желательно с транскодером и TURN relay.
А если у нас уже есть сервер — на кой черт нам стек, заточенный на p2p?
Кстати, про интересные особенности WebRTC свежий пост от Voximplant — http://habrahabr.ru/company/Voximplant/blog/271921. Ощутите ту боль, которая читается между строк.
DASH — это стандарт chunked доставки видео как HLS/HDS/SmoothStreaming, только с абсолютно диким форматом плейлистов. Использует ли его уже кто-то — вопрос. Для стриминга VOD — однозначно ГОРАЗДО лучше Adobe RTMP, но все перечисленные транспорты лучше его.
С live video — тоже лучше, если не нужна latency меньше пары секунд.
MSE — веб-стандарт, который описывает как и какие куски данных пихать в HTMLMediaElement. Его занесли в w3c те же люди, что придумали DASH, чтобы этот DASH вообще работал. В принципе, неплохая штука, но пока очень ограниченно поддерживается. flash.net.NetStream.appendBytes ИМХО как-то проще и очевиднее.
WebRTC — это кошмарный SIP-телефон без собственно SIP, занесенный в браузер, слабо подходящий для чего-либо кроме p2p. Невероятно монструозное поделие, еще и сомнительной применимости, потому что набором поддерживаемых кодеков не совпадает с стандартами де-факто стриминга.
«Лучшее на Geektimes
Исполнители парижских терактов общались по SMS без шифрования»