λ
Если все эти блейзы и фс2 стримы прибиты к конкаррент эффект, то все плохо
Size: a a a
2020 February 21
λ
Если все эти блейзы и фс2 стримы прибиты к конкаррент эффект, то все плохо
А они прибиты, эх
KS
Зачем аппликатив менять функтором ?
Бл, наоборот офк
λ
Kirill Shelopugin
Бл, наоборот офк
Да почему , можно и не наоборот, вдруг тебе не нужен пьюр)
KS
Ну я изначально говорил про расширение, но поплыл и порядок не тот указал, да
V
Иерархию не запомнил?
KS
Ладно, в общем, слушать надо Олега, как минимум то, что он в подкасте и докладах рассказывал, как максимум - то, чем он в понве делится
λ
Имея Unlift[F, G] и Effect[F] я получаю G[Effect[G]]
АК
Kirill Shelopugin
Конкретная монада сразу делает язык очень богатым - тут и сайд-эффекты и конкурентное исполнение, и всё в одном флаконе, ничем не ограничено
А разве это плохо с точки зрения написания клиентского приложения? Конкретная монада берет на себя всю работу с менеджментом эффектов и канкаренси в то время как я могу начать выстраивать свой дсл с помощью более высокоуровневых компонент, относящихся к логике конкретной задачи (в виде каких-нибуть зио модулей, ограничивая в конкретных местах контекст до необходимой подчасти а ля
ZIO[Database with DatabaseConfig, ...]), а не к подробностям возни с эффектамиV
А разве это плохо с точки зрения написания клиентского приложения? Конкретная монада берет на себя всю работу с менеджментом эффектов и канкаренси в то время как я могу начать выстраивать свой дсл с помощью более высокоуровневых компонент, относящихся к логике конкретной задачи (в виде каких-нибуть зио модулей, ограничивая в конкретных местах контекст до необходимой подчасти а ля
ZIO[Database with DatabaseConfig, ...]), а не к подробностям возни с эффектаминет. надо эффекты кодировать, а не приложение
λ
Что значит эффекты кодировать ?
NV
А разве это плохо с точки зрения написания клиентского приложения? Конкретная монада берет на себя всю работу с менеджментом эффектов и канкаренси в то время как я могу начать выстраивать свой дсл с помощью более высокоуровневых компонент, относящихся к логике конкретной задачи (в виде каких-нибуть зио модулей, ограничивая в конкретных местах контекст до необходимой подчасти а ля
ZIO[Database with DatabaseConfig, ...]), а не к подробностям возни с эффектамиZIO с чем угодно в параметре энва все ещё является конкретной монадой с бесконечно богатой экспрессивностью. То, что там в энве Database не означает, что она не может делать запросы по HTTP, например.V
да и пусть делает она эти http запросы
V
таков путь
KS
А разве это плохо с точки зрения написания клиентского приложения? Конкретная монада берет на себя всю работу с менеджментом эффектов и канкаренси в то время как я могу начать выстраивать свой дсл с помощью более высокоуровневых компонент, относящихся к логике конкретной задачи (в виде каких-нибуть зио модулей, ограничивая в конкретных местах контекст до необходимой подчасти а ля
ZIO[Database with DatabaseConfig, ...]), а не к подробностям возни с эффектамиВсё, что ты сказал - и про высокоуровневые компоненты, и про логику - в целом не противоречит ТФ. Описывая логику на тайпклассах, ты точно так же будешь делегировать работу конкретной монаде, только она будет определена где-то в конце программы, а ты будешь писать высокоуровневый код. Никто ведь не заставляет тебя писать race заново, верно? Ты так же будешь заботиться о бизнес-логике своего приложения
KS
ZIO с чем угодно в параметре энва все ещё является конкретной монадой с бесконечно богатой экспрессивностью. То, что там в энве Database не означает, что она не может делать запросы по HTTP, например.Ну, не бесконечно, а ограниченым самим зио, но да, посыл понятен, ограничений почти нет, в отличие от
AV
А почему дегусь против ТФ?
AV
А потому, що ТФ позволит легко перейти с зио на незио
AV
А почему мы юзаем тф с зио? А тому що так, в итоге, чище и удобнее. И вендорлока нет