Kotlin плетётся где-то в хвосте, писать на нём вовсе не так приятно, но при этом он куда более популярен. Загадка.
Каком хвосте? Wanna be functional language? Ну так у Kotlin в приоритете как раз таки фичи которые позволяют ему быть практичным, безопасным и популярным, а не фп-чистеньким. Видимо вот тут кроется разгадка
В скале куда мощнее и интереснее. Тут это просто параметр который берется из скоупа вызова (класс-левел, топ-левел в резолве не участвует, только то что в функции самой) и имплиситно передается. В общем до скаловских имплиситов тут очень далеко
Это вообще не замена DI, разве что если передавать что-то типо ApplicationContext и оттуда сервисы доставать в каждом методе. Почему? Да потому что context "окрашивает" функцию, теперь чтобы вызвать outputMessage нужно коллеру знать про UserService и положить его в контекст. Т.е это не DI
Что же это?
Классная штука для DSL - тут прямо очень много возможностей открывается
Для меня основной юзкейс это компайл-тайм-тред-сейф замена ThreadLocal
Еще вероятно кейсы которые мне не доводилось использовать
Замена ThreadLocal самая приятная, у меня контроллеры завернуты в context(_: UserContext) и через HandlerMethodArgumentResolverUserContext построенный из запроса передается в контроллер, дальше все функции по стеку определяют что им нужен context(_: UserContext) и получаем секьюрити без багов, даже с учетом что мы используем и корутины, и реактор и акторы и у нас библиотека которая используется и со спрингом и без спринга. В общем супер производительный, пуленепробиваемый способ делать секьюрити и транзакции в нашем случае.
Я сейчас развиваю контексты в сторону использования их со всякими @Cached/@Retry, чтобы везде отказаться от неявной передачи/хранения стейта, на явные контексты.
Так что фича очень удобная для написания быстрого и безопасного кода. Особенно актуально в эру ИИ
А добавьте свой DI сюда https://github.com/Heapy/di-comparison Будет куда более информативнее чем звездочки расставленные автором в вакууме. Например в бенчмарке выше получилось что спринг бут это 9мб а у вас 30, хз как вы считаете
Проблема не в том что в них тяжело разобраться, проблема в том что при такой глубине стека многие оптимизации JVM перестают работать и условно можно получить сервис который обработает в два раза меньше запросов да еще и с большой latency
Ну это вы еще spring boot не видили, там любой эксепшен в hello-world это 100 уровней вложенности. Такая цена вот гибкости, не всем походит, мы перестали например много где srping-boot использовать из-за этого
Какова вероятность, что, обнаружив какой-то баг, я смогу попробовать его исправить и отправить PR, а не ждать и надеяться, что мейнтейнеры когда-нибудь сделают это сами? Около нулевая. Именно поэтому в репозитории React'а висят баги от 2014 года — не потому, что их кто-то другой не может исправить, а потому что это фиктивный open-source. Это системная непрозрачность, и она прослеживается во всём, что делает React.
Коротко - чтоб Вы спросили :) А если серьёзно, какая разница какой у них код-стайл? Да потребовалась целая директория, для такого маленького пакета, ну и что? А ничего. Работает этот код в отдельной директории или нет - всё равно, главное чтобы он решал свою задачу. Да и, есть вероятность, что кэш импортов здесь как-то участвует (мб что-то оптимизирует), но не уверен.
Есть ощущение что это как-то связано с react-native и cерверными компонентами
Зачем сохранять слоп, если можно прямо слопу отдать на ревью. А еще лучше пусть сначала напишет один, а потом 10 слопов ревьювят
Где тут котлин? Где тут джава?
Поливаха, будь человеком, пофикси таги
Дефолтные хабы и тэги в каждом вашем посте знатно надоели, давай-те если пост вообще не про то не будем их включать, ок?
Да, просто декларативная передача параметра, ничего прям фундаментально сложного нет, но при этом очень красиво получается
Каком хвосте? Wanna be functional language? Ну так у Kotlin в приоритете как раз таки фичи которые позволяют ему быть практичным, безопасным и популярным, а не фп-чистеньким. Видимо вот тут кроется разгадка
В скале куда мощнее и интереснее. Тут это просто параметр который берется из скоупа вызова (класс-левел, топ-левел в резолве не участвует, только то что в функции самой) и имплиситно передается. В общем до скаловских имплиситов тут очень далеко
Это вообще не замена DI, разве что если передавать что-то типо
ApplicationContextи оттуда сервисы доставать в каждом методе. Почему? Да потому что context "окрашивает" функцию, теперь чтобы вызватьoutputMessageнужно коллеру знать проUserServiceи положить его в контекст. Т.е это не DIЧто же это?
Классная штука для DSL - тут прямо очень много возможностей открывается
Для меня основной юзкейс это компайл-тайм-тред-сейф замена ThreadLocal
Еще вероятно кейсы которые мне не доводилось использовать
Замена
ThreadLocalсамая приятная, у меня контроллеры завернуты вcontext(_: UserContext)и черезHandlerMethodArgumentResolverUserContextпостроенный из запроса передается в контроллер, дальше все функции по стеку определяют что им нуженcontext(_: UserContext)и получаем секьюрити без багов, даже с учетом что мы используем и корутины, и реактор и акторы и у нас библиотека которая используется и со спрингом и без спринга. В общем супер производительный, пуленепробиваемый способ делать секьюрити и транзакции в нашем случае.Я сейчас развиваю контексты в сторону использования их со всякими @Cached/@Retry, чтобы везде отказаться от неявной передачи/хранения стейта, на явные контексты.
Так что фича очень удобная для написания быстрого и безопасного кода. Особенно актуально в эру ИИ
Указал лицензию
Добавил, результаты хорошие, но в целом не принципиально отличаются от аналогов типо koin, kodein
А добавьте свой DI сюда https://github.com/Heapy/di-comparison
Будет куда более информативнее чем звездочки расставленные автором в вакууме.
Например в бенчмарке выше получилось что спринг бут это 9мб а у вас 30, хз как вы считаете
https://manageripgeorgia.atlassian.net/wiki/spaces/FAQ/pages/1199276038/2025+2026
Проблема не в том что в них тяжело разобраться, проблема в том что при такой глубине стека многие оптимизации JVM перестают работать и условно можно получить сервис который обработает в два раза меньше запросов да еще и с большой latency
Ну это вы еще spring boot не видили, там любой эксепшен в hello-world это 100 уровней вложенности. Такая цена вот гибкости, не всем походит, мы перестали например много где srping-boot использовать из-за этого
Ну да, я не вчитывался. Если все-таки посмотреть на сорцы, то аж на третьей страницы после всяких devtools и tests есть такой результат, который как раз похож на реализацию https://github.com/facebook/react/blob/eb2f784e752ba690f032db4c3d87daac77a5a2aa/packages/react-reconciler/src/ReactFiberHooks.js#L3941
Я так понимаю кина не будет?
А в линукс ядре висят баги с 2012 и то потому что судя по всему поиск дальше не идет https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&limit=0&order=changeddate%2Cpriority%2Cbug_severity&query_format=advanced
Третья ссылка в результах код клиента https://github.com/facebook/react/blob/eb2f784e752ba690f032db4c3d87daac77a5a2aa/packages/use-sync-external-store/src/useSyncExternalStoreShimClient.js#L25
Четвертая код сервера https://github.com/facebook/react/blob/eb2f784e752ba690f032db4c3d87daac77a5a2aa/packages/use-sync-external-store/src/useSyncExternalStoreShimServer.js#L10
Приведите список аналогов RSC
Автор не знает что существует поиск, я нашел сорцы useSyncExternalStore за минуту прямо не выходя из браузера: https://github.com/search?q=repo%3Afacebook%2Freact useSyncExternalStore&type=code
Еще автор не знает про то, что реакт это не только замена jquery, но очень хитрый рантайм, у которого нет аналогов https://overreacted.io/progressive-json/
Есть ощущение что это как-то связано с react-native и cерверными компонентами
DI не решает проблемы транзакций например либо создает проблемы производительности/оверхед в случае не singleton бинов
Согласен, не видел пока хорошего примера DI на контекстах