Народ у меня такой вопрос Сложилось ощущение что на практике фп

скалы чаще предпочитают использовать дуби, даже меня самого дуби подкупила очень понятной
механикой работы. Но вот сегодня поковырял slick (начиная с версии 3)
И почему то не нашел ничего такого - что дуби дает чего нет в слике 3
Интреполяторы запросов есть не менее мощные в слике
можно юзать тот же tsql и он даже в компайлтайме проверяет что
sql-ка правильная, и маппинги проверяет (правда для этого требует
указать подключение к базе, к которой подрубается в компайл тайме)
дуби в этом случае дает check тесты.
и вот возникает вопрос почему на практике все таки дуби начали
охотнее завозить? или может все таки я не прав и слик все таки большинство юзает и предпочитает?

В дуби есть F[_], на этом, имхо, его преимущества заканчиваются, и начинается конкатенация строк.

я вот тоже думаю slick не любят потому что никто не хочет писать Task.deferFromFuture(db.run(...)) А может ли вследствии этого теряться производительность? Типа slick всегда в Future выводится а дуби более универсальный Или если обернуть Future в Таску - то все будет ок?

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

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

И на фп виртуальной машине :)

ну эт так себе аргумент

фп важно для программиста на уровне его взаимодействия с кодом, а не на уровне исполнения кода в ВМ или еще где

/toxic

слик вполне себе фп

согласен странная логика говорить раз не F[_] то не ФП типа не служил не мужик)

val setupFuture = db.run(setup) футуры исполняются сразу и следовательно не соблюдают ссылочную прозрачность как минимум. Значит не фп (не в понимании «фп ето программирование с ФВП»)

да хоть голое ИО/ЗИО/моникстаск, необязательно тф

Task.deferFromFuture(db.run(setup))

я это и имею в виду под «не задизайнено под фп-подход с сохранением СП» — надо каждый чих заворачивать в такое вот

Частично согласен, но db.run вызывать самому необязательно. Это всё в прослойке (тонкой).

программист, который не шарит в том как исполняется код в ВМ, иногда пишет очень стрёмный в плане перформанса код два топ примера из практики на втором месте .toMap который вызывали на mutable кеше, который мог быть большой 10-20 мб, несколько сотен раз в секунду чтобы получить immutable Map там дальше ни на что это вообще не влияло убрать .toMap - минус 60 процентов primary allocation, минус 30 процентов загрузки прода (а прод тогда был 72 ядра) а на первом месте - lazy val за каким-то хером в теле метода, которая тогда (2.11 по-моему скала ещё была) автоматически становилась глобальным тред локом для всех тредов, которые этот метод вызывают так что фп важно для программиста all the way down

ну там не совсем про это была реплика. Я говорил о том, что ФП дает бенефиты именно на этапе чтения/написания/поддержки кода и архитектуры, а смысла фанатично требовать тру-фпшность на всех уровнях нет. Поэтому например нормально внутри скаластд коллекций видеть вайлтру и прочие мутабельные штуки, и иметь вполне себе нетруфп-грязную-какещехотите жвм

а, ну по-моему достаточно посмотреть в имплементации скала коллекций с var и прочим

while truшки в локальных методах это вполне себе ФП если я не ошибаюсь называется локализованный эффект

да, я про это и говорю

есть ссылки где можно глянуть как это сделать? Я щас обычно фигачу везде deferFromFuture - не оч красиво

написать обертку для слика, нет?

Ты можешь вообще не писать нигде db.run. Например, можно репозитории автоматически переводить из DBIO в твой F. Например, если есть какой-то Repo trait UserRepo[F[_]] { def findUserByEmail(email: Email): F[Option[User]] } class UserRepoImpl(...) extends UserRepo[DBIO] { // ... } То, имея ~> выше, можно с помощью cats-tagless превратить твой UserRepo[DBIO] в UserRepo[F]. implicit val functorKUserRepo: FunctorK[UserRepo] = Derive.functorK[UserRepo] userRepoImpl.mapK(transact) И транзакции будут выполнять автоматически при покидании DB слоя.

Осталось только понять причём тут знание виртуальной машины

вм как среды исполнения фп кода - в широком смысле, везде где это критично

если говорить про тайплевел/зио/моникс, то для «фп кода» там используется не сама жвм, а отдельный рантайм поверх нее (собственно ИО-ЗИО-Таск)

ну и описанные «беды» были и правда не с ВМ, а с деталями реализации стдлибы или языка