Ergo Framework 3.0

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

Согласен, упустил этот момент. Поправил текст.

Суть Erlang не в языке и стандартной библиотеке, а в виртуальной машине. Больше смысла было бы сделать язык с синтаксисом Go и компиляцией в BEAM.

А насколько широко фреймворк используют, интересно? Просто 2.8K звезд на github, при этом всего две issue, ни разу такого не видел.

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

Просто 2.8K звезд на github, при этом всего две issue, ни разу такого не видел.

обычно быстро закрываю баги :).

Сильно вникать пока некогда, я правильно понимаю что там полная реализация OTP + поддержка сетки которая в erlang? Тоесть я могу в свой сервис написанный на православном erlang добавить ноду с реализацией чего нибудь на golang и оно вполне зарегается и будет работать?

да

пример https://github.com/ergo-services/examples/tree/master/erlang

документация https://docs.ergo.services/extra-library/network-protocols/erlang

здесь постил бенчмарк эрланговского стека https://x.com/halturin/status/1802801540216054040

(прямая ссылка на скриншот https://pbs.twimg.com/media/GQTU49YXAAA2eCy?format=png&name=large)

Красавцы, может с этого проекта какая то доля go разрабов наконец то осилит OTP и начнет наконец нормально в много поточку делать… А то как поглядишь на эти микросервис микросервисом погоняет, иногда тоска нападает, хочется взять бейсбольную биту и пойти учить уму разуму направо и налево. ))

OTP

Что это такое?

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

Мы попробовали микросервисы на Го. Но у компании ограничен бюджет на процессорное время и память в облаке :)

А BSL это разве OSS лицензия?

OSS но с ограничением на коммерческое использование

Больше смысла было бы сделать язык с синтаксисом Go и компиляцией в BEAM.

Зачем? Что в синтаксисе Go такого особого/ценного, что нужен новый BEAM язык, чего нет в существующих?

Егор фреймворк… Так, Денис ОС тут уже была 🤭

Никаких. Даже в LFE смысла больше. Но тогда можно не париться и просто писать на Erlang, а автору зачем-то понадобился именно Go. Явно не из-за производительности, т.к. на ста+ одновременно живых и общающихся друг с другом потоках BEAM покажет лучшую производительность чем Go.[1]

[1] Не проверял. ¯\(ツ)/¯

Но тогда можно не париться и просто писать на Elixir

Пофиксил)

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

ЕМНИП автор тут неоднократно утверждал, что на его задачах (и его клиентов) Go/Ergo уделывает BEAM.

OTP

Что это такое?

https://en.wikipedia.org/wiki/Open_Telecom_Platform

Но тогда можно не париться и просто писать на LFE

Пофиксил) Если уж мы об альтернативных языках для BEAM говорим.

на его задачах (и его клиентов) Go/Ergo уделывает BEAM.

А, ну тогда ОК. Правда тогда возможно этим клиентам вообще OTP не нужен, но это уже им виднее. Мне просто как-то странно видеть OTP там где нет массовой распределённости и параллелизма.

# стаж в Erlang - 3 года

Особенно печалит что микросервисы используют REST там где в этом нет абсолютно никакого смысла. У вас есть огромный инструментарий - REST, {JSON,XML,…}-RPC, Websocket, SSE, protobuf, и т.д., и т.п. Используйте что лучше подходит. А то берут шуруповёрт и начинают им кто гвозди забивать, кто следы клиентов в системе рассматривать.

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

Из интереса, сколько человек работают над проектом?

на ста+ одновременно живых и общающихся друг с другом потоках BEAM покажет лучшую производительность чем Go.[1]

[1] Не проверял. ¯(ツ)/¯

Даже не представляешь насколько сильно ошибаешься.

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

Из интереса, сколько человек работают над проектом?

один :)

один :)

Хмм… А как же

Мы опубликовали исчерпывающую документацию по фреймворку…

формализм ))

Отлично. Дай посмотреть результаты.

Вы не понимаете сути новой парадигмы программирования. В отличие от старых подходов, где доменные сущности и связи между ними концептуализируются либо в самом языке (как в лиспе), либо моделируются сложной и развитой иерархией классов без модификации языка (как в яве), в Организационно Ориентированном Программировании они выносятся и обосабливаются на организационно-управленческом уровне. Каждая сущность это отдельный микросервис. Каждый микросервис это отдельная команда. Каждая команда это отдельный бюджет и при нём менеджер (иногда больше: people lead, tech lead, product owner и agile couch). Для взаимодействия команд нужен отдельный слой управления. Чем больше под тобой людей, тем ты круче как менеджер. Если между тобой и разрабом хотя бы два слоя менеджеров, получай лычку директора департамента или даже вице-призедента.

