+

А если у вас в той же программе не только IO? Например ConnectionIO ещё? Весь общий код два раза писать?

Я с автором не согласен по ряду причин.
Первое: используя конкретные реализации IO-монады, мы сразу резко расширяем наш "лексикон", т.е. количество доступных действий в коде. Это усложняет как написание кода (листать сорцы либо скаладоки IO/Monix/ZIO в поисках нужной функции это занятие медитативное), так и ревью (чем больше действий разрешено, тем больше когнитивная нагрузка и тем сложнее анализировать код, написанный другим человеком).
Второе: TF - это всё-таки не про один Sync[F] и не про сайд-эффекты, как может показаться из прочтения, автор делает упор только на них. Если в бизнес-коде приложения нет сайд-эффектов, написанных юзером, то Sync там может и не быть. TF же про выражение подъязыка, на элементах которого строятся программы. Лексикон этого подъязыка расширяется по необходимости, когда нужно добавить какую-то новую функциональность.
Третье: касательно даже Sync - да, его, как и его наследников, еще более сильных, по возможности должно быть в бизнес-коде как можно меньше, чем его меньше - тем меньше вероятность выстрелить в ногу. Использования сильных котоэффектовых тайпклассов желательно изолировать как можно тщательнее, оставим сам бизнес-код чистым.
В чем я с автором согласен: использовать TF с целью "а вдруг перейдем на другой эффект" - это нерационально, существующие популярные решения и так предлагают более-менее схожий api, что касается контроля эффектов.
Проблема, которую автор описывает, по большей части вызвана плохой иерархией тайпклассов в котоэффектах, но никак не тем, что TF плохо подходит для написания бизнес-кода. Многие считают, и я с ними согласен, что для вэлью-кода важно ограничить домен, в котором оперирует писатель кода, будь то фримонады как инишл представление или тф как финальное, любой вариант неплох

А ты прочитал гист?) Автор там в целом соглашается с тем что библиотечные функции, так же, как и общую, можно и нужно выносить и абстрагировать

Ну вот ты говоришь что приходится листать api IO чтобы найти нужный метод. Но с котоэффектами это возводится в квадрат, тебе мало того что надо знать, что функция есть, тебе ещё надо знать где она есть

👍 спасибо

Поэтому для более удобного ТФ есть тофу. Основа в виде cats хороша, там базовые тайпклассы, где листать особо ничего не нужно - все знают откуда flatMap. С эффектами сложнее, да, и поэтому я предлагаю тофу как решение для тф-кода

Мне кажется это очень быстро запоминается. Всё-таки этих тайпкласов кот наплакал 😂 Буквально за неделю. Помогает поиск по коду cats effect.

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

В первый раз никто не полезет коты юзать а тофу и подавно нету необходимости, а тот кто полезет имеет представление о чем речь как минимум читая доку

Да, я согласен с тем, что иерархия не такая сложная, и достаточно запомнить пару паттернов, навроде - если что-то надо запустить посреди поля то это, скорее всего, что-то с effect, если нужно паралельное исполнение - что-то с concurrent, но всё равно лишняя нагрузка, иерархию эту помнить

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

что там в доке, почему все так, вряд ли все знают и понимают

Ну вот в плане хелперов да я встречал такое что тянут

Эх блогпост что-ли написать

и это коты, тофу скорее надо сравнивать с котоэффектами, которые уже сознательно тянут (ну либо фанаты всяких фс2 врапперов для очередей)

Лично моё, возможно ошибочное, впечатление - программирование в стандартных (минимальных?) абстракциях очень сильно помогает упрощать код.

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

Но вообще ничего ужасного не вижу в том что кто-то предпочитает не абстрагироваться. Ну значит приложение маленькое и и так работает.

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

я могу тока отложить кирпичики от такого

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

Так говоришь будто на тф сам пишешь