Теперь есть типизация свойств в классе, параметров и возвращаемых значений методов. В php дженерики ждут не меньше, чем в go. Мне просто не понятно какие паттерны нельзя реализовать без дженериков

Теперь есть типизация свойств в классе, параметров и возвращаемых значений методов. В php дженерики ждут не меньше, чем в go. Мне просто не понятно какие паттерны нельзя реализовать без дженериков

я не думаю что native актуально сравнивать

Потому и спрашиваю про архитектуру приложения на go. Если свои решения или используются подходы из других языков.

> В go же аналог класса - это структура. Что мешает засунуть бизнес логику в структуру?
Ничего, кроме того, что ты не сможешь нормально написать достаточно универсальный код для обработки _разных_, но схожих структур. Например, у тебя есть список пользователей и список клиентов (наборы полей разные, но в чём-то схожи). Ты вряд ли сможешь обрабатывать их одинаково, без копипаста. С теми же дженериками смог бы. А в php ты можешь перечислить несколько типов через | или вообще обращаться к полям, не зная типа (что есть антипаттерн, но тем не менее).
Да, на это есть хаки, но я говорю о принципиальных вещах.

>  Какие паттерны, например? В php же тоже нет дженериков, но паттерны вполне себе реализуемы.
Читай https://habr.com/ru/company/jugru/blog/503868/, раздел про агрегаты.

> Что мешает использовать композицию вместо наследования?
Ни та, ни другая в одиночку всех проблем не решает.

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

Да все нормально с ООП в го. У меня есть большой монолитный проект как пример

Можно загнаться и в джава стиле писать

Интерфейсы не дадут

Интерфейсы не дадут

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