Мой посыл был больше в том что из синхронного clojure.java.io (использующего FileInputStream/FileOutputStream под капотом ) не выйдет сделать ассинхронное просто обернув в go-блоки, поток будет блокироваться.
Но если задача просто для практики и было просто желание разобраться с core.async то думаю всё ок )

тоже на секунду, ы

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

докстринги странноваты, не по гайду

ну и по core.async из принципиального — внутри go блоков не надо делать блокирующие операции
в твоём случае здесь https://github.com/reflechant/json-diff/blob/editscript/src/json_diff/core.clj#L21 go нужно заменить на thread, который тоже возвращает канал

Дополнительная магия netty заключается в том что Norman Maurer смог реализовать его без такого колличества локов. Где-то был скрин с кодом nio, там на ~10 строк кода было 4 лока, 15 минут искал эту презентацию но не смог найти, последний раз видел её в 17 году по-моему, похоже её больше нет в сети.
На счет io в fs по-моему там есть что-то, гуглить по zero-copy file transfer, но самому мне не приходилось это использовать

а вообще для такого https://github.com/reflechant/json-diff/blob/editscript/src/json_diff/core.clj#L26-L29 есть https://clojuredocs.org/clojure.core.async/pipeline-blocking, который соберёт все запросы в ответы с указанным параллелизмом

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

Я сделал два канала чтобы не перепутать порядок файлов

Надо бы поподробнее посмотреть как core.async работает. В Go делать блокирующие операции, особенно IO, в горутинах - классика

да вроде на jvm работает, с ограниченным пулом потоков)

полагаю, это можно будет в jvm ток когда релизнется Project Loom

Clojure в этом отношении не Go
Thread pool небольшой, рассчитан на CPU-bound операции

насколько я знаю, там свой тред-пул

я, конечно, видел как Loom превращает обычные локи в "необычные" =)) но думаешь оно и io сделает асинхронным?

и принцип действия такой же, как на футурах. А вот manifold работает на netty, там другая асинхронность

он не про это, там про юзермодные легковесные треды, похожие на те что в Go

>manifold работает на netty
мб имелось ввиду aleph ?
Сам manifold наскок помню ничего такого не имеет

это понятно, лум в своем скоупе обычные локи превращает в неблокирующие и "паркует" этот поток. Но разве это спасет ио?

ну и касательно работ с жсонами и парсингом - все эти go потоки как вообще влияют на кеш миссы? самые быстрые парсеры там вовсю на SIMD пишутся, а тут данные по потокам будут разные. Вот Vector API когда в джаве выйдет...

manifold это подмножество стека aleph, да.

смотрел доклады по HFT - там вообще поток лепят на ядро