@bernik: всегда есть варианты старого доброго vps и dedi от гигантов вроде ovh и hetzner до мелких частников, сидящих на прямх каналах к публичным internet exchange (для россии лучше франкфурт)

а я не думаю что повторить акторы на core.async просто, все таки акторы и CSP отличаются сильно, например в акторах нет никаких гарантий что сообщение дойдет

слышал что на java вобще модель акторов нэффективно работает

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

ээ, реально? Я прям стышал что акка это прям чуть-ли не лучшее что есть у скалистов

или проблема реально с жавой как язык, а не с JVM вообще?

Проблема в том, что JVM — не VM для акторных языков.

Чтобы акторы работали нормально, они должны быть дешёвыми. Настолько дешёвыми, что было бы не страшно пару-другую сотен на каждое подключение запустить.

HiPE и другие эрлаговые VM сделаны так, чтобы запуск нового процесса, его жизненный цикл и помирание занимали микросекунды.

В JVM оттюнен жизненный цикл объектов, а в HiPE основной объект оптимизации — процессы.

эм, не очень понял - core.async работает же и создание канала дешевое за счет еще одной абстракции над потоками. Тоже самое как я понимаю у акторов

или мы о разном?

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

@artemyarulin: В акторной модели декомпозиция задачи происходит на кучи кооперирующихся процессов. Если у тебя натуральным образом обработка разлагается на 50 акторов, а ограничения VM заставляют тебя сделать 2 потока, то это не позволяет тебе писать естественный код.

а эм, а как это отличается от core.async когда я делаю 50 каналов? сори, я нуб просто в JVM самом

Кто слушает эти каналы?

Я сам отвечу, что какой-то код :)

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

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

ааа все упонял

спасибо

Тиресна: https://github.com/puniverse/quasar https://github.com/puniverse/pulsar

Кто-нибудь щупал?

@aav: @shinych: У вас на этом ^ или ручками, без зелёных потоков?

@dottedmag: ручками

https://habrahabr.ru/post/282986/

Сассман назвал две причины; впрочем, сразу замечу, что в первой из них нет ничего особенного. К 1997 году Абельсон и Сассман уже устали рассказывать практически одно и то же с 80-ых, поэтому решили оставить преподавание и предложили главе кафедры самостоятельно решить, как поступить с самим курсом. Здесь удивляться действительно нечему — что угодно может осточертерть, если заниматься им достаточно долго. Впрочем, вторая причина гораздо серьезнее. По мнению Сассмана, они с Абельсоном осознали, что учебный план SICP больше не в силах подготовить инженеров к тому, что представляет собой «инжиниринг» сегодня. В 80-ых и 90-ых инженеры строили сложные системы, комбинируя простые и хорошо изученные «части». Целью SICP было предоставить язык абстракций для рассуждений о таких системах. Сегодня дела обстоят не так. Сейчас инженеры обычно пишут код для сложного аппаратного обеспечения, которое они не до конца понимают (причем часто это происходит по причине коммерческой тайны, а не в силу лени или недостатка времени — взять ту же Apple и ее технологии). Это же утверждение справедливо и для программного обеспечения, поскольку программные окружения состоят из гигантских библиотек с широчайшей функциональностью. Согласно Сассману, сегодня его студенты большую часть своего времени тратят на чтение мануалов к этим библиотекам, чтобы разобраться в том, как связать их вместе с простой целью — чтобы всё заработало и сделало то, что им нужно. Со слов Сассмана, «Программирование сегодня больше напоминает науку: вы берете часть библиотеки и «тыкаете» в нее — смотрите на то, что она делает. Затем вы спрашиваете себя, «Могу ли я настроить это так, чтобы оно делало то, что мне нужно?». Подход «анализ через синтез», используемый в SICP, когда вы строите большую систему из простых, маленьких частей, стал неактуальным. Сегодня мы программируем «методом тыка».

блин так и не успел прочитать, а уже неактуально стало(

Еще как актуально

просто рынок изменил условия

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

синтезировать что-то

Если большинство просто юзает готовое и что-то комбинирует то это не значит что теперь везде так. Рич синтезировал clojure и он крут... теперь это просто другой уровень

те кто наигрался фреимврками.. думаю меня поймут))))

