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

😍

называется pypy

да https://github.com/php/php-src

я тоже с пыхи убежал, потерпи месяц-другой потом похуй будет

да и щас похуй, но не похуй

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

я DI сам написал

иок? или сервис-локатор просто?

singleton обычный

А че убежал раз она такая сладкая (сахара то много)

профитней

я вот не убежал, я и то, и другое и чутка жс даже

DI не нужен. Насчёт интерфейсов - объявляй нужные интерфейсы прямо в тестах и гоняй тесты поверх них

DI и IoC Container – разные вещи. DI как раз таки нужен для снижения coupling, нормального тестирования. Без него чистую архитектуру нормально не выстроить

пример кода?

как концепция - очень нужен как спецсофт - в общем-то, обходимся. собственно, годный DI на go не написать никак, и генерики тут не сильно помогут, так что обходимся вынужденно

uber-fx....

кажется, что подход как с CA, разделение инциализации приложения на композиты - выглядит очень и очень.

ну оно кривое же и косое, и пользу от него можно извлечь в очень ограниченном наборе случаев

Не совсем понимаю, про что ты именно говоришь ?

задавай вопаросы

Да и вообще di — это не про di-фреймворк — он лишь нужен чтобы облегчить сборку всех компонентов и не делать раздутый мэин. Без него вполне можно сделать хорошую инверсию

А wire?

не пробовал 🙁

Говно

Почему говно, если он генерит ровно то, что многие пишут руками в main.go? Т.е. если генерится, то говно, а если написал руками инициализацию, то нет?

Ну смотри, это +1 депенденси. И оно иногда кидает такие ошибки, которые ты не сможешь понять. Кейс(вайр): у меня есть ифейс, его имплементирует тип со ссылочными ресиверами. Когда ты запустишь генерацию, вайр поругается что тип не имплементирует ифейс, и ты офигеешь потому что оно имплементирует. Оно не будет говорить что у типа поинтер ресиверы.

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

При использовании DI код, из "раздутого" модуля main размазывается между следующими частями: - конфигурация DI - код самого DI-фреймворка - код модулей, связываемых DI Вам не кажется, что "раздутый" main намного проще понять, дебажить, рефакторить и расширять, чем пытаться понять и, тем более, дебажить, как и в каком порядке между собой взаимодействует код внутри di фреймворка с конфигурацией di и кодом ваших модулей?

Что значит конфигурация di; код самого di-фреймворка и код модулей, связываемых DI. У fx активных функций 5-6 штук и обчёлся, да и так таковой конфигурации нет. Его задача при старте приложения раскидать все инстансы по графу и вс.

"раскидать все инсансы по графу" - это же намного проще понять, настроить и дебажить, чем вручную написанный явный код. Ведь так?