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

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

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

Если рассматривать только с этой точки зрения - тофу ничем не лучше. Да - нету иерархии, но помнить что откуда все равно надо.

.race находится в Race, .fire в Fire, даже .timeout и тот в Timeout. Выглядит, будто это запомнить проще, чем иерархию

.race находится в Race, .fire в Fire, даже .timeout и тот в Timeout. Выглядит, будто это запомнить проще, чем иерархию

Точно так же, как нужно помнить сотни методов внутри конкретного эффекта, только там они ещё и в одном файле

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