Насколько сложен GO?

Привет мужики!
Ну что, GO слишком сложный в освоении после питухона и шарпа?

0

Сообщение от Usaga DI нет. Либо руками контейнер формируй, либо катай сторонние решения и генерируй код.

https://github.com/gozix/di

Но я не фагат DI, за годы работы с ними так и не понял, чем они принципиально лучше простого вызова конструктора, который (вызов), гораздо проще дебажить, чем "магию" DI.

Добавлено через 2 минуты

Сообщение от imcavs™ я туда иду за ооп и убить свое свободное время)

За ООП и убить время идите в SmallTalk. Вот там ООП по самое немогу.

0

Сообщение от korvin_ https://github.com/gozix/di

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

Сообщение от korvin_ Но я не фагат DI, за годы работы с ними так и не понял, чем они принципиально лучше простого вызова конструктора, который (вызов), гораздо проще дебажить, чем "магию" DI.

"Выворотом" зависимостей - Inversion of Control. Тебе не надо знать, что сервису нужно в конструктор передать ибо этот сервис тебе уже готовым передаётся в твой конструктор. Код получается чище более устойчивый к изменениям. Конечно же не забесплатно, а за счёт того, что появляется контейнер, который отвечает за композицию графа зависимостей твоего приложения.

В простейших приложениях это, конечно же, может быть избыточным.

0

Сообщение от Usaga Но эти штуки для этого языка не родные.

Эти штуки ни для какого языка не родные, нигде DI не встроена в язык, везде идёт отдельной библиотекой, зачастую реализованной через чёрную магию рефлексии.

Сообщение от Usaga Я бы не стал их использовать.

Почему?

Сообщение от Usaga "Выворотом" зависимостей - Inversion of Control.

IoC к DI отношения не имеет, это паттерн проектирования.

Сообщение от Usaga Тебе не надо знать, что сервису нужно в конструктор передать ибо этот сервис тебе уже готовым передаётся в твой конструктор.

Мне в любом случае не нужно этого знать, потому что параметр конструктора -- интерфейс. При чём тут DI?

Сообщение от Usaga Код получается чище более устойчивый к изменениям.

Спорно.

Сообщение от Usaga Конечно же не забесплатно, а за счёт того, что появляется контейнер, который отвечает за композицию графа зависимостей твоего приложения.

И как только в нём происходит что-то не так, получаешь невменяемый стэктрейс, с кучей ненужной информации о внутреннем устройстве DI-фреймворка и дай бог хоть с каким-то информативным сообщением. Причём где-то в рантайме. В то время как вызовы конструктора явно написан в коде, видно где произошла ошибка, да и параметры проверяются статически.

Сообщение от Usaga который отвечает за композицию графа зависимостей твоего приложения.

Можно не строить сложные графы зависимостей, и всё сразу станет проще и даже DI не понадобится.

0

Подскажите, есть хорошие курсы по GO?

0

Whitecolor, A tour of Go

Добавлено через 1 минуту
Whitecolor, https://go.dev/doc/

0

Сообщение от korvin_ Почему?

В малом и среднем по размеру проекте, контейнер DI вполне можно собрать руками. А это меньше зависимостей от сторонних решений и меньше магии. Лично мне нравится, когда в коде всё явно сделано.

Сообщение от korvin_ IoC к DI отношения не имеет, это паттерн проектирования.

Эти две вещи идут рука об руку.

Сообщение от korvin_ Мне в любом случае не нужно этого знать, потому что параметр конструктора -- интерфейс. При чём тут DI?

Я не про интерфейсы. Ты хочешь создать сервис простым вызовом его конструктора. Этот конструктор может требовать другие сервисы. Значит сервис, в котором ты вызываешь конструктор другого сервиса, должен инициализировать и все его зависимости. Или получать их в свой конструктор. Так ведь? Inversion of Control это решает. А сам IoC удобно делать на базе DI.

Сообщение от korvin_ Спорно.

Ну, кому как, видимо.

Сообщение от korvin_ И как только в нём происходит что-то не так, получаешь невменяемый стэктрейс, с кучей ненужной информации о внутреннем устройстве DI-фреймворка и дай бог хоть с каким-то информативным сообщением. Причём где-то в рантайме. В то время как вызовы конструктора явно написан в коде, видно где произошла ошибка, да и параметры проверяются статически.

Ни разу не получал невменяемого стэктрэйса. Обычно простое "Не могу удовлетворить такую-то зависимость такого-то конструктора". Но да, такое ловишь в рантайме. Это одно из "не бесплатно". Но вполне лечится тестами.

Сообщение от korvin_ Можно не строить сложные графы зависимостей, и всё сразу станет проще и даже DI не понадобится.

Можно и без багов писать и максимально оптимально. Что уж мелочиться. Если пишем большое и сложное приложение, то и инфраструктура у него будет большая и сложная. И не всегда это от нас зависит. Сказали, что надо огромный монолит со всеми вытекающими - мы его и пишем.

0

Сообщение от Usaga Эти две вещи идут рука об руку.

Гм, нет, не идут. IoC можно делать без DI, а DI можно делать без IoC.

Ты путаешь принцип проектирования

In software engineering, inversion of control (IoC) is a design principle in which custom-written portions of a computer program receive the flow of control from an external source (e.g. a framework). The term "inversion" is historical: a software architecture with this design "inverts" control as compared to procedural programming. In procedural programming, a program's custom code calls reusable libraries to take care of generic tasks, but with inversion of control, it is the external code or framework that is in control and calls the custom code.

с джавизмом

Alternative meaning The phrase "inversion of control" has separately also come to be used in the community of Java programmers to refer specifically to the patterns of dependency injection (passing services to objects that need them) that occur with "IoC containers" in Java frameworks such as the Spring Framework.

Сообщение от Usaga Inversion of Control это решает.

IoC тут вообще не при чём.

Сообщение от Usaga Но вполне лечится тестами.

Какими тестами? В тестах моки и стабы, там другое наполение DI-контейнера.

Сообщение от Usaga Если пишем большое и сложное приложение, то и инфраструктура у него будет большая и сложная.

В большом и сложном приложении подключение инфраструктуры будет составлять считанные проценты сложности, и решается практически один раз. DI тут также решает несуществующую проблему, если это вообще можно назвать решением. Зато привносит дополнительный уровень абстракции, магии и неявности, требует дополнительных знаний, и (желательно) дополнительной поддержки со стороны IDE.

0

Сообщение от korvin_ Зато привносит дополнительный уровень абстракции, магии и неявности, требует дополнительных знаний

Ну да, есть такое. Уже сталкивались с этим на большом проекте.

0