Нужна экспертиза при переводе проекта на Эрланг

[Олег]

Наша  компания, которая более 10 лет работает в области электронных закупукок. В свое время проект был написан на Perl. Т.к. многое изменилось и Perl уходит с рынка - хотим переписать систему. Рассматриваем Erlang как один из возможных языков. Язык нравится, просто заводит:) Проверили стек возможных библиотек - все что нужно есть. Можно двинуться в путь, но ...

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

Как вариант - можем взять в команду специалиста, но все же хотим попробовать осилить своими силами.

Есть ли желающие давать советы за деньги? 

[Alex Chistyakov]

А Вы бы не могли поподробнее рассказать, что именно заставляет Вас рассматривать Erlang в качестве основного языка для построения веб-системы?

Спасибо,

--

SY,

Alex

--
Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Naim Shafiev]

да и зачем переходить с перла, на нем есть очень и очень развитые ORM и веб форки , также по асинхронному есть тот же Coro и anyevent

[Alex Chistyakov]

Вот да.

Perl, конечно, умирает, но умирать ему еще лет двадцать.

Любой проект умрет значительно раньше, к Земле летит комета.

--

SY,

Alex

[Vladimir Lashko]

Как показывает опыт, найти программистов на эрланге тяжелее чем на перле.

Так что с точки зрения бизнеса  такая замена это даже не шило на мыло, а гораздо хуже.

20 января 2016 г., 21:28 пользователь Alex Chistyakov <alex...@gmail.com> написал:

--

Best regards, Vladimir Lashko

email: ostr...@gmail.com

cell: +79262299812

[naim]

Да и  также перловое русскоязычное комьюнити довольно дружное на примере той же группы moscow.pm

[Aleksey Kluchnikov]

Для написания скелета лучше нанять специалиста. Потому что на erlang простой язык, но надо писать на OTP, а это уже фреймворк, с ним нужен опыт. И человек будет счастлив писать прототипы :)

20 января 2016 г., 22:32 пользователь Vladimir Lashko <ostr...@gmail.com> написал:

[Aleksey Kluchnikov]

А чего все так против?

Не хотите разбавлятся перловиками? :))

20 января 2016 г., 23:30 пользователь Aleksey Kluchnikov <kluchn...@gmail.com> написал:

[Yuri Zhloba]

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

20 января 2016 г., 22:32 пользователь Aleksey Kluchnikov <kluchn...@gmail.com> написал:

--

Yuri Zhloba

skype: yzh44yzh
phone: +375 44 793 33 73

[Олег]

Чувствую в этой теме сейчас смешаются три вопроса:

1) Стоит ли переходить на Erlang с Perl?
2) Если да, то какую стратегию выбрать? Учить старую команду? Брать тимлида на Erlang? Привлечь консультанта(тов) для старта?
3) Конкретно про наш проект, почему для него близок Erlang.

По вопросу №3:

У нас - система электронных торгов. В принципе  - достаточно стандартная веб система. Очень близко к электронному магазину. Но есть свои особенности связанные с торгами:
 - требуедся высокая надежность, чтобы пользователи не кричали "ой ой аукцион остановился", любые проблемы в торгах очень болезненно воспринимаются клиентами.
 - очень желательна горячая замена кода, чтобы не прерывать торги.
 - масштабируемость внутри кластера, балансировка нагрузки, ну это как всегда
-  требуется распределенность системы по узлам, разнесенным в разные страны (пока есть несвязанные узлы в Росии, Узбекистане и Китае), но очень хочется наладить обмен данными между узлами.

Есть еще сугубо личное отношение к Erlang из разряда ... почитал, попробовал(https://github.com/OlegUm/go2erlang), понравилось:)

[Sergey Yelin]

Приветствую,

Если вы решили вот так прямо сразу всё переписать на другой язык - это уже вызывает некоторое беспокойство. 

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

Доверьте написание прототипа самым опытным и проверенным товарищам и строго с них спросите потом. Ответы типа “Михалыч, я посмотрел либу/написал прототип - всё ништяк, нам подходит!” сразу в корзину, так как потом может выясниться маленький нюанс, который похоронит проект. Ну или сделает его поддержку дорогой. 

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

Разработчиков на Erlang в России действительно мало, опытных ещё меньше, стоящих - единицы. Найти такого и привлечь к своим проектам редкая удача, а вам нужен именно такой, раз вы решили поставить судьбу проекта на карту. Так что удачи! :)

---

Best regards,

Sergey Yelin.

[Yuri Zhloba]

Выглядит как проект, подходящий для эрланг. Однако и достаточно сложный, посему опытный эрлангист в команде нужен.

21 января 2016 г., 9:49 пользователь Sergey Yelin <eli...@gmail.com> написал:

[Alex Chistyakov]

2016-01-21 10:42 GMT+03:00 Олег <zp.tp...@gmail.com>:

Чувствую в этой теме сейчас смешаются три вопроса:

1) Стоит ли переходить на Erlang с Perl?
2) Если да, то какую стратегию выбрать? Учить старую команду? Брать тимлида на Erlang? Привлечь консультанта(тов) для старта?
3) Конкретно про наш проект, почему для него близок Erlang.

По вопросу №3:

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

Коллеги-эрлангисты, а напомните pls, у кого в этой группе реально работает в продакшне горячая замена кода?

--

SY,

Alex

 

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

Есть еще сугубо личное отношение к Erlang из разряда ... почитал, попробовал(https://github.com/OlegUm/go2erlang), понравилось:)

--

[Yuri Zhloba]

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

21 января 2016 г., 9:54 пользователь Alex Chistyakov <alex...@gmail.com> написал:

[Eax Melanhovich]

Erlang очень хороший язык. Но я боюсь, в данном случае вы с большой
вероятностью хотите использовать его для не самой удачной задачи. В
статье http://eax.me/erlang-one-year/ и там по ссылке в конце можно
ознакомиться с подробнейшим моим видением этой ситуации.

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

--
Best regards,
Eax Melanhovich
http://eax.me/

[Eax Melanhovich]

> Если вы решили вот так прямо сразу всё переписать на другой язык -
> это уже вызывает некоторое беспокойство.

Нет, что действительно вызывает беспокойство --- это 10-и летний проект
на Perl :D Так что желание все переписать тут _совершенно_
естественное. Тем не менее, +1 за:

> Не нужно вот так сразу переписывать всё на другой язык.

[Alex Chistyakov]

2016-01-21 11:06 GMT+03:00 Eax Melanhovich <afi...@devzen.ru>:

> Если вы решили вот так прямо сразу всё переписать на другой язык -
> это уже вызывает некоторое беспокойство.

Нет, что действительно вызывает беспокойство --- это 10-и летний проект
на Perl :D

А 10-летний проект на Python был бы лучше, что ли?

Ну, окей.

 

Так что желание все переписать тут _совершенно_
естественное. Тем не менее, +1 за:

> Не нужно вот так сразу переписывать всё на другой язык.


--
Best regards,
Eax Melanhovich
http://eax.me/

--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.

Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу erlang-...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Eax Melanhovich]

Вы говорите так, словно не был бы :D. Ну, окей.

[Yuri Zhloba]

Переход на Python я могу одобрить, а вот на Go вряд ли. Тоже магринальный язык, на котором мало разработчиков. Только к задаче он подходит хуже, чем Erlang.

21 января 2016 г., 10:13 пользователь Eax Melanhovich <afi...@devzen.ru> написал:

--

[Sergey Yelin]

Как раз-таки нет. Долгосрочные проекты одного языка это довольно распространённое явление. Ничего страшного тут нет. Если есть проект, в проекте люди с экспертизой и опытом, на рынке достаточное количество разработчиков, готовых за деньги разработчика этот проект поддерживать и развивать, то странно менять одну платформу, пусть не очень популярную, на другую не очень популярную платформу. Не понимаю профита. Или возможно топикастер чего-то не договаривает. ;)

Другое дело, если речь идёт о том что, часть системы не удовлетворяет каким-то требованиям и камрады хотят попробовать её заменить/переписать на что-то более подходящее, например, на Erlang, который, судя по отзывам, хорошо подходит для поставленной задачи. Звучит конкретно, разумно, возможно даже не нарушает NDA, что, как следствие, может повысить качество данной дискуссии.

---
Best regards,
Sergey Yelin.

[Alex Chistyakov]

2016-01-21 11:27 GMT+03:00 Yuri Zhloba <yzh4...@gmail.com>:

Переход на Python я могу одобрить, а вот на Go вряд ли. Тоже магринальный язык, на котором мало разработчиков.

Прочесть эти две фразы в рассылке Erlang - бесценно!

Это на Go-то мало разработчиков?

Окей.

--

SY,

Alex

 

[Vladimir Lashko]

Не холивара ради, про поиск людей.

Искать людей на перле сложно, всех выгребают те крупные/старые, кто уже имеет кучу кода на нем – мыло, яндекс и тд.

На эрланге еще сложней – их просто нет.

На ГО? В нашей компании за год их, наверно, уже больше 40 гоферов собралось. Язык прет по популярности. Лет через пять он будет распространен в вебе как сейчас ПХП :). Если дать зарплату чуть выше рынка, то при выборе можно будет ковыряться в кандидатах.

Могу судить, тк сам +14 лет в основном на перле, последнии 2 года на GO.

21 января 2016 г., 11:58 пользователь Alex Chistyakov <alex...@gmail.com> написал:

[Олег]

На самом деле у нас в команде как раз сложилась дилемма Erlang vs GO.

Я - болше за Erlang, руководитель разработки - больше за GO, но четкого выбора не сделали т.к. решили попробовать написать примеры/прототипы, разобраться и выбрать уже более осознанно.

[Yuri Zhloba]

Эта дилемма легко решается -- каких людей найдете, на том и делайте )

21 января 2016 г., 11:30 пользователь Олег <zp.tp...@gmail.com> написал:

На самом деле у нас в команде как раз сложилась дилемма Erlang vs GO.

Я - болше за Erlang, руководитель разработки - больше за GO, но четкого выбора не сделали т.к. решили попробовать написать примеры/прототипы, разобраться и выбрать уже более осознанно.

--

Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Sergey Prokhorov]

Было бы гораздо проще что-то советовать, если бы вы чуть детальнее описали ваш проект.

Какие нагрузки. Много мелких клиентов или немного, но совершают множество запросов.

Какого рода операции он выполняет. Много вычислений/CPU или сходил в базу, вернул JSON-ку.

Это веб-сайт или REST апишка или что-то не HTTP? Есть ли долгоживущие подключения клиентов.

Зачем вам кластер?

Использует ли ваш текущий проект каких-то perl-демонов/воркеров или это только веб-приложение по принципу "обработал HTTP запрос и забыл".

Ну и так далее.

четверг, 21 января 2016 г., 12:30:01 UTC+3 пользователь Олег написал:

[Yuri Zhloba]

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

21 января 2016 г., 11:41 пользователь Sergey Prokhorov <seri...@gmail.com> написал:

--

Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Олег]

Эта дилемма легко решается -- каких людей найдете, на том и делайте )

-  Да, это самая мудрая стратегия.

Но есть несколько идей, как ее реализовать:

1) Попробовать сделать прототипы и на Erlang и на GO.  Если потеряем один -два человеко-месяца, то потом наверстаем за счет более правильного выбора.
2) Прототипы можно сделать открытыми - код будет полезен не только нам но и сообществу. Это даже интересо - сравнить  реализации на двух языках.
3) Я заметил, что в Erlang не хватает описания кейсов решения многих типовых задачь типа  "делай так ..." особенно в области применения библиотек, по мере создания прототипов понадобится разобраться с несколькими темами и оформить в виде статей - авторам можем выплатить некоторое вознаграждение. Попробуем извлечь пользу как личную так и общественную.

Разумно ли так подойти к вопросу?

[Yuri Zhloba]

да, сравнить было бы интересно

21 января 2016 г., 11:56 пользователь Олег <zp.tp...@gmail.com> написал:

--
Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Sergey Prokhorov]

Я так понял, речь идёт о http://www.tender.pro/

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

среда, 20 января 2016 г., 20:09:30 UTC+3 пользователь Олег написал:

[Vladimir Lashko]

Судя по ".shtml?" там действительно мамонты :)

21 января 2016 г., 13:50 пользователь Sergey Prokhorov <seri...@gmail.com> написал:

--

Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--

[umatomba]

Если дело с вебом и в команде и так нет опыта erlang, может стоит обратить внимание на http://elixir-lang.org/, тот же эрланг "только на рельсах)"

--

[Naim Shafiev]

да там им надо хотя бы на catalyst или mojo* посмотреть . насчёт если принципиально нужно отказаться от Perl в части веб морды то это на php7.

[Eugene Lisitsky]

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

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

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

Пока ядро команды на этом "собаку не съест" ничего надежного не будет, и приходящий консультант тут не поможет.

 

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

Как у вас устроены торги? 

Есть ощущение, что вы планируете вечно живущую ноду, которая всегда на связи, подключена и быстро работает. Из этого очень часто вырастает система "прибитая гвоздями" к серверу. В этом месте уже можно забыть про масштабирование, особенно географическое. Так же учтите, что против железного сбоя  горячая перезагрузка кода не поможет.

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

 

 - масштабируемость внутри кластера, балансировка нагрузки, ну это как всегда

Проще всего балансировать staleless и по запросам. А если все клиенты "присосутся" к одному серверу - как их отбалансировать? Всех выгнать метлой с сервера, заставить переподключиьтся на другой? Тогда лучше сразу сделать, чтобы они переподключались.

 

-  требуется распределенность системы по узлам, разнесенным в разные страны (пока есть несвязанные узлы в Росии, Узбекистане и Китае), но очень хочется наладить обмен данными между узлами.

А если шардить данные по лотам/торгам/сессиям/и тп.?

Иначе вам будет нужна хитрая система передачи данных между разными ДЦ, сразу же выскакивают варианты сетевых задержек, CAP-теорема и прочие радости. А потом обязательно получится так, что локальный сервер принял ставку пользователя, а удаленный не получил. В итоге локально выиграл аукцион один пользователь, а на другом сервере другой. Вот как разруливать эту бизнес-ситуацию? На мой взгляд, пусть лучше пользователь получит сетевую ошибку или задержку в обновлении данных. Он понимает, что интернет штука ненадежная. А так получатеся продали товар, приняли  деньги, а потом  "извините". 

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

Единое информационное пространство по всем торгам выглядит красиво, но только на бумаге.

Представьте, что один кластер где-то в Австралии стал недоступен для других (это вобщем-то штатная ситуация).

Что выберете:

1. Приостанавливать торги для вообще всех пользователей?

2. Разрешить пользователям купить один и тот же товар несколько раз?

3. Признать торги на "отсоединившемся" кластере невалидными и откатить все действия? Пользователям написать, что они неудачники, им не повезло, потому что у вашего сервера пропала связь с остальными серверами. Только как кластеры узнают, кого считать отвалившимся, а кого нет? Из Австралии картина будет прямо обратная. 

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

Я бы подошел рекомендовал чуть другой путь:

1. Общая масштабируемая архитектура.

2. Собрать ядро команды на нужном языке.Еесли сложно найти - это уже звоночек.

3. Начать с отдельных изолированных некритичных подсистем обкатку и разработку.

4. Выводы по предыдущим этапам.

 

Есть еще сугубо личное отношение к Erlang из разряда ... почитал, попробовал(https://github.com/OlegUm/go2erlang), понравилось:)

--

Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--

Yours,
Eugene Lisitsky

[Eugene Lisitsky]

Уже вроде писали про либы

> Проверили стек возможных библиотек - все что нужно есть.

К сожалению, это "ниочем".

Простейший пример.

В 2010 году в erlang было целых 5 (или даже 6) несовместимых библиотек для работы с  JSON. 

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

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

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

21 января 2016 г., 14:00 пользователь Naim Shafiev <sha...@gmail.com> написал:

--

Yours,
Eugene Lisitsky

[Vadim Nik]

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

[Олег]

Вадим, как можно пообщаться?  По скайпу можно?

пятница, 22 января 2016 г., 11:23:05 UTC+3 пользователь Vadim Nik написал:

[Aleksey Kluchnikov]

А чирканите хоть пару строк чем все закончилось? Интересно же.

22 января 2016 г., 11:46 пользователь Олег <zp.tp...@gmail.com> написал:

Вадим, как можно пообщаться?  По скайпу можно?

пятница, 22 января 2016 г., 11:23:05 UTC+3 пользователь Vadim Nik написал:

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

--

[Aleksey Kishkin]

С json и сейчас зоопарк )) У нас используется mochijson2 но в процессе рассматривания deps обнаружили что зависимости подтягивают себе и jsx и jiffy

Alexey Kishkin

21 января 2016 г., 14:54 пользователь Eugene Lisitsky <lisi...@gmail.com> написал:

[Олег]

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

Что в итоге.

1) Переход на Erlang с другого языка возможен - есть успешные примеры, когда команды в 3-10 разработчиков делали это в разумное время.
2) Первое на что нужно ответить, а нужен ли вам Erlang. Все зависит от специфики проекта. В нашем случае - ответ не очевидный т.к. да, требуется надежность и производительность, но с другой стороны - наш проект - очень похож на интернет магазин с расширенным функционалом электронных торгов. То есть, каждому кто выбирает Erlang  нужно ответить на вопрос "а почему не PHP или Python"?
3) При переходе придется преодолеть большое число проблем, которые с первого взгляда не очевидны.
4) Переход только своими силами - это на 95% огребание ненужных проблем. Поэтому тут есть два решения:
 - взять в команду опытного Erlang разработчика
 - привлечь одного или пару консультантов на время старта проекта.
А еще лучше - совместить эти подходы!
5) Рынок разработчиков на Erlang в России - узок, но не фатально. Кто ищет, тот взегда найдет.
6) Не самым плохим решением будет сохранить часть кода на том языке, на котором ваш проект был изначально (в нашем случае Perl) и использовать Erlang как "Клей".

7) Возможно из-за специфики нашего проекта для нас больше подошел бы elixir+phoenix. Аргументация следующая:
- Очень активное сообщество; если посмотреть на число контрибьютеров - в elixir его библиотеки - оно больше чем у Erlang. Это - первая ценность elixir. Скорее всего, это сообщество будет активно пополняться за счет перетекания из Ruby за счет тех, кто недоволен его скоростью.
- Elixir создает инфраструктуру для быстрого старта (набор стандартных библиотек + phoenix) - меньше "разрыва мозга", когда нужно выбрать одну из 5 близких библиотек.
- Elixir проекты уже выходят в продакшен - по отзывам "отзывы - скорее положительные"
- Выбор Elixir - это некоторый риск, попытка сработать на опережение.
8) Основная проблема с Elixir   -  нужен разработчик или консультант, который вывел свой проект в продакшен и может помочь нам с консультациями на старте.

Так что в выбор Erlang VS Go для нашего проекта я свожу к Elixir VS Go

[Yuri Zhloba]

Ну это еще не итоги, но промежуточная фаза правильная :)

25 января 2016 г., 12:40 пользователь Олег <zp.tp...@gmail.com> написал:

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

Что в итоге.

1) Переход на Erlang с другого языка возможен - есть успешные примеры, когда команды в 3-10 разработчиков делали это в разумное время.
2) Первое на что нужно ответить, а нужен ли вам Erlang. Все зависит от специфики проекта. В нашем случае - ответ не очевидный т.к. да, требуется надежность и производительность, но с другой стороны - наш проект - очень похож на интернет магазин с расширенным функционалом электронных торгов.

3) При переходе придется преодолеть большое число проблем, которые с первого взгляда не очевидны.
4) Переход только своими силами - это на 95% огребание ненужных проблем. Поэтому тут есть два решения:
 - взять в команду опытного Erlang разработчика
 - привлечь одного или пару консультантов на время старта проекта.
А еще лучше - совместить эти подходы!
5) Рынок разработчиков на Erlang в России - узок, но не фатально. Кто ищет, тот взегда найдет.
6) Не самым плохим решением будет сохранить часть кода на том языке, на котором ваш проект был изначально (в нашем случае Perl) и использовать Erlang как "Клей".

7) Возможно из-за специфики нашего проекта для нас больше подошел бы elixir+phoenix. Аргументация следующая:

- Очень активное сообщество; если посмотреть на число контрибьютеров - в elixir его библиотеки - оно больше чем у Erlang. Это - первая ценность elixir. Скорее всего, это сообщество будет активно пополняться за счет перетекания из Ruby Тех кто недоволен его скоростью.

- Elixir создает инфраструктуру для быстрого старта (набор стандартных библиотек + phoenix) - меньше "разрыва мозга", когда нужно выбрать одну из 5 близких библиотек.
- Elixir проекты уже выходят в продакшен - по отзывам "отзывы - скорее положительные"
- Выбор Elixir - это некоторый риск, попытка сработать на опережение.
8) Основная проблема с Elixir   -  нужен разработчик или консультант, который вывел свой проект в продакшен и может помочь нам с консультациями на старте.

Так что в выбор Erlang VS Go для нашего проекта я свожу к Elixir VS Go

--
Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--

[Timofey Koolin]

Две копейки по go:

Достоинства:
1. много библиотек, в основном работают и делают то, что надо.

2. очень прост в понимании

3. Простая кросс-компиляция (например если разработчики у вас на винде работают, а сервер на linux)

4. Никаких проблем с установкой и зависимостями на целевой машине (это было основной причиной почему я на go перешел) - всё таскается с собой внутри бинарника.

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

Недостатки:

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

2. Нет нормального отладчика.

3. Очень многословная обработка ошибок - надо или половину игнорировать или половина кода будет вида if err != nil {...}

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

5. Проблемы с определением своих типов на основе примитивных. Например если сделать type MyType int, то потом через reflection MyType от int не отличить.

6. Горутина не управляется с наружи. Т.е. нельзя сделать что-то наподобие супер-визора и прибивать запущенные горутины снаружи - можно только отправить сообщение "прибейся пожалуйста", а горутина сама должна его принять и обработать. Т.е. например нельзя просто сидеть и слушать сокет - надо слушать его с таймаутом и время от времени проверять пришедшие сообщения (а не пора ли завершиться).

25 января 2016 г., 14:05 пользователь Yuri Zhloba <yzh4...@gmail.com> написал:

--

Blog: www.rekby.ru

[Vladimir Lashko]

Тимофей, жаль что это рассылка про Эрланг, поспорил бы. Но замечу что единственны недостаток по существу это пункт 3. Но еще пункт 2 - тк все отладчики на любителя. Очевидно, что остальные пункты это наследие работы с не типизированными языками и попытками писать как "привык". Это пройдет :).

26 января 2016 г., 13:21 пользователь Timofey Koolin <tim...@koolin.ru> написал:

--

[Timofey Koolin]

Да я в общем-то уже привык уже ко всему - на данный момент Go это у меня основной язык :)

26 января 2016 г., 15:26 пользователь Vladimir Lashko <ostr...@gmail.com> написал:

--

Blog: www.rekby.ru

[Evgeny M]

По поводу перехода на Эрланг и написания первого работающего проекта с нуля, сразу в не просто в продакшн, а в продажу как коробочный продукт в руки неквалифицированных пользователей, могу рассказать пару слов о своем опыте. Года три назад перешел с питона на эрланг, один, без посторонних консультаций. Язык простой, но концепции в нем специфические, и многое привычное придется просто забыть. Проект вы напишете, он будет надежно работать 24/7 без падений, но архитектуру переделывать тоже обязательно будете, потому что часть решений будет принята неправильно. Правда переписывать довольно легко, переход между один gen-server -> по процессу на операцию -> пул процессов делается быстро. 

По поводу прерывания торгов - не думаю что остановка раз в месяц на 5 минут в 3 часа ночи для накатывания новой версии создаст какие-то затруднения. Так что при желании можно обойтись и без горячей замены кода и без шардинга. Нагрузки у вас вряд ли космические. А плюсов от того, что часть данных можно держать в одном процессе в RAM и не думать о синхронизации - много.

Если все-таки решитесь писать, обязательно тестируйте все решения под нагрузкой, есть неочевидные вещи, связанные с иммутабельностью, garbage collector и binary. Прочитайте http://erlang.org/doc/apps/erts/users_guide.html и http://erlang.org/doc/apps/erts/index.html , там нет воды, информация написана очень сжато. Будет велик соблазн использовать mnesia, но если данные не ложатся 100% в идеологию key-value и/или данных много, лучше этого не делать, не надейтесь, что сможете написать нормальную имитацию привычных возможностей SQL-баз поверх мнезия. Но и коннекторы к mysql/postgres, прямо скажем, по качеству так себе. Вообще проблемы с библиотеками могут возникнуть самые неожиданные - например нет библиотеки для генерации капчи и вообще для работы с картинками. Строки опять же, которых нет, но они вроде как есть. Зато есть ets, аналогов которому мало где можно найти, который хорош как in-memory хранилище, с единственным недостатком - жрет много памяти. 

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

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

Сумбурно, но как-то так.

[Олег]

Не прошло и пол года а мы уже во всю пишем на Elixir. Наш выбор был скорее положительным. Хотя, конечно, все можно было написать на чистом Erlang.
Позитивно то, что разработчики на ерланге быстро вливаются в новый язык. Так что те, кто желает перейти на Еликсир - не сомневайтесь, все получится. Но возьмите в команду людей с хорошим опытом на Ерланг.

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

[heiheshang]

То же перешел на Erlang. Был богатый опыт работы на Пролог, как увидел Erlang сразу родным повеяло. Использую для вэба. Посмотрел Elixir + Phoenix, но решил делать на Zotonic. Использую для разработки Zotonic CMS, очень хорошая CMS и фреймфорк для разработки. В последнем проекте понадобилось связать сканеры штрих кодов с бэкэндом. Сканеры физически находятся в разных странах, ставить комп с монитором только для того чтобы отсканировать штрих код и отослать его дальше не хотелось. Взял raspberry pi + usb modem + wifi сканер. На малинке написал простенькое приложение по получению данных со сканера и отсылке данных по MQTT протоколу на сервер на котором Zotonic крутится. Диспетчер видит данные со сканеров в браузере, обновление инфы в браузере через pub/sub. Никаких доп библиотек не пришлось использовать все оказалось в Zotonic. Все обмены бэкенда с фронтэндом через websocket, скорость работы более чем, 4 месяца пока велась разработка , работали на сервере 1 ядро CPU 20 GB SSD 1 GB RAM пинг до сервера был 200мс и ни кто не замечал проблем. Такое провернуть на PHP + еще что то там навряд ли получилось , опыт то же богатый.