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

а я сижу тут, как дурак... надо допилить новую фичу - хочу успеть за сёня :)

ты это я

ZIO выглядит как-то попроще, чем cats\scalaz и прочие tf. но в абсолютном выражении все равно мотивация непонятна

у меня просто на руках проект состоящий на 90% из каких-то лейзи имплиситов и тайп холов который читает из очереди, чот калькулирует, кладет в дб

какой пиздец. Выглядит еще хуже чем использование from x in someAsync select x нотации для тасков в сишарпе

Так он, если что, как раз за полную ссылочную прозрачность. Если говорить, про практическую мотивацию всего этого, то ZIO/IO/Monix/twitter.Future - это приличные реализации холодных тасков. Каждая со своими фишками и трейдоффами. Плюс ZIO в качестве холодного таска в том, что он полегче с аллокациями при обычных паттернах использования и корректная работа с отменой тасок и ресурсами. Теперь про контроль/абстракцию от эффектов: все эти таски удовлетворяют общему набору тайпклассов из cats.effect и авторам библиотек очень удобно писать абстрагировавшись от конкретной реализации через F[_] и эти самые тайпклассы, чтобы потребитель библиотеки мог использовать любую интересующую его реализацию.

в смысле, если все, как написано выше, то я понимаю, почему скале пичот от kotlin

Те же холодные таски

Каждая конкретная реализация - да. (Только опять-таки, там у каждой свои фишки есть) Суть скаловского tf'а в том, что ты можешь от конкретной реализации таска абстрагироваться

С помощью еще одной абстракции?

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

Нет, не совсем. Это если с совсем практической стороны. Если копать глубже, то tf - как паттерн это отличное решение expression проблем и средство для eDSL. И неплохая штука с точки зрения parametricity, т.к. очень сильно сужает возможные интерфейсы. А, то как обычно в скале tf используют - это обычно называют MTL-style в хаскеле.

Каждая конкретная реализация - да. (Только опять-таки, там у каждой свои фишки есть) Суть скаловского tf'а в том, что ты можешь от конкретной реализации таска абстрагироваться

вроде же давно все поняли, что eDSL - это путь в никуда. особенно dsl для таких крайне туманных понятий, как “эффекты”

зачем нам абстрагироваться от штатной фишки языка\стдлибы\сторонней либы?

Ну это дико спорно. Почти любая программа - это eDSL некого рода.

следуя этому тезису, мне предлагается встроить eDSL в eDSL?

Хотя бы чтобы не протекать инфраструктурными и техническими деталям по всеми проекту

Тут скорее опять-таки, насколько широко эту идею понимать. Вот реализации CE - это же самые настоящие eDSL

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

Ну проблема в том, что в традиционном ОО сложно типобезопасно и без кучи адаптеров абстрагироваться от типа контейнера/таска.

откуда берется уверенность, что “протекание” деталями реализации проекта в проекте - это плохо?

Так часто получается одновременно слишком много движущихся частей в рамках каких-то участков кода или проекта в целом. А человеку удобнее работать с сильно ограниченным числом каких-то возможностей.

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

В отдельных, хорошо разделенных слоях

“у нас много абстракций, поэтому давайте мы введем еще одну абстракцию"

Это даёт плюс, когда абстракция выходит ограниченее того, что она прячет.

мало того, это настолько сложная абстракция, что ее не каждая команда может корректно реализовать

Ну в tf, какой-нибудь ZIO/IO/Task с доброй сотней методов прячется за мелкими (по количеству методов) Functor/Monad/Applicative

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

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

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

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

дохера фреймворков, делающих это без аппликатива

Так поинт в чем? Обазываться фреймворками вместо использования фич языка?

а у нас есть язык, в котором аппликатив - это фича?

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

Я хз, я на сишарпе )

Так и в чом с ним проблема?

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

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

Проблема в том, что там где есть возможность абстрагироваться от конкретного аппликатива, кучу комбинаторов к нему ты получаешь забесплатно из стандартной библиотеки.

в каком языке аппликатив в стдлибе?

в скале?