Выпустил большой релиз Ergo Framework 1.2.0

Up to x5 times faster

Сходу, поправь ридми. Либо “Up to 5 times faster”, либо “Up to 5x faster”.

да, там еще есть опечатки. меня не парит :). потом как-нибудь, в следующем релизе.

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

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

Зашел, увидел касперский, ушел. Не буду даже 5 метровой палкой трогать.

Зашел, увидел касперский, ушел. Не буду даже 5 метровой палкой трогать.

у анонимуса есть аргументация или это эмоциональное отклонение? в касперском, кстати и винда, и линукс во все поля используется. откажись и от них. а еще они воздухом дышат. иди до конца ))

Похоже на реализацию OTP для Go.

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

Да, я знаю. Проблема в том, что многие из этих паттернов имеют смысл в основном с Erlang и BEAM. Ну и, кам он, gen_server – это просто event loop из семи залуп.

А сборка мусора там на процесс или на все процессы чохом?

у го нет разделения памяти по горутинам. одна куча с одним мусорщиком. не нужно искать прямую аналогию с ерланг-процессом. в ergo процесс - это просто абстракция над горутиной. GenServer - это паттерн, основанный на этой абстракции. как и Supervisor, Application. GenStage - он уже использует под собой GenServer. Просто в этих всех прелестях уже построена коммуникация с сетевой прозрачностью всякими событийными фичами. Например, мониторинг процесса на ноде А процессом на ноде В - делается одной командой и благодаря сетевой прозрачности вся магия по установке соединения и всякой кухней по связыванию этих процессов произойдет автоматом. если один процесс на ноде А завершиться, то подкапотная машинерия сгенерирует нужное сообщение и пошлет процессу на ноде В. Или же если нода А сломается, или сеть сломается - в любом случае процесс на ноде В получит сообщение DOWN этого процесса.

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

Проблема в том, что многие из этих паттернов имеют смысл в основном с Erlang и BEAM.

я бы не согласился. супервайзинг - оч крутая штука. линковка, мониторы (distributed особенно) - незаменимые фичи. сейчас вот из коробки есть GenStage - совсем огонь.

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

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

в ergo процесс - это просто абстракция над горутиной

т.е. надежности никакой, в смысле эрланга, где нельзя уронить vm.

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

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

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

т.е. надежности никакой, в смысле эрланга, где нельзя уронить vm.

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

А смысл какой в этой разработке?

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

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

А почему бы тогда не взять Elixir?

А почему бы тогда не взять Elixir?

Там многие девтулзы те же самые. Я вот в один опенсорсный проект на эликсире хотел покоммитить, но так и не осилил развернуть среду для разработки :(

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

На 100k Connections Test, чистый Elixir не уступает Go, а нода слилась уже на 60к.

https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/

А если посмотреть на какой-нибудь ватцап c их 450 million daily active users, то возникает вопрос можно ли такое написать на другом языке.

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

А если посмотреть на какой-нибудь ватцап c их 450 million daily active users, то возникает вопрос можно ли такое написать на другом языке.

можно. просто его разработали в далеком 2008-2009 на базе XMPP, который был в виде ejabberd, а тот в свою очередь написан на ерланге. так что выбор ерланга был не как решение техдира ватсапа, а как быстро и дешево запилить мессенджер используя что-то готовое. и да, в то время было «второе пришествие» ерланга в ИТ отрасли. но потом появились golang/rust и утилизация многопроцессорности стала сильно проще для разработчиков. сейчас хайп вокруг эрлага утих и он снова направился в сторону забвения. новые проекты на нем сейчас писать не самая лучшая идея. спецов мало, экосистема не развиваетяс. сам язык в вялом темпе пытается подавать признаки жизни, но это все ерунда. его ждет судьба перла - им будут восхвалятся «старые пердуны», расказывать в каментах про «а вот в наше время…». Эликсир дал, конечно, еще одно дыхание ерлангу, но оно живо только благодаря Erlang Solutions, а эта компания жива только тем, что поддерживает действующие ерлаговские внедренные решения плюс немного сверху что-то делает нового на эликсире. Это ничтожно мало в сравнении с комьюнити тех же golang/rust.

А это полноценная замена узла в эрланг кластере с бесплатной *5 производительностью, или есть ограничения?

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

А это полноценная замена узла в эрланг кластере с бесплатной *5 производительностью, или есть ограничения?

да, полноценная drop-in замена. если какая-то нода в кластере не справляется с задачей, можете взять этот фреймворк, переписать код на golang и оно нативно встроится в кластер. erlang-соседи даже не заподозрят, что общаются с нодой на golang.

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

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

забегая вперед, отвечу на вопрос «откуда х5, ведь сетевой стек у ерланга на си написан?»

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

ключевые особенности, которые дают прирост именно в реализации ergo:

• ETF encoder/decoder имеет stackless реализацию. у ерланга этот кусок написан очень неэффективно, особенно когда речь идет о сложных структурах (списки, мапы, комплексные структуры с вложенностью). чем сложнее структура, тем результат у ерланга драматически хуже. у ergo этот кусок очень сильно отпрофилирован и сложность структуры не оказывает сильного влияния. посмотрите графики бенчмарков. технически, я могу показать и 10х кратное превосходство просто взяв, например, массив из структур с пачкой мапов). в свое время в ерланге даже сделали atom cache в сетевом стеке ибо атомы там очень активно используются. по их оценкам в то время это дало очень значительный прирост. когда начинал реализацию этой фичи в ergo тоже ожидал что-то существенное, но по факту получил 5-10% прироста. по всей видимости у них этот кеш закрывает другой очень неэффективный кусок функционала.
• fragmentation support реализована в рамках реализации DIST (у erlang сборка/разборка фрагментов делается в BEAM машине, что тормозит очень сильно

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

Если все так плохо, почему Elixir/Phoenix набирает популярность?

Думаю, что производительность не самый важный фактор. На Elixir очень приятно и быстро писать (современный функ. язык), практически как на ruby.

Если все так плохо, почему Elixir/Phoenix набирает популярность?

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

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

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

elixir вполне развивается. Из недавнего Numerical Elixir дает 5000 прирост производительности при вычислениях.

https://alembic.com.au/blog/2021-03-25-high-performance-numerical-elixir-nx

я не в буквальном смысле говорил про числодробилку. имелось ввиду CPU-специфичные задачи.

BEAM выше головы прыгать не умеет. только с помощью нифов, разумеется.