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

Это не означает, что это нужно использовать повсеместно. Каждому инструменту - своё применение. И рефлексии следует избегать настолько, насколько это вообще возможно.

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

на этом прототипе будет скобок зашкаливающее количество

Все стоит использовать когда нужно. Не только рефлексию.
Если говорить за производительность, то можно все писать на cgo и аллоцировать память, в которую не ходит gc, все будет работать очень быстро.
Нужно ли писать весь код на с? Нет.
Везде баланс нужен.

Все стоит использовать когда нужно. Не только рефлексию.
Если говорить за производительность, то можно все писать на cgo и аллоцировать память, в которую не ходит gc, все будет работать очень быстро.
Нужно ли писать весь код на с? Нет.
Везде баланс нужен.

Все стоит использовать когда нужно. Не только рефлексию.
Если говорить за производительность, то можно все писать на cgo и аллоцировать память, в которую не ходит gc, все будет работать очень быстро.
Нужно ли писать весь код на с? Нет.
Везде баланс нужен.

На си можно и на котлине писать

для котлина нужна жвм или экспериментальная грааль

Вызовы си го вроде считаются системными, не будет ли из-за этого все тормозить на вызовах, но работать быстро внутри?

llvm

В зиг?

В пхп нет строгой типизации, поэтому и дженерики не нужны.

> Богатая доменная модель подразумевает, что бизнес-логика заключена в классах и их поведении/отношениях. Анемичная подразумевает, что бизнес-логика пишется процедурно (в сервисах или даже plain-функциях), а классы - это просто структуры для передачи данных

В go же аналог класса - это структура. Что мешает засунуть бизнес логику в структуру?

> Соответственно, в го, без дженериков и прочего мета-программирования очень сложно делать всякие хитрые паттерны, основанные на отношениях объектов.

Каккие паттерны, например? В php же тоже нет дженериков, но паттерны вполне себе реализуемы.

> А в php ты изи можешь описать, скажем, десять классов подтипа "заказ" и написать универсальную функцию, которая единообразно обрабатывает любой  класс из вышеперечисленных.

Что мешает использовать композицию вместо наследования? Я где-то читал (возможно ошибаюсь) что создатели go и решили не включать в язык наследование потому, что можно использовать композицию

в зиге ручное выделение памяти