Ок сейчас поменяю

Пиу Пиу!!
Работает!
Спасибо
А можешь объяснить почему в 2.12 не работало?

В 2.13 какие-то баги с вариансом фиксили, но про именно это из релиз ноутов не помню ничего

Ok
Спс 👍

cf.handle[Promise[A]]  в 2.12

в 2.12 вывод типов не может из-за страшного джавового подхода к call-site-variance вывести тайп-параметр

он понял, что функция возвращает Promise[A], но дальше, исходя из баунда, он должен подставить какой-то из надтипов Promise[A]

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

Привет. Начал потихоньку вкатываться в тф и напоролся на то, что http4s.BlazeClientBuilder требует целый ConcurrentEffect и из-за этого мне приходится тянуть его через половину проекта. Если я правильно понимаю, то ConcurrentEffect слишком много может и как следствие противоречит идее тф об атомарности тайпклассов. Вопрос: правильно ли я это понимаю и если да, то как этого избежать? Использовать какую-нибудь другую библиотеку для http? Или это абсолютно нормальное явление?

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

А в инициализации приложения допустимо требовать что угодно

возможно, вам поможет IOApp

посмотрите в документации, что это

С сервером всё так. Но вот клиент протекает, разве нет? Получается что часть бизнес логики будет всё равно тянуть ConcurrentEffect

IOApp же просто приносит имплицитные Timer и ContextShift, разве нет?

Мне интересно, можно ли как-то избежать такой сильной вещи как ConcurrentEffect

так же IO, из которого по context bound в нужных классах вы вытащите ConcurrentEffect

Проблемы в том, чтобы его получить у меня нет

возможно ошибаюсь, если да, то поправьте

Я наоборот пытаюсь его избежать где возможно

Клиент тоже можно создать наверху или что-то мешает?