Есть же IRC сервер Ergo на Go

Вау! Моё почтение, чо.

напиши свой тест. сравни с https://github.com/ergo-services/benchmarks (см тест ping)

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

ерго покаывает около 6М в локальном тесте 1-1 и немногим больше 2.5М по сети.

в тесте 8-8 локально почти 12М, по сети около 3М.

картинка

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

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

В «надёжность с нуля» не верю. Али ты чудотворец? :)

проверь, узнаем )))

Есть же IRC сервер Ergo на Go

это ты им пиши «есть же фреймворк Ergo на Go» )))

ergo раньше назывался ergonode. в феврале 2020 года обрел имя ergo. но жил на моей личной учетке гихаба.

ergo который irc раньше назывался Oragono и переименовался в начале июня 2021 года

Благодарю за разъяснения

(N = number of CPU)

ста+ одновременно живых и общающихся друг с другом потоках

Ну, если у вас сто процов в тестовом стенде…

Могу сам проверить. Но выдавать результат с N = number of CPU за N = 100+ по меньшей мере опрометчиво.

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

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

А 3.0.0 == 2.3 ? А то я ждал 2.3 версию, а тут сразу после 2.2.4 3.0.0 пришла. И актуально ли все для этого релиза что на скринште https://ibb.co/7pthF0p (читай вошли ли все изменения).

там был некорректный тест. я позже обнаружил это.

виноват, на вопрос не ответил… да, 3.0 использует MPSC, о котором шла речь в том тесте.

еще в качестве подтверждения… больше ядер => больше пропускная способность

картинка

на цпу с 64 ядрами

локальный тест 64 актора шлют другим 64 акторам - 21М сообщений в сек

2024-09-06 00:07:45 [info] 97D7AFC3: BENCHMARK: 64 processes send 64000000 messages to 64 process
2024-09-06 00:07:48 [info] 97D7AFC3: received 64000000 messages. 21148610.261242 msg/sec

по сети - 4.9M сообщ в секунду

2024-09-06 00:08:13 [info] 08D36A53: BENCHMARK: 64 processes send 64000000 messages to 64 processes
2024-09-06 00:08:13 [info] 1BF6920E: new connection with 'node_network_NN_n1@localhost' (08D36A53)
2024-09-06 00:08:26 [info] 08D36A53: received 64000000 messages. 4910860.292277 msg/sec

Особенно печалит что микросервисы используют REST там где в этом нет абсолютно никакого смысла. У вас есть огромный инструментарий - REST, {JSON,XML,…}-RPC, Websocket, SSE, protobuf, и т.д., и т.п. Используйте что лучше подходит. А то берут шуруповёрт и начинают им кто гвозди забивать, кто следы клиентов в системе рассматривать.

Плохо на вас Erlang повлиял. Вы сейчас ставите в один ряд REST (архитектурный стиль) и протоколы данных/связи ({JSON,XML,…}-RPC, Websocket, protobuf), а потом делаете какой-то вывод. У вас не получилось.

получай лычку директора департамента

Ефрейктор департамента??..

Почитал документацию - выглядит интересно (дискреймер: я на Erlang-e много писал, сейчас пытаюсь на go)

Как обходиться без ерланговского pattern matching?

open telecomunication platform это штука которую любой разраб который юзает green threads и прочие названия в go, akka и прочих языках должен впитать в подкорку чтоб делать что то дельное а не ловить дедлоки на пустом месте.

Ну спорно, я конечно душой болею за erlang, но в плане числодробилки он явно продует golang. Хотя мессадж про количество тредов возможно имеет смысл ))

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

В общем, посмотрел я на это и выглядит очень удручающее, если честно. Ничего личного в отношении автора)

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

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

3. Снова использывание ненужных концептов из жавоподобных языков, такие как конструкторы. Вот есть у нас type SomeStruct {}. Если нам для создания типа достаточно &SomeStruct{}, то отдельную функцию-конуструктор создавать не надо.

4. Можно жаловаться, нарекать и т.д., но в го система типов есть достаточно ограниченная. Если не подходит, то надо другой язык выбирать. Все эти врапперы над interface{}, либо List = []any - это все shallow abstractions. Ну не получится сделать так, как в расте, например.

