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

Чем-то похожая история ZIO / scalaz

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

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

Это подразумевало бы, что все zero dependency либы имеют тенденцию быть популярными

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

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

Я не забываю, потому что подавляющая часть исследований и инструментов конкуретности не учиывает всё, что вы перечислили.
Никаких дисков, видеокарт и процессоров в сепарационных моделях конкаренси, которыми Трунов вон занимается, нет

В реальности выполнение может идти не на классическом СPU, и вообще может быть не про CPU, а про какое-то производство на заводе или биологические\химические процессы.

В другой реальности в конкаренси активно задействованы люди, произвоящие события на своих клиентах, всё это хоть и сопутствует каким-то реальным кейсам, отношения к конкаренси как к предметной области не имеет

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

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

Исходя из этого же текста - все правильно трактуют, что в конкаренси имеет быть общий ресурс. Но, чтобы точнее понять этот абзац, надо разделять логическую (созданную программистом) конкаренси/параллельность и физическую (вынужденную). Это такая же байда как и с пуш-пулл стримами. Если выбрать другой срез, то могут и поменяться термины.

И в этой связи в том же абзаце есть одна неточность. Логическая параллельность может иметь место в рамках одного физического ядра процессора. Если вычисления проходят логически независимо друг от друга, то с точки зрения исполнения не важно, что на ядре они конкурируют и идут как A->B->A->B с переключением стека, они все равно останутся параллельными в рамках логики. И ниже потом все правильно писали, что фактически конкаренси - есть подвид параллельности, когда появляется борьба за ресурс. Но все это опять таки может иметь смысл только до тех пор, пока мы не смешиваем логическую и физическую составляющие - иначе будет бардак в голове и терминологии

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

А ты внедрил?

Одна из моделей конкаренси - акторная.
Какой общий ресурс у акторной модели?

threadpool

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

Врешь ты все. Акторы - это параллелизм, а не конкарренси

никакого тредпула у них нет общенго

Вначале не внедрит, потом в чате врёт