Комментарии 19
НЛО прилетело и опубликовало эту надпись здесь
На мой субъективный взгляд, в качестве промышленного языка общего назначения лучше Clojure сейчас ничего нет, учитывая наличие готовых библиотек и средств разработки. А также возможности использования Clojure/ClojureScript для веб-приложений.
А то, что Clojure — это LISP, говорит о том, что, наконец то, то было круто в теории, стало круто на практике :).

Соглашусь с автором в том что Clojure отличный язык. Годовой опыт коммерческого использования не дал мне повода для сомнений а наоборот подтвердил это. Язык очень простой, писать и проверять код очень просто. Как следствие при меньших трудозатратах выход намного выше.
Но. Касаемо использования данной библиотеки у меня сомнения, точнее не вижу вообще в ней смысла. Так же как не нашел смысла в core.async, 99% atom'ы и agent'ы решают задачи с успехом. По сути core.async поможет только если вы строите приложение внутренний через обмен сообщениями, но оправдано ли это?
Если у кого-то есть вопросы сомнения по поводу Clojure в продакшене, можете задать вопросы кэтому комментарию, попытаюсь ответить.

А какую архитектуру / фреймворк вы используете для декомпозиции приложения на модули и поддержки состояния каждого модуля?

Мы раньше использовали Component: github.com/stuartsierra/component
Я видел так же, что люди используют Duct: github.com/duct-framework/duct

Otplike эту задачу успешно решает, одновременно с заходом на многопоточность.
А какую архитектуру / фреймворк вы используете для декомпозиции приложения на модули
Мы используем только стандартные средства, 1-н файл это один модуль (ns) стараемся чтобы он отвечал за обособленную часть логики.
… поддержки состояния каждого модуля?
По сути не так много мест где нужно состояние. Это некоторые инфраструктурные моменты, абстракции для работы БД(connection pool), конфиги, возможно ещё что-то и некоторые алгоритмы с бизнес логикой, которые требуют стэйта. У нас это отдельные модули.
У нас очень мало стейта(условно переменных) в приложении, можно пересчитать по пальцам, только там где без этого не обойтись. В остальном мы стремимся чтобы каждая функция была чистой(т.е. без side effect), это значительно упрощает приложения и что уменьшает кол-во багов. В основном когда приходит запрос извне мы подготавливаем все необходимые данные в коллекцию и передаем их вместе с данными из запроса далле, а не запрашиваем в в каждой функции отдельно(в цепочке вычислений). Там где нужен стейт мы используем обычный def или atom, второе соответственно позволяет выполняет изменения стейта в runtime.
Там где это сделать не возможно напрямую получаем нужный стэйт, проблем это не доставляет.
Вообще нужно стремиться минимизировать количество стейтов, это сильно упрощает код, что уменьшает кол-во багов.
Могли бы вы привести конкретную проблему которая заставила вас внедрять вышеописанные библиотеки? Нам достаточно описанного выше.
> стараемся чтобы он отвечал за обособленную часть логики
Опыт показывает, что уже для приложений среднего размера — это практически невозможно. В некоторый момент роста приложения появится зависимость между модулями.
Далее, как правило, появляются требования к серверу иметь стейты у модулей.
Далее, у стейтов появляются жизненные циклы. И надо не забыть, что модули уже зависят друг от друга.
И добавим к этому очевидное желание, чтобы сервер обрабатывал запросы параллельно.
Erlang и Otplike дают простое решения для этой гремучей смеси :).

Касаемо описанных вами проблем, по сути, согласен что связанность в приложении растет, количество стейтов так же. Только регулярный рефакторинг уменьшает эту проблему.
Но не понял как вы увязали параллельные запросы и модули. Модуль, в моем понимании это просто набор функций так или иначе связанных между собой, обособленных в файле или другой схожей сущности. Любую функцию или цепочку функций можно выполнить в отдельном потоке, вариантов реализации множество. ИМХО описанный выше подход вносит больше сложностей чем решает.

>Но не понял как вы увязали параллельные запросы и модули.
Стейт модуля — это часть модуля. Так или иначе, этот стейт нужно шарить между потоками в многопоточном приложении.
Атомы решают проблему одновременного доступа к стейту, но с учетом наличия жизненного цикла этого стейта и зависимостей между модуляли такой стейт становится сложно поддерживать.
Но я не все проблемы назвал, на самом деле :).
Далее, в приложении появляется необходимость иметь линки между стейтами и иметь событийную систему.
Через атомы (+ сore.async) это тоже можно решить видимо, но решения проще чем в Erlang/OTP я пока не видел :).

Давно хочу изучить clojure, но не знаю с чего начать, не подскажите?

По Сlojure сейчас есть много информации. В зависимости от вашего опыта вы можете выбрать лучший учебник на данном этапе:
— Введение в Clojure: alexott.net/ru/clojure/clojure-intro
— Introduction to Clojure: clojure-doc.org/articles/tutorials/introduction.html
— Clojure By Example: kimh.github.io/clojure-by-example/#
— Задачи по Clojure: www.4clojure.com
— Книги по Clojure: rutracker.org/forum/tracker.php?nm=clojure

Я бы вам советовал после вводной статьи по Clojure, прочитать книгу по Clojure. И одновременно с чтением книги пробовать писать код самостоятельно.

Опыт есть, на js пишу и стараюсь придерживаться фП. Спасибо большое за ссылки, буду разбираться

А ещё, не подскажите какой текстовый редактор или иде используете?

Для начала поиграться с синтаксисом, к нему нужно просто привыкнуть, чтобы он легко читался, это неделя-две. 4clojure.com отличный сайт.
Разобраться с основными структурами данных (если не знакомы), список и ассоциативный массив.
Разобраться с основными функциями для работы со структурами в Clojure assoc, conj.
Разобраться с основной функцией в FP — reduce, и её производными map, filter,…
Ну и прочитать хорошую книгу, я рекомендую следующую:
"Эмерик, Карпер, Гранд: Программирование в Clojure. Практика применения Lisp в мире Java"
Если как рус так и анг вариант.

Синтаксис своеобразный, сильная вложенность смущает. Только радует совместимость с джавой.

Вложенность точно такая же как влюбом другом языке. Можете сделать эксперемент, два варианта одного и тогоже алгоритма и подсчитать. На своем опыте могу утверждать синтаксис осваивается очень быстро и тогда начинаешь понимать что как это не странно(на первый взляд) программы на clojure читать проще.

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

Конкретно тот код — боевой, мы его используем в продакшене :).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.