https://github.com/clojure/brew-install
Как бы это странно не выглядело но вот в этом репозитории создаются бинари для clojure и clj тулов

Ну у них же прям инструкция есть официальная, как ставить clj. Там по инструкции надо запускать sh-скрипт, который скачает из инета что надо и раскидает куда надо.
Если инета нет, то корректируешь скрипт и в путь!

Или тебе принципиально надо из исходников собрать?

вот тут можно глянуть, тоже в условиях без интернета устанавливается https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/clojure/default.nix

@zarkone а emacs vim как собираются в никс ос?

вот, тоже в той же репе можно посмотреть https://github.com/NixOS/nixpkgs/blob/97ee9d357cdf97ad691d9e61c3986198fc85bca2/pkgs/applications/editors/emacs/generic.nix

Йоу. Ребят, а на сколько cljc "силен"? Я не разу не использовал, и не связывал кложурные фронт и бек. Я не понимаю: можно ли там например задефайнить async'овый channel и по нему обмениваться данными между фронтом и беком?

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

это просто куски кода которые ты можешь шарить в cljs и clj

ну я могу в нем дефнуть channel из clojure.core.async и по нему гнать данные между беком и фронтом? это реально? это секурно?

Это не работает. Канал не код.

Как? Если у тебя бэк в jvm, а фронт у клиента в браузере?

то есть анрил. я понял.

я думал, если либы одинаково называются, то можно clojure.core.async-то везде.

а если бы cljs.core.async, то нельзя) вот такая логика была.

Ну да, можно этот код использовать и на бэке, и на фронте. Код, а не результат его выполнения.

Можно везде. Но собранный код остаётся заперт в своей среде выполнения.

спасибо

Можно попробовать написать свою обертку. Я когда-то писал примитивный клиент для redis стримов с интерфейсом core.async. Думаю по аналогии можно сделать, все протоколы есть.

Да, есть важный момент: код на cljc не обязан полностью совпадать между реализациями. С помощью reader conditional можно указывать различия.
То есть, теоретически можно сделать какой-нибудь каналоподобный объект, который в clj будет торчать из сервера (лезть в пул вебсокетов, обращаться к API gateway, и т.п.) а в cljs будет к этому же серверу подключаться через вебсокет-клиент.

Но — это использование механизма несколько не по назначению. Он нужен чтобы реализовывать одинаковое поведение на разных платформах. Я б всё-таки рекомендовал разделить эти сущности на серверную и клиентскую. А то мало ли, потом захочется перенести обработку серверного канала в NodeJS+cljs, придётся эту конструкцию распиливать.

Т. е. опасно застревать в предположении, что clj = сервер, а cljs = клиент. А если транспортом для канала использовать вебсокет, то разделение на сервер и клиент необходимо. (А вот для, скажем, WebRTC – не уверен…)