было бы на сях, можно было был про NIF подумать

Ну, подразуемвается наверное, что ты запушкаешь го в докере как микросервис

И это правильный подход к изготовлению софта в 2018 году

ну это очень серъёзное усложнение с точки зрения архитектуры + лишние точки отказа + нагрузка на админов

Я тоже так считаю

затем что: 1. мешать много языков и технологий без серьёзной причины - к большим проблемам в будущем 2. Go тяжело эмбеддится в другие языки

erlang спокойно может общаться с любой другой приложухой

запустить +1 сервис - нагрузка на админов?..

Но альтернатива - переписать чихуянихуя на эликсире

ну надо мониторить что он работает

где докер, там кубернетис, а потом тянем за собой etcd/консул и вот это всё.

надо его разворачивать

и разработчикам отдельно в том числе

где докер, там кубернетис, а потом тянем за собой etcd/консул и вот это всё.

ОМГ =)

ну в серъёзной компании да

где отдельные крутышы devops

где докер, там кубернетис, а потом тянем за собой etcd/консул и вот это всё.

не, никакого k8s

но так не у всех

ну дык мы всегда серьёзная компания по дефолту-то =)

Если начнёшь - уже не остановиться, это факт

не докер композ же юзать на проде)

Просто хуле кзлы переписали на Го, если было на C++ всё норм

Это не мой немой вопрос

Просто хуле кзлы переписали на Го, если было на C++ всё норм

?

потому что го проще для мелкой сетевой фигни

Ну так эликсир ещё проще

потому что го проще для мелкой сетевой фигни

а эликсир проще чем го для мелкой сетевой фигни

вот и нашли причину, чтобы переписать =)

угу

очень проще

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

РЕЛИЗЫ

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

На самом деле на Го сделали, потому что охера программистов на Го

РЕЛИЗЫ

у меня коллега полдня билдил го проектик под линукс на маке с непривычки =) (кстати, так и не справился)

так что релизы понятие растяжимое

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

Причём большинство из них, являясь не очень то профессионалами в программировании (ибо Го лёгкий как яйца карлика), пытаются запихнуть их любимы "Го" везде

Ребят, а ГенСервер же пока не обработает один запрос, за другой не берется?

если handle_call использовать

Ребят, а ГенСервер же пока не обработает один запрос, за другой не берется?

да

так что если в handle_call самому себе call сделать, то заблочится.

а я тогда не понимаю вот одного defmodule GS do use GenServer def handle_call({:time, i}, _from, _state) do IO.inspect i for i <- 0..1000000000000000 do i*300 end {:ok, i, nil} end end GenServer.start(GS, name: GS) for i <- 0..10 do spawn fn -> GS.handle_call({:time, i}, nil, nil) end end

for i <- 0..1000000000000000 do i*300 end выполняется очень долго, но когда в цикле делаю 10 handle_call получаю сразу все inspect’ы

GS.handle_call({:time, i}, nil, nil) -> GS.call ?

похоже на правду, напишу если не поможет)

спасибо

@Virviil Так или иначе переписывать кусок софта, который уже работает и используется в production-е без проблем на другом языке и легко интегрируется (Go - как микросервис и без всяких докеров легко интегрируется - я в своей жизни не встречал ничего, что можно было так легко брать, качать бинарник и запускать, как софт на Go) - для этого должны быть очень везкие причины. Есть много библиотек, где не хватает maintainer-ов или времени или разработчиков на Elixir-е, зачем плодить еще больше таких же библиотек, которых некому мейнтейнить? И в данном случае нет вопроса, что же Chihaya не умеет, зачем нужна была бы версия на Elixir-е?

Мое дела предложить

Но я бы поучаствовал

Если бы кто нибудь этим занялся

банальный вопрос, что делает receive с сообщениями, которые не матчатся? Просто удаляет их из очереди?

помогло

Eugene Остаются висеть на вечно, пока их не накопится много и vm не прибьет OOM-killer.

банальный вопрос, что делает receive с сообщениями, которые не матчатся? Просто удаляет их из очереди?

http://ndpar.blogspot.ru/2010/11/erlang-explained-selective-receive.html

http://ndpar.blogspot.ru/2010/11/erlang-explained-selective-receive.html

спс, а то офф-доки такие скудные, что хер поймешь как оно работает на самом деле.

спс, а то офф-доки такие скудные, что хер поймешь как оно работает на самом деле.

рекомендую тогда вот тут ещё почитать http://learnyousomeerlang.com/more-on-multiprocessing#selective-receives

я эту книгу с одного захода прочитал

там с картинками всё классно разжёвано

дока у эрланга недружелюбная, да

не, уже все ясно

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

И еще. Насколько я понял GenServer по умолчанию генерит некий умолчальный handle_info, который все неизвестные сообщения выбрасывает из очереди. А если я задам некий handle_info реагирующий на определенный тип сообщений, то будет ли опять сгенерирован умолчальный handle_info для левых сообщений или таки этот "спам" будет засирать мою любимую очередь?

GenServer в Elixir-е да, и будет все эти сообщения в лог отправлять: received unexpected message in handle_info/2:

Нет, сгенерирован не будет.

Но если не будет catch_all функции, то он просто крэшнится при получении не подходящего сообщения.

GenServer всегда все сообщения из очереди выгребает.

А насколько большая очередь может быть?

настолько - насколько оперативы хватит?)

@JustStealIt Ага, пока OOM не прибил VM.

кстати из этого следует что если у вас что то ушло в рекурсию и проебались условия выхода то пока они не сожрут память и VM не прибьет ООМ они будут занимать память и крутиться вечно

Потому мониторинг - обязательная вещь.

Антибот?))

дока у эрланга недружелюбная, да

по мне так в 100 раз лучше чем го)

Привет! Можете посоветовать библиотеку клиент для Phoenix на Objective-C ? Взаимодействие с каналами феникса (чат)

Привет! Можете посоветовать библиотеку клиент для Phoenix на Objective-C ? Взаимодействие с каналами феникса (чат)

Возьми любой с вебсокетс

там какой-то особенный формат сообщений. На js у меня сходу не получилось написать. Только с использованием оф библиотеки

для swift есть, думал для objective-c есть что путнее

готовое в смысле

jetfire/README.md at master · acmacalister/jetfire · GitHub https://github.com/acmacalister/jetfire/blob/master/README.md

спасибо, попробую!

Подскажите, а когда в тестах для феникса нужен контекст %{conn: conn}?

Мне пишет ворнинг, что нужно использовать build_conn, как начинаю его использовать, пишет, что conn is unused

Привет! Можете посоветовать библиотеку клиент для Phoenix на Objective-C ? Взаимодействие с каналами феникса (чат)

выкинь из схемы каналы и тебе сразу станет сильно проще

хотя, это предложение наверняка очень опоздало

выкинь из схемы каналы и тебе сразу станет сильно проще

не совсем понял, что имеется в виду. Выкинуть каналы при написании клиента или на сервере?

вообще не используй каналы феникса. и феникс по сути тоже.

херовый какой-то совет получился

ну нет. Я уже написал сервер работающий. На каналах все завязано, вся маршуртизация

это пусть мобильные разработчики разбираются ))

ну вот в этом и проблема, да