5. Все эти any - это все типонебезопасные абстракции. Сейчас any можно избежать в 99% случаев, а тут они использованы массово и везде.

6. Помимо редких исключений, мы принимаем интерфейс, а возвращаем всегда конкретный тип.

func factoryA() gen.ProcessBehavior {
	return &actorA{}
}

Конструкция такого рода является бредовой

type actorA struct {
	act.Actor
}

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

func (a *actorA) Init(args ...any) error {
	a.Log().Info("started %s process on: %s", a.Name(), a.Node().Name())
	return nil
}

Почему принимает any? Откуда вообще человек должен знать, что надо имплементировать такой метод? Что будет, если я его опущу? Откуда я могу знать, какие значения придут, сколько их будет?

HandleMessage(from gen.PID, message any) error

Я вообще не вижу нигде context.Context, все io операции в го должны работать с контекстом.

Зачем мне знать, откуда конкретно приходит запрос? Это фундаментальная ошибка в распределенной системе.

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

if result, err := a.Call(remote, MyRequest{MyBool: true, MyString: "def"}); err == nil {
			a.Log().Info("received result from remote process %s: %#v", remote, result)
		} else {
			a.Log().Error("call remote process failed: %s", err)
		}

Опасная стилистическая ошибка, люди всегда ожидают, что сначала обрабатывается ошибка, а не наоборот. Redundant else statement - есть принятый стил early return

11. Непонятно зачем нужен метод a.SendAfter, это и так элементарно делается в го.

func init() {
	// register network messages
	if err := edf.RegisterTypeOf(MyRequest{}); err != nil {
		panic(err)
	}
}

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

13. Все эти огромные интерфейсы со 100500 методов - редфлаг. Интерфейсы должны быть маленькими и иметь только те методы, которые используем в конкретном пакете

14. Нет graceful shutdown

15. Непонятно зачем к фреймворку присобачен еще какой-то логгер, логгеров что ли недостаточно? Сейчас в го есть slog и в p99 случаев его достаточно, для p1 есть zerolog

	// disable default logger to get rid of multiple logging to the os.Stdout
	optionsA.Log.DefaultLogger.Disable = true

	// add logger "colored".
	optionColored := colored.Options{TimeFormat: time.DateTime}
	loggerColored, err := colored.CreateLogger(optionColored)
	if err != nil {
		panic(err)
	}
	optionsA.Log.Loggers = append(optionsA.Log.Loggers, gen.Logger{Name: "cl", Logger: loggerColored})

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

16. Я понимаю, что в ерлаге fail fast и т.д., но концепт супервизора абсолютно бессмысленный имхо

17. Тесты какие-то хиленькие, непонятно чи то юнит-тест или интеграционный. В любом случае покрытие слабое

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

для примера. озвученная претензия про

Конструкция такого рода является бредовой

func factoryA() gen.ProcessBehavior {
	return &actorA{}
}

вполне стандартная практика. аллокация объекта, который реализует интерфейс. эта функция является аргументом для запуска процесса в методе Spawn. Для чего так? это про изоляцию и атомарность.

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

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

Как обходиться без ерланговского pattern matching?

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

после го мне теперь ерланг кажется абсолютно нечитабельным :)

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

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

Многие концепты сделаны в противоречии логики го.

Выходит зря Пайку предъявляли, что Go не привносит ничего нового, ведь он придумал новую логику, логику Go.

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

Это что-то про то, что статуя уже в камне, нужно просто найти её.

Вот есть у нас type SomeStruct {}. Если нам для создания типа достаточно &SomeStruct{}, то отдельную функцию-конуструктор создавать не надо.

А если не достаточно, то надо.

Можно жаловаться, нарекать и т.д.

Что можно делать?

Все эти врапперы над interface{}, либо List = []any - это все shallow abstractions. Ну не получится сделать так, как в расте, например.

Ты точно хочешь донести до нас какую-то осмысленную идею, а не чувство, которое у тебя возникло при написании поста?

Помимо редких исключений, мы принимаем интерфейс, а возвращаем всегда конкретный тип.

Конструкция такого рода является бредовой

Бредовым является твоё расстройство личности. Если автор использует рефлексию/кодогенерацию, возврат интерфейсов – элегантное и простое решение.

Я не понимаю, зачем встраивать какой-то тип в актора

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

Откуда вообще человек должен знать, что надо имплементировать такой метод?

Let me tell you about our lord and savior, convention.

И т.д., и т.п. ЛОР - не то место, где надо самоутверждаться, Микита.