@dragoncube не слышал про такое.

@dragoncube рефы, что отделют идентити от стейта наоборт благо. в это соль immutability.

@mike1452 Разговор был в том ключе, что все хотели STM, но в результате он нафиг никому не сдался, и вся сложность рефов оказалась бесполезной: все пользуются атомами.

Но я не помню, где и кто об этом говорил.

@dottedmag аха, спасибо

видимо агенты тоже не очень популярны

Это Stuart Halloway, например, говорил в одной из своих презентаций

Что STM на бумаге - штука отличная, но на практике просто не нужна почти никогда

@dragoncube И с агентами та же ботва, да.

Что агенты, что STM нужны гораздо реже, чем кажется.

Вот и получается, что кложура слишком сложная. Vars слишком много чего в себя вобрал, Refs и Agents не нужны. Можно было обойтись гораздо меньшей кровью 😃

так что, закрываемся?

Нет, просто ментально вешаем ярлычки "deprecated" и "almost always a bad idea"

На конкретные конструкции.

@artemyarulin пошел дальше и выпили кложу с продакшена

@dottedmag STM для специальных задач. например: ОЗУ ныне дешевая. и все счета клиентов можно хранить в ОЗУ. при совершении транзакции можно с помощью STM зачислять и списать деньги, а с помощью агентов, которые дружат с транзакциями внутри STM отослать в kafka в асинхронном режиме данные по транзакции

Так, так, счета в ОЗУ?!

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

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

Если есть кафка, то способы материализации вьюшек из потока событий уже не так важны.

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

типовой сервер 512GB RAM

таких 100

для одной из задач

так что все 80 млн клиентов вполне себе помещаются

еще и с коэффициентом репликации 3

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

@akond угу, чота я раньше думал что кложа это 10х, а в реальности ну может 1.2х модификатор от силы. Функциональное программирование вот это 10х идея, но я тоже самое могу на TypeScript делать, и не трахаться с интреопом в реакт нейтив

@artemyarulin Много траха с интеропом?

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

У меня есть интересная штука: на $DAILYJOB я написал небольшую специфичную in-memory database для специальных запросов и индексов. Ничего off-the-shelf не подошло. На ноде.

Если у меня дойдут руки, я сделаю ещё одну реализацию на Clojure и на ClojureScript и сравню количество кода и производительность.

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

Так отспекать, и всё.

А ты пробовал? Я вот видел либки где спеку прям для всего юзали, а многословна что пипец, лучше уж типы

Уменьшение случайной сложности нужно тем сильнее, чем больше проект, кстати.

Прототип можно хоть на перле писать.

Не нужно всё спекать. Нужно спекать узловые части, по которым стыкуется система.

И критические инварианты.

Если приложение — развесистый UI к REST-у, то спекать долго и кложура не нужна 😄

ну в любом случае - рантайм контаркты + тесты будут всегда меньше чем рантайм контракты + тесты + типы

Да кто ж спорит.

@dottedmag я думаю, что языки очень важны, но вторичны для проекта. на первом месте - люди и процессы. соответственно, если Артем решает качественно задачи на TypeScript значит команда слаженно работает, процессы доставляют value. Однако повторюсь, что по моим наблюдениям: 1) кложа ложится в голову не у всех 2) кложа требует начать думать иначе. Если основная работа на императивном языке, а кложа для pet project максимум, то рано или поздно настает оверхед и работа поглощает, поэтому люди возвращаются в императивные языки. Однако если все время кодить на кложе, то со временем мозг научается не только кодить, но и проектировать системы в целом in a clojure way. Вот тогда кложа сильно выстреливает, т.к. идеи подкрепляются языком разработки.

ну вот, контракты перенести мне на TS проще чем типы в кложуру. Но и хаскель мозг повернул чутка

@mike1452 Ясен пень, что проекты задерживаются и фейлят не из-за инструментов уже много лет как 🙂

ага, я просто на работе на ES6 начал писать, уже 30к строк кода, 6 человек, после того как процесс поставили (тесты, ревью, планирование, архитектура) мы фичи начали выкладывать как горячие пирожки. Тут то я и задумался что язык это второстепенное, если даже не ниже

Простой пример: представим, что в памяти есть какой-то стейт и он постоянно изменяется разными thread'ами. Как в императивном языке передать стейт на другую машину? Тут надо поломать голову, как обеспечить консистентное чтение постоянно изменяющегося объекта, как его сериализовать , как его на другом конце собрать...

@artemyarulin К сожалению, ISeq и другие хорошо продуманные протоколы и форсированное разделение value и identity перенести в мир JS сложнее.

в кложе этих вопросов просто не возникнет.

@artemyarulin Я как-то попытался использовать Immutable.js. Это вырвиглаз.

ну вот я 2 месяца переписывал, 3к строк CLJS (c тестами) - вот один раз за все время мне реально не хватило update-in в итоге просто сделал reduce.

дак оно не всегда и надо, в 90% хватает стандартных

[{name:'John'}].map(c => {...c, email: c + `@domain.com`})

@mike1452 Можно сказать так: 1) мультипликатор кложуры увеличивается по мере того, как команда лучше понимает правила разработки распределённых систем; 2) дизайн кложуры заставляет задумываться о том, как разрабатывать распределённые системы; 3) положительная обратная связь 1) и 2) начинает работать далеко не с начала; 4) мультипликатор кложуры на неопытной команде меньше единицы.

если взять redux (который в этом чатике хаят) дак изменить ничего и не выйдет просто, да и не нужно если про фронт

@artemyarulin а как без репла то живется? пусть и на ES6

а по figwheel не скучаешь?

ага, единственное что меня держало последние пол года. А потом открыл TDD + Jest который перезапускает только тесты которые была заэфечены изменениями и ок. Главное в репле это моментальный отклик - это у меня осталось

ну уж в жс мире всяких hot-reload уже дофега, работают хуже, но в 80% норм

Кстати, господа, подскажите быструю библиотеку для работы с вебсокетами для кложуры? aleph?

весь hot-reload императивных языках очень сомнительная вещь. фиг знает, но у меня подозрение, что на большой кодовой базе с приличным стейтом это все будет фейлится. кстати в последнем докладе Стю Халлоуэй рассказал в чем фундаментальное отличие jshell от repl и почему аналоги repl'a никогда им не станут

@dottedmag бери aleph, он зачотный

@dottedmag мы использовали https://github.com/ptaoussanis/sente

@mike1452 У меня уже есть протокол через вебсокеты, нужно новую реализацию сервера сделать.

А это какая-то обёртка?

Или там можно произвольный вебсокетный протокол реализовать?

Если через веб-сокеты ты будешь передавать некие структуры данных по своему алгоритму, то why not, sente подойдет.

>весь hot-reload императивных языках очень сомнительная вещь ой да ладно там, договорились в начале что весь стейт в redux storage и ок

Клиент уже есть с джысон-протоколом.

сервер в сенте уже сделан http-kit, Immutant v2+, nginx-clojure, node.js, Aleph

Т.е. можно просто взять алеф 🙂

Это вообще сервер-ту-сервер.

слово "договорились" смущает. я правильно понимаю, что если в команде, кто-то случайно не в redux storage положит, то договор развалится?

От стейта в (def) тоже никто не убережёт 😃

мы в контексте hot-reload

а если кто-то в команде случайно атом сделает то чо?

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

@artemyarulin ну может и правда есть repl в императивных языках. если попадется на ютубе ролик, скинь плиз, очень интересно посмотреть, как работают в repl'e в языка с мутабельными данными

просто до сих пор не видел

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

В Erlang ещё. Но Erlang без мутабельных данных 😄