Освоение серверного javascript идёт с лютым скрипом и перманентым желанием блевануть. Зато с test first (привет, @squadette) и собственным mock server.
учи уже Erlang. JS в бэкенде как по мне совершенно идиотская идея ‎- Я много страдала
^ this. Для функциональщиков есть erlang, для императивщиков go. А серверный js – такое же неудачное решение, как апплеты на яве. Ну и всегда есть традиционное вроде явы и питона. ‎- 9000
@larhat жить захочешь – не так раскорячишься. ‎- blackout drunk
@vinsentru erlang очень хочу, но пока задачку себе не придумал чтобы. ‎- blackout drunk
@9000 go скучен как фон Триер. Тогда уж Rust какой-нибудь лучше. Традиционно у меня Ruby головного мозга, и если питон ещё куда ни шло, то яву я как-то вообще на дух не переношу. ‎- blackout drunk
пейтон почти то же что и раби (только лучше). но менять одно на другое я хз. поэтому и советую Erlang - практичный, прагматичный и при этом не такой как раби/пейтон. Rust это замена C, писать на этом бэкенд наверное можно, но непонятно зачем. ‎- Я много страдала
«go скучен как фон Триер» — если б у меня была привычка брать цитаты на скриннеймы, вот бы непременно ‎- мяу-фактор
Специально для тех, кто любит руби, есть Elixir, руби-подобный язык на платформе эрланга. Рекомендую. ‎- 9000
@vinsentru ты же знаешь, что каждый раз, когда я вижу/слышу «раби», я убиваю котёнка? ‎- blackout drunk
@9000 да, спасибо, Elixir уже потыкан палочкой изрядно. Вполне неплох (возможно, потому что сделан не последним в рубишной истории человеком), но я пока опять же слабо представляю применимость за пределами рельсоподобного Phoenix, что скучно. ‎- blackout drunk
Elixir претендует быть "лучше чем папа", т.е. Erlang, но по сути это он же. Потому я рекомендую хотя бы почитать книжку по Pure Erlang чтобы понимать общие концепции, а синтаксис уже на выбор. Мне Erlang нравится тем что он очень простой и читаемый, но это дело вкуса. Книжко/сайт вот это, отцы платформы так задвигают про OTP в своих книжках, что хочется застрелиться, а тут все по делу и нормальным языком http://learnyousomeerlang.com/content ‎- Я много страдала
Применимость - любой бэкенд. На pure E. дофига веб-серверов готовых на все вкусы, плюс кролик с нативным коннектом, плюс базы разные всякие. У меня рабочий проект на E. грузит файлики кастомерам и не кашляет. ‎- Я много страдала
@vinsentru кальмара пробовал читать, не дочитал — пока бесполезно без задачек. Вощем, думаю, дозрею когда-нибудь. ‎- blackout drunk
ну там понятно, что Erlang ни разу не язык общего назначения, например работа со строками (включая парсинг) там пиздец медленная. но во всем что касается "отпарсить бинарный протокол и быстро чото кудато переслать" - самое оно. ты скажи какие задачки есть а я скажу ложатся они на E. или не особо. ‎- Я много страдала
^ Да, binary pattern matching там на зависть всем вообще. ‎- 9000
Или там миллион соединений держать, всякие websockets, xmpp, etc — самое оно, кмк. ‎- 9000
у меня практический пример тут. эрланговский веб-сервер Cowboy разбивает URL на токены при парсинге, и конечно использует бинарные строки, потому что они быстрые. А мне надо было из списка таких строк собрать обратно переданную строку, вставив разделитель "/". Соответственно вариант один с конкатенцией строк и преобразованием каждого токена с binary_to_list, а второй путь (предложенный моим бывшим шефом, знатоком Э.) собрать большую бинарь из этих токенов и уже потом конвертить в строку. Ну и там специальный синтаксис для конструирования бинарей и все такое. Так вот это самое конструирование бинарей от 2 до 10 раз быстрее чем конкатенция строк. Потому что там на самом деле вообще ничего никуда не копируется, просто создается новая структура с указателями. ‎- Я много страдала
^ Всё равно, поди, быстрее, чем на руби! ;) (Mutable strings? really?) ‎- 9000
не, они конечно не мутабельные, но там строки это просто list of chars, и оно как-то не особо оптимально сделано. ‎- Я много страдала
@vinsentru: в руби зато мутабельные. в хаскеле точно так же два (и при желании больше) типов строк, встроенный простой и неэффективный на больших размерах (String = [Char]), и эффективный "бинарный" (Text, ByteString, etc). думаю, так же и в ML-ях всяких. ‎- 9000
Кстати, вопрос знатокам. Есть на erlang какое-то подобие рубической sinatra? ‎- blackout drunk
^ ну не то чтобы совсем наподобие, но есть Webmachine для чистого REST-а и вот Cowboy ‎- волна бургерных
Недавно удивился изрядно узнав что http://chicagoboss.org/ выжил и вырос ) ‎- labria
Сowboy же вроде как веб-сервер тупо. Или я не прав. Синатра же не про веб сервер, а про простой DSL для обработки запросов с роутингом, хелперами для разных фронтовых сахаров, хуками до запроса, простым форматом отдачей ответов и вот этим всем. (Я про руби головного мозга предупреждал). ‎- blackout drunk
@vinsentru вот кстати таки понял с чем у меня затык главный. Я не знаю инструментария. Если в эко-системе руби для меня всё ясно и понятно — какую либу для какой задачи взять, как их вместе собрать во что-нибудь полезное и т.д. — то в эрланге нихуя не ясно и совсем не понятно. ‎- blackout drunk
@labria или вот этот ваш чикагобосс. Я правильно шутку понял, что если проводить аналогии, то это такой Passenger из рубической вселенной, над которым все приличные люди только смеются, а в продакшн ставить и не подумают? ‎- blackout drunk
про экосистему все просто. собирается все на основе OTP, тулов много, самый поулярный rebar. в доке к нему и статьях в инете написано чо как. грубо если указываешь в конфиге либы прям линками на гитхаб, оно тянет резолвит зависимости и компилит. релизы генерить тоже умеет. ‎- Я много страдала
теперь что касается собственно либ. это блять сложный политический вопрос, потому что либы есть но их не очень много. я действую по принципу "куда позже был последний коммит, то и юзаю". с другой стороны хачатся зорошо написанные эрланговские либы сильно проще чем пейтоновские например. те я натурально что мне надо форкаю и патчу по необходимости ‎- Я много страдала
про общую структуру в плане "как собрать" читай про принципы OTP, applications и gen_server. вкратце: внутри erlang VM может бежать куча приложений, каждое со своим деревом супервизоров и процессов. у приложения есть.API, ты его юзаешь. то что ты тпишешь тоже отдельное приложение со своим деревом и тд, никто никому не мешает, все работает параллельно. ‎- Я много страдала
ну и вся эта фигня либо работает через API который дает gen_server, либо можно напрямую кидать сообщения в процессы. но по OTP лучше так не делать. процессы же такие легкие, что их реально можно порождать миллионы, они быстро стартуют без оверхеда. думать в терминах приложений и процессов с обменом сообщениями оказывается очень удобно и архитектура выходит простой. ‎- Я много страдала
а, ну и о том, в чем все остальное сосет. сообщения можно кидать не только внутри одной ноды, но и между нодами. те ты можешь одно из приложений вынести на другой хост, связать ноды друг с другом и никто ничего не заметит, будет просто работать. те вширь оно масштабируется очень хорошо. ‎- Я много страдала
@vinsentru это всё в общих чертах мне понятно. У меня с практическим применением ступор наступает. Вот например, про синатру мне никто и не ответил. Вспоминая годы молодые и как это было, я первый раз открыл доку по ней и через 30 минут у меня готов API для, извините, опроса и вывода статуса пачки распределённых виртуалок. Ещё 30 минут и говно webUI на bootstrap, чтобы эту всю байду отображать. ‎- blackout drunk
^ посоветовали же cowboy, webmachine, mochiweb. Лапшин, кстати, рассказывал, что ерланговские сообщения для общения апп на разных тачках лучше не использовать, а использовать стандартные IPC методы. Ну и вообще типа, лучше не рождать слишком много процессов и не слать слишком много сообщений. ‎- адский хардлайн в засаде