После года разработки состоялся релиз фреймворка Ergo 1.2, реализующего полный сетевой стек Erlang и его библиотеку OTP на языке Go. Фреймворк предоставляет разработчику гибкий инструментарий из мира Erlang для создания распределённых решений на языке Go с помощью готовых шаблонов проектирования Application, Supervisor и GenServer. Поскольку в языке Go отсутствует прямой аналог процесса Erlang, то во фреймворке используются goroutine как основы для GenServer с обёрткой recover для возможности обработки исключительных ситуаций. Код проекта распространяется под лицензией MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54925
9 контрибуторов? Не взлетит.
но-но, правдами и неправдами Братство Кольца своей цели добилось
Ломать -- не строить. Одно дело фремворк написать, а другое дело оборудование в вулкан бросать.
> а другое дело оборудование в вулкан бросатьэто значит в видео-драйвер добавить поддержку Vulkan API?)
А лет через 20 будут искать программистов на эрланге, поскольку старые отомрут, а код как работал, так и будет работать
пишу последние 7 лет на ерланге, могу сказать, что этот миф обычно звучит от людей, которые только слышали про ерланг, но в реальности его не использовали. да, он стабильно работает, но такую же стабильность можно достич и на другом языке с теми же ресурсными затратами.
Обычно когда разработчики на эрланге покидают компанию их код переписывают с использованием других более распространненых технологий
Взвесьте мне полкило фреймворка для написания новой планеты, пожалуйста. На Си++.
Сетевого? ASIO?
И мне того же что и этому господину
КТО НА КОМ СТОЯЛ !?!?Что на чем реализовано ?
Я так понял, что чуваки решили переписать Erlang/OTP на go. Ну, успехов, чо...
Так и напрашивается proxy-сервер на этой штуке.
> используются goroutine как основы для GenServer с обёрткой recover для возможности обработки исключительных ситуацийКажется, это называется "химера", или, по-народному, "смесь бульдога с носорогом".
Предположу, что Джо Армстронг смотрит на всё это, свесив ноги с облака, и посмеивается в усы.
а чем вам эта абстракция не нравится? аргументированно получится сформулировать?
> а чем вам эта абстракция не нравится? аргументированно получится сформулировать?Попробую.
Уже есть код, в котором эти абстракции (gen_server, gen_supervisor) реализованы, причём они органично вписаны в язык с его концепцией "let it crash". Для того, чтобы реализовать эти абстракции на go, необходимо, фактически, надстроить над go целую систему примерно так же, как EVM построена на C. То есть, это - NIH и велосипединг. И опять-таки, для чего? Чтобы запускать прикладной код, нписанный на go, в виде чего-то, похожего на эрланговский gen_server? Для этого достаточно научиться писать NIF'ы на go.
вы как-то в сторону разговор увели. мне было инетресно, чем именно не нравится абстракция над горутиной?поясню... в ерланге процесс - легковесная сущность с мейлбоксом. в ерго - горутина с буферизированным каналом в качестве мейлбокса. в ерланге процесс падает - никому дела нет. в голэнге горутина падает - через рекавер ловится и все также никому дела нет. в ерланге на базе этого сделали генсервер, чтобы создать супервизоринг. в ерго на базе обертки над горутиной также создан объект с теми же характеристиками как и генсервер. в ерлаге это дает хорошие возможности проектирования. что мешает использовать этот же опыт в голэнге?
так чем именно не подходит такая абстракция?
идея отправлять всех в ерланг, чтобы писать в ОТП стиле - так себе совет :). возможно вы недостаточно внимательно прочитали readme на странице проекта.
В Го как известно есть серьезные проблемы с GC, поэтому, например, от него отказались в Discord-е. Как у Эрланга с этим по сравнению с Го?
>В Го как известно есть серьезные проблемы с GCвы как-то замалчиваете тот факт, что оперируете статьей 2х летней давности, в которой использовали Golang 4х летней давности. и это не считая того, что ребята там как-то странно сетовали на проблему из которой напрашивался один вывод - они не использовали пул ресурсов.
если вы на хайлоаде, то должны чуть глубже понимать подкапотное пространство. именно по этой причине ergo отпрофилирован и оптимизирован под хайлоад (используются техники stackless, resource pool, минимизировано использование shared channels).
забыл добавить, к той статье даже в комментариях очень много было вопросов про адекватность выводов и сути проблемы. так что весьма спорная статья, чтобы приводить ее в качестве аргументации.
Когда абсолютно не в теме, но очень хочется что-то "умное" сказать ))).
А "не в сторону" - это ограничиться обсуждением исключительно технической стороны концепции gen_server над горутинами?
вы всегда так уходите от ответа? либо в сторону, либо вопросом на вопрос? ))) не находите ли это отсутствием внятных аргументов в озвученных ранее мыслей?
если вы потеряли ход мысли на какой вопрос я прошу ответить...в первом сообщении вы процитировали текст про генсервер как абстракцию над горутиной и назвали это химерой. на что я попросил вас аргументированно сформулировать суть вашего комментария про "химеру". в чем именно вы находите "химерность" в реализации ergo дерева супервайзинга? если эта реализация "химера", то какая должна быть по вашему экспертному мнению правильная (эталонная, если хотите) реализация?
чтобы было понятней, почему ваш комментарий не несет в себе смысла>Уже есть код, в котором эти абстракции (gen_server, gen_supervisor) реализованы, причём они >органично вписаны в язык с его концепцией "let it crash". Для того, чтобы реализовать эти >абстракции на go, необходимо, фактически, надстроить над go целую систему примерно так же, как EVM >построена на C.
для начала... нет такого паттерна gen_supervisor. есть gen_server, supervisor, application. ну, там еще несколько других есть, но дерево супервизора обеспечивают эти три. концепция "let it crash" строится на стратегиях рестарта для паттернов supervisor и application (при этом под капотом каждого из них gen_server). в ergo эти паттерны реализованы ровно с такими же стратегиями - ровно та же концепция let it crash.
я лишь могу сделать выводы, что вы недостаточно внимательны были в прочтении README файла на странице проекта, либо недостаточно владеете предметом OTP, поскольку иначе бы не стали писать абсурдные выводы вроде "необходимо, фактически, надстроить над go целую систему примерно так же, как EVM построена на C".
И то и другое. Расслабься, не сможет он аргументировать. Нечем.
Да, попутал название, каюсь - давно читал (у Армстронга в "Programming Erlang" в серии Pragmatic присутствуют оба названия поведениия - и "supervisor", и "gen_supervisor" - м.б. оттуда в голове засело). Только это не "паттерны", а "поведения", паттерны в Эрланге - это то что сопоставляется (ну, во введении в Design principles пару раз это слово употребляется применительно к процессам). Но это так, жонглирование словами.
А вот это: концепция "let it crash" строится на стратегиях рестарта для паттернов supervisor и application - это просто глупость. Концепция "let it crash" - это подход к обработке непредвиденных ситуаций, которые считаются неизбежными. И она вовсе не обязательно связана с перезапуском упавшего процесса. Нвпример, после краха процесса, обрабатывающего запрос, клиенту может быть отправлен код с ошибкой (типа HTTP 500 Internal Server Error), после чего соединение закрывается. Или просто процесс, связанный с рухнувшим, что-то запишет в лог и тоже завершится. И концепция "let it crash" не основана на стратегиях рестарта, это концепция Supervision tree основана на концепции "let it crash", и других фундаментальных концепциях, в частности - на концепции связанных процессов.
> недостаточно владеете предметом OTPЯ им вообще не владею. Я с ним когда-то из любопытства ознакомился.
Т.е. темой не владеем, а указывать как правильно лезем 😄. Про let it crash херню конечно наморозили, но это простительно для человека не в теме
Так кто ж вас заставляет лезть, если вы темой не владеете?
тут уже выше написали, что вы, мягко говоря, неточны в своих выводах. поясню почему>А вот это: концепция "let it crash" строится на стратегиях рестарта для паттернов supervisor и application - это просто глупость.
за это, родителей в школу
>И она вовсе не обязательно связана с перезапуском упавшего процесса.
за это, выгнать из школы
>Нвпример, после краха процесса, обрабатывающего запрос, клиенту может быть отправлен код с ошибкой (типа HTTP 500 Internal Server Error), после чего соединение закрывается.
вы даже не представляете, как далеко вы от истины ). не буду голословным. попорядку
- нет никакого соединения в этом процессе. и никто не разрывает его (от этого прям реально не смешно, а даже грустно стало).
- если речь о мониторах, то процесс, который повесил монитор дейстительно получает 'DOWN' сообщение, но это не про let it crash от слова совсем
- если речь о линковке, то процесс слинкованный также рухнет вместе с другм. опять же не про let it crashможет хватит топить себя и спорить с тем, кто изучил эту кухню изнутри, а не "когда-то из любопытсва ознакомился"? ).
PS: вся суть let it crash в том, что любой упавший процесс будет перезапущен ровно с теми же параметрами, с которыми он был запущен. внезапно, это те самые паттерны (behaviour, если быть педантичным в терминологии OTP), которые реализуют стратегии перезапуска (temporary, transient, permanent). не сочтите за труд, почитайте подробнее http://erlang.org/doc/design_principles/des_princ.html и перестаньте уже демонстрировать свое невежество.
Вы прислали мне ссылку на введении в Design principles - документ, который я сам упоминал как то единственное место в документации на OTP, в котором разные виды процессов названы "паттернами". Вы, вообще, внимательно читаете, что Вам пишут?
Если Вы и "кухню изучали" так же внимательно, то неудивительно, что Ваше понимание концепции "let it crash" ограничивается только супервизором в OTP, причём только как средства перезапустить упавший процесс.
> нет никакого соединения в этом процессе. и никто не разрывает его (от этого прям реально не смешно, а даже грустно стало).Простите, Вы всерьез считаете, что я не понимаю разницы между понятиями "connection" (которое между хостами) и link (который между процессами, один из которых может быть socket owner того самого connection, а остальные - обработчиками, которые могут крашиться, и в этом случае socket owner отправляет клиенту сообщение об ошибке)?
Последние бастионы добра рушатся.
>> Добавлена статическая маршрутизация, чтобы исключить обращение к EPMD для определения порта узлаДобавлен костыль чтобы закостылять дыру в костылях
Смущает только то что в OTP завязан на Erlang специфичные вещи и вот как эти паттены проектирования переносятся в golang я честно говоря боюсь даже смотреть. Хотя наверное стоит поглядеть.
трата времени
Понятное дело, каждый уважающий себя программист должен написать свой езыг с обвертками.
У меня в детстве была книжка по C/C++, там выпускное упражнение как раз было создание компилятора для своего языка. Так что вы зря удивляетесь, некоторые просто сделали его с особым усердием.
Насчёт усердия не знаю, но в предыдущие разы это были c# и nodejs. Я конечно понимал что это наркомания, но в какой то момент мне начали её предлагать из всех щелей, я просто их игнорировал, но количество вакансий и неувеличавшуюся собственную зарплату игнорировать было тяжелее, ещё тяжелее было пропускать проекты с хорошей идеей написанных наркоманами. С горя пришёл в кровавый интерпрайз и тут никто не спрашивает на чем ты хочешь писать, переписывать никто не даст, а предыдущий разработчик скорее всего уволился после того как переписал php на nodejs. Так что искоренять заразу надо в зародыше.
Я извиняюсь, что прерываю вашу беседу... А вы точно читали о чем речь в новости?
Про ежа и ужа уже шутили?
А зачем шутить, если лангерам теперь жрать эти три метра колючей проволоки?
Пишу на го. Фреймворк обернул стандартные возможности в новые методы со своими менеджерами и еррорами. Типа пакета http но для других протоколов наверноеPS а всякие сишники стоят в сторонке и завидуют попердывая)
мягко говоря, вы ошибаетесь про "обернул стандартные возможности в новые методы". загляните ради интереса в какой-нибудь из паттернов, в тот же gen_stage.go. а потом в dist протокол, а после в etf. не уверен, что это попадает в категорию "обернул стандартные возможности" ).
с чего вдруг?! Все что ты могёшь сделать на го, мы легко сделаем (и делали много раз до всякого го) на Сишечушеньке
:) Show this on C :
package mainimport "fmt"
func main() {
fmt.Println("Hello, 世界")
}
Опять идиотов в тред завезли. Будет выглядеть так же. Ты, клоун, перед тем как херню из помоек ретранслировать гугли лучше, авось не опозоришься в следующий раз.
Прекрасная новость. Спасибо за работу!
пеши исчо
tls1.3 он напрогал, go обновил, хопа tls обновился, запишем changelog