да я пошутил конечно.

чутка оффтопа - а чо как скала вообще? Совсем прям г? Если по рукам бить и не юзать все подряд то можно писать нормальный код? А то прям везде все ноют что там ад и садомия, сложно и куча всего что ток можно, может это все неосиляторы?

Если по рукам сильно бить, Java получится, я думаю)

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

дада, я тоже видел ту презентацию)

просто у них там скала.жс, интересно посмотреть как чо там

и там кажись с иммутабельностью не все в порядке

дада immutable list of mutable values 😄

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

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

ну там да, как я понимаю она и так и так умеет

все умеет. "immutability by convention”(c)

хотя сами упоротые из лагеря джихадистов статической типизации частенько грешат насильственным приведением типов )))))

immutability by convention и в C можно сделать :)

ага, вот это и останавливает все

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

Продолжайте играться с хаскелем

на худой конец еще ерланга поковыряйте для расширения сознания

@artemyarulin: http://haskellbook.com/

@malch: Ага спасибо, я уже прочитал пару книжек - счас руку набивать надо чтоб прочувствовать все эти монады) За ерланг спасибо, тоже смотрел его как-то. Ну ок - буду значит дальше хаскель капать

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

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

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

оо, вот отлично. У меня похожая идея - логику в кложуре, а весь IO на хаскеле

а вы планируете какой-то сервис держать на хаскеле?

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

можно на ты, а то прям не удобно) Нене, у меня react-native приложение на ClojureScript

ну еще второе приложения как идея - там уже мобайл+браузер+бек

ааа, понял. Я это дело только на серверной стороне юзаю.. на клиенте простой clojurescript

а как хаскель на мобилах? уже зрелый?

ну в JS мире обмениваться не проблема - оба языка умеют интероп, т.е. создать js объект совсем не проблема. На беке - ну тут я хаскель не буду смотреть, там у них конечно все есть, но тот же netty|aleph им не переплюнуть) ну хаскель умеет компилится в JS, а значит умеет и мобайл. Вот как пример https://github.com/jyrimatti/hseverywhere

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

если только веб ассембли там какой-то допилят и повсеместно внедрят.. тогда только

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

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

"Весь IO на хаскеле" взорвало мой мозг.

а шо?

ну может человек монадами проникнуться хочет

хочу ага

Все разы, когда я видел гибрид, логика была на хаскеле, а общение с внешним миром — на чём-то ещё.

ну или так тоже сойдет, я еще не продумал до конца)

Гыгы.

@pacman: Компилятор хаскела — штука очень интересная. От исходной программы не остаётся и следа.

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

и понесёт меня

а тут проекты горят.. таски.. делать надо

а в голове хаскель

недаёт

@pacman: а как крестил? у нас помимо otplike еще одна либа разрабатывается, как раз для того, чтобы из кложаскрипта эрланговские ноды пинать

а я просто из кложи пинаю

Как?

Через эрланговый протокол?

а так напрямую через веб тоже можно.. только там жсоны (((

да

через протокол

поднял ерлан ноду рядом

Т.е. кложа работает external node в эрланговом кластере?

Как C node?

ну у меня хаскеля нет.. у меня кложура как веб висит с бизнеслогикой. а рядом тут же нода ерланга

ща сину код

там немного

под себя правда перепилил.. так как со строками иногда непонятки

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

а там все остальное нормально конвертится

вот клиент простенький

для вызова процедур ерланговской ноды

синхронно

асинхронно тоже можно и сообщениями плеваться в обе стороны, но мне пока это ненадо было

А, через Java API. Аккуратненько и чистенько.

ну да

Уф как слак расплющило от открытого сниппета.

заюзал отработанный жаваклиент

обернул его в кложу и нормально

снизу 2 тестовый функции для примера

чота моей слаке тоже плохо. Но плюс за код, круто. А почему ерланг? Он вроде умеет лучше с бинарными протоколами работать?

вот в том и прикол

мне надо по телнету кудато слазить

я вручную его легко реализвал на ерланге

или пингануть чего

и на ерланге можно сразу кучу вокеров запустить и небольно

@artemyarulin: Эрланг — это зашибительный сетевой мультиплексор.

тоесть 150 девайсов одновременно опросить

половино из которых не пингуются может

а ерлангу пофиг

хм, а если кор.асинк здесь поднять? Будет чем-то хуже?

))))))))))))))))))

не пробовал

Просто попробуй реализовать на core.async и на Erlang простой код: взять 150 хостов и пингануть их, с таймаутом и параллельно. Результаты сложить и отдать.

Увидишь разницу в сложности кода.

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

а можно там дальше и целый кластер забабахать

тоже легко

ага, спасибо за разъеснение. Надо дочитать книжонку, а то я тока пару глав по ерлангу прочитал

ну еще ерлангом милое дело бинарные данные пачками выкавыривать.. например подписи с файлов или еще чего

по ftp чтото выкачивать или по http обращатья... дёшево получается бинарные видеопотоки транслировать к примеру

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

@shinych: в общем если надо из кложурскрипта юзать.. то наверное проще через http . поднять на ерланге ковбоя (веб вервер) и выполнять запросы либо вообще вебсокеты обрабатывать. В качестве протокола обмена можно юзать json или даже попробовать вот это https://github.com/isaiah/transit-erlang

а вообще классно было бы если бы Clojure на ерланге тоже мог паразитировать

у нас есть поделие csi (ClojureScript Interface). цепляется к эрланговской машине по вебсокету. со стороны эрланга такое соединение выглядит как процесс, которому можно что-нибудь, заслать, и оно прилетит в клиенту. со стороны клиента можно послать сообщение любому процессу. вообще это +- аналог эрланговского JInterface

туда-сюда гоняем ETF (Erlang Term Format), сериализатор-десериализатор у которого у нас свой

ого, я думал кложура + ерланг это очень специфичная штука, а тут оказывается каждый второй А вы @aav почему ерланг дополнительно юзаете с кложурой?

@aav а у вас один процесс висит на ноде эрланга или вы там пул делаете?

@pacman: каждый коннект с клиента - это отдельный процесс, на стороне эрланга

@artemyarulin: потому что clojure - это jvm, а erlang - это erlang

@artemyarulin: и строго говоря это не не эрланг дополнительно, а clojure дополнительно. задача формулировалась “как писать ui на cljs к эрланговскому проекту"

там, еще про otplite был вопрос. по сути это симулятор (на сколько это возможно) эрланговской семантики процессов поверх core.async. т.е. наш “процесс” ничем не отличается от (go …) кроме того, что он знает такие вещи как link, monitor, trap, позволяет регистрировать такие “процессы”. на его основе есть gen_server, скоро будут супервизоры.

смысл затеи не в том чтобы повторить эрланг, в рамках jvm это не реально. а в том, чтобы повторить эрланговские patterns, в первую очередь, gen_server

а вообще если не секрет, у вас ерланг для каких задач?

в одной - это machine vision в soft real time контексте. конкретно - распознавание лиц на видео-потоках. не кооперативное.

другая задача (я про нее гораздо меньше знаю) это, можно сказать, очень хитрый спулер для high volume printing

круто 👍

для принт-центров, которые печатают, в частности monthly statements для visa

Вот всегда так, как только контора из Германии, так сразу же что-то реальное, а не хипстерчат с фоточками еды.

ну, справедливости ради, первое - это в большой степни в россии происходит

Окей, офис в германии :)

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

вот надо взять волю в кулак и csi с otplike на гитхаб выложить

интересно - а почему решили cljs для фронта? ну т.е. рассматривали что-нить еще, или просто CLJS это самое похожее на ерланг?

@artemyarulin: ну а на чем еще? elm / purescript слишком экзотично, всякие N2O вообщем, тоже

Ха, у меня сейчас как раз куча вкладок на оба Pure/Elm открыто, да экзотика пока

@artemyarulin: для воинов духа - это вполне way to go. но нам, например, немецких автомобилистов на clojurescript уговорить некоторых усилий стоило. elm/purescript не думаю что они бы осилили.

дада, ну круто вообще cljs + erlang, няшно

@aav вот вы упомянули распознавание лиц.. в реалтайме. у вас это все чисто средствами ерланга реализовано или какие-то вещи. которые требуют производительности положим на си написаны?

@pacman: эрланг только “управляет” - все что надо быcтро (С/С++) ну и критические вещи на GPU живут - CUDA

на низком уровне у нас есть нативные демоны, которые эрланг стартует (open_port, etc) и за ними следит. между демонами и эрланговским кодом - protobuf

@avv благодарю за ответ... Значит все таки CUDA.

ну впринципе классно

а вот для CUDA, это какие-то особые сервера надо использовать?

@aav что на куде считать? Пример можно?

Ну они анализ изображений делают

мало ли. всякое бывает

может спектрограммы какие обсчитывать в реалтайме

@az например Face Detect, у нас своя варианция на тему каскадов Haar'a

А, с телефона не долистал историю

@pacman: а запускать - да нужны gpu. можно бытовые, можно всякие дорогие профессиональные (серия Tesla)

а вообще у нас даже на таком живет - http://www.nvidia.com/object/jetson-tk1-embedded-dev-kit.html

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

@pacman: я вот тут не очень уже хорошо знаю подробности. там есть нюансы что не во всякий сервер можно gpu засунуть, и там с питанием/охлаждением тонкости есть

на AWS дают виртуалки с GPU

@dartov: дают, и не только там. но довольно дорого выходит.

да, это для богатеньких буратин 😞

https://www.nimbix.net/

мы вот тут кластер тестировали. но нам для эксперимента пары часов хватало.

и больше где-то 15 нод получить не выходило - говорило что “нет свободных"

а они через openstack api дают ноды заводить?

или только мышкой?

какое-то api там есть

но нам и “мышкой” вполне хватало

$2.80 в час сейчас нода с K40 стоит

и 3.50 с двумя

а g2.8xlarge это эквивалент чего у них?

High-performance NVIDIA GPUs, each with 1,536 CUDA cores and 4GB of video memory

это как 1/3 одного К40

да, разница приличная

но у амазона удобно что трафик с S3 бесплатен, все рядом

вообще спасибо, очень интересные предложения

тачка с двумя К80 с оплатой по часам

> чутка оффтопа - а чо как скала вообще? Совсем прям г? Если по рукам бить и не юзать все подряд то можно писать нормальный код? А то прям везде все ноют что там ад и садомия, сложно и куча всего что ток можно, может это все неосиляторы? ну вот я на скале несколько лет пишу уже. язык и язык, есть плюсы и минусы. clojure попроще, конечно.

ребят, мне одному кажется, что JWT как-то не очень быстро энкодится

или я чего-то не понимаю, или сейчас это самое медленное место в API

@az: Подробнее, пожалуйста.

@az: JWT в смысле "JSON Web Token"? Подписанный?

@az: HMAC или RSA?

да

rsa

у меня сжирается много CPU

короче в связке с eventmachine-ой так себе получается

на clojure - е сыкотно пока проекты писать

% openssl speed rsa4096
Doing 4096 bit private rsa's for 10s: 1632 4096 bit private RSA's in 9.99s

Потому что RSA очень медленный алгоритм с большими ключами, конечно.

Маленькие ключи сильно быстрее: Doing 2048 bit private rsa's for 10s: 11872 2048 bit private RSA's in 10.00s

Но пользы от них ноль.

2048 bit уже вычисляются чтоли?

Сегодня ещё нет.

вообще если данные на сервисе не особо секьюрные то и HS256 с secretkey за глаза

Ключевое слово — сегодня.

сегодня как раз задеплоил на нем сервис в прод

по сбору статистики

У HMAC-SHA256 совсем другие секурити-свойства.

@serioga: просто как то очень смущает количество критики про скалу, особенно от адептов фп

да потому что: хочешь писать императивно — пожалуйста, ооп? да ради бога, фп? легко

аа т.е. fp by convention

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

дада именно это я и читал

пришёл умник, написал код с использованием scalaz, простые парни с опытом java даже со стаканом не разберутся

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

scalaz - это попытка реализовать стандартные монады и прочие штуки из теории категорий на скале

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

в некотором роде scalaz - это попытка из scala сделать хаскель)

удачная?

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

в scala это выглядит все очень overcomplecated

и не очень дружелюбно)

в отличае от хаскеля, где система типов позволяет все это красиво реализовать

в scalaz городят всякие технические извороты

зато элементарные функциональные вещи с стандартной поставке вызывают геморрой например аналог (comp f1 f2 f3)

typeclass-ы в scala реализовать так же как в хаскеле просто невозможно

отсутствие синтаксиса для данных вида {:a {a: {:a {}}}} тоже огорчает

да, это вообще боль

работа с immutable nested структурами - это та еще задачка

спасибо за инфу. а скалу.жс вы не смотрели? как оно по сравнению с cljs?

решается как в хаскеле линзами - но это уже очень сильные колдунства для скалы)

ну а для бизнеса version fragile серьёзная проблема, хотя я на практике сильно не страдал от этого, больше переход java7→java8 вопросов вызывал

> а скалу.жс вы не смотрели? я не сталкивался

скалу.жс не смотрел, но я мне просто не верится что у них там все хорошо)

😄

с самим scalac бы до конца разобрались)

и с тем как это все ворочается под jvm)

ладно останусь тогда с хаскелем пока, спасибо ребят!

макросы я в скале не осилил, тоже ещё магия

вообще все эти их тенденции с переименованиями typesafe в lightbend-ы тоже ничего хорошего)

макросы - это адский ад)

если на template haskell народ поругивается, то уж scala макросы - это за гранью добра и зла)

всякий hype про reactive programming мне тоже непонятен

в clojure открываешь rationale, смотришь и видишь, зачем и почему намутили, решаешь, надо оно тебе или нет

ну вот как раз typesafe две идеи и двигают typesafe и reactive)

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

правда скала по сравнению с хаскелем типАбезопасный язык)

и видимо ребята решили от греха подальше сменить название)

в общем я со скалой по прежнему работаю, а на clojure микросервисную архитектуру леплю

а так сама jvm в целом устраивает, когда опыта с ней наберёшься

у скалы сейчас есть три достаточно серьезных продукта - kafka/spark/play framework

акка не?

акка все же далеко не так популярна

> play framework не трогал. я на liftweb вырос

да, были забавные холивары в свое время почему в typesafe stack не взяли lift

если бы в akka akka-http был действительно хорош, думаю у неё было бы гораздо больше сторонников

интересно, твиттер свой heron (заменитель сторма) собираются опенсорсить? он тоже на скале 100%.

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

может и достаточно популярна, просто у меня опыт такой:)

может akka в каких-то задачах и популярна лично мне распределённые акторы как-то не понадобились

а heron вроде как на pure java

есть инфа? интересно почитать.

да вроде никакой инфы особо не раскрывали, давненько уже читал только что мол быстрее, выше, сильнее и да, решили на чистой джаве

аа, я может упустил этот момент. интересно, почему на чистой джаве решили.

потому что шустрее

jit скалу оптимизирует как повезет и результаты трудно спрогнозировать)

плюс scala - это по большому счету все равно дополнительный слой поверх джавы и оверхед привносит в любом случае

ну да, понятно.

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

но вычислительный оверхед не страшен, если он улучшает жизнь разработчика

в том то и дело, что разница есть, например, если посомтреть на то как в scala были функции/лямбды реализованы до интеграции с java8

как раз для таких систем как heron - вычислительный оверхед не желателен, генерится куча объектов, жрется память, растет время и продолжительность gc, растет latency

все это критично

неплохой доклад, кстати на тему скалы и перфоманса http://www.youtube.com/watch?v=M7ptT_yY97U

только гугл что-то не может мне рассказать, что heron написан на яве

а, нашёл пдфку

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

http://delivery.acm.org/10.1145/2750000/2742788/p239-kulkarni.pdf

в общем, там наверчено — читать страшно

я тоже ее сейчас читаю – “The Heron Instances are written in Java, as they need to run user logic code (which is written in Java). There is one JVM per Heron Instance."

но это воркеры только – там еще метрики всякие есть и тд

Какие весёлые графики в конце.

"Всё лучше стало"