Хех, на c# у нас IoC контейнер иерархичный - сверху байндим инфраструктуру, а уже в дочерних контейнерах собираем зависимости под конкретный сервис

До какого-то уровня хватает тупых конструкторов. Ну жили же с for comprehension на 600 строк

И не треснули

Править там даже быстрее было чем думать какой там динамический конфиг правильно написать

Тосты конечно не так удобно но тоже терпимо

Но зато все предельно очевидно

Вопросам и странным ошибкам связанным с вайрингом прямо никогда не было

Треснули недавно, там есть ограничения в скалаке

На количество строк в форе?

На количество строчек с равно после одной стрелки

Что-то около 40 равно и все ломается

a <- b
c1 = d1
c2 = d2
...
c40 = d40

Интересно. То есть можно через x <- y.pure обойти по идее?

Да

Или попилить фор

а вот интересно, какие-то есть бенчмарки
что оборачивание в F[_] flatmap приносит (уносит) в плане производительности
и чего кто придерживается в этом смысле

вот есть логи и метрики
которые по сути очень минимальная манипуляция в памяти, никакого I/O существенного
то есть технически это да, эффект, и код выглядит красивее обёрнутый в эффект, и вроде бы всё будет заоптимизировано в один тред
но по сравнению с диском или network I/O, отделение такого (синхронного) эффекта совершенно вроде бы ни о чём?
логи это асинхронный аппендер всегда, а для метрик же используются всякие там LongAdder и прочие чудесные concurrent примитивы, неблокирующие счётчики

Спасибо за рекомендации и отличный пример с имплисит диай - учту в будущей работе 👍

IO вообще не про это

критичной разницы для 99,9% приложений не будет в производительности от того, заворачивают ли код в «F[_] flatmap»

ну тут как раз про high load и low latency