ничего не понял что это такое и зачем это нужно. Если вы хотите сказать что петон лучше чем Го подходит для целей десктопа, то я не согласен с вами категорически. Разве что для хелувордных задач, которые хоть на баше решай.

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

не полезем же мы в эту таблицу

Напиши, как Go будет выглядеть конструкция "зову виртуальный метод А, одна из его реализаций зовет виртуальный Б, одна из его реализаций зовет виртуальный Ц" В питоне: class X: def a(self): self.b() class Y(X): def b(self): self.c() class Z(Y): def c(self): pass Z()a() Как это будет в Go? Сорри, но .net forms - тонкая прослойка над winapi - не зачет. Java почти всегда все сама рисует - т.е. контролы самой и рисовать приходится - не зачет. nodejs - обертки на существующими фремворками - не зачет.

я вот сейччас пишу десктопный клиент для прода на go и это пиздец Мне впервые за полтора месяца постоянно нужны дженерики, динамический каст просто убивает

а в go - нет, нетути

а в go - нет, нетути

а зачем динамический каст именно в десктопе на Го? и дженерики

В C++ вызов метода родителя - тоже статический вызов, и не имеет отношения к виртуальной таблице.

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

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

Любом? Я уже написал на питоне выше.

Динамический каст нуже чтобы протаскивать зависимости в контексте в хендлеры по сравнению с вебом на десктопном клиенте в, скажем так, хэндлер приходится (хотя и не хочется) протаскивать очень большое количество разных зависимостей, результат довольно уродлив так же очень большое количество однотипных операций над коллекциями объектов, которые не сводятся к единым интерфейсам, приходится писать кучу имплементаций скажем множеств

Любом? Я уже написал на питоне выше.

В go это невозможно так как нет наследования ваш кэп )

это не наследование

В go это невозможно так как нет наследования ваш кэп )

у меня тоже много зависимостей. Не вижу как это решается темплейтами C++. Наоборот в Го удобно делать для локализации зависимостей маленькие пакеты с узкими интерфейсами. А множество - это же map[A]bool, нет?

В go это невозможно так как нет наследования ваш кэп )

ага либо пистаь руками либо писать генератор для них

причём тут узкие интерфейсы? Как узкие интерфесы помогают избежать работы с пустыми интерфейсами в контекстах? множество — это map[type]struct{} + методы join-ов и получения слайса и так штук десять писать

короче заниматься всякой мутью и бодаться с языком вместо решения бизнес задач

Назови отличие.

а на каком языке надо писать?

Чтобы не было не доразумений: я люблю Go. Но любить - это принимать недостатки.

это такой архитектурный ход, когда указываются только те методы, которые использует пакет. Чтобы связность между пакетами свести к минимуму Про пустой контекст не понял - почему он возникает в десктопных аппах с множетвом зависимостей и как это решается темплейтами в С++?

отличие только одно - в разграничении области видимости.

а на каком языке надо писать?

он возникает потому что единственный способ прокидывать зависимости вл фреймворке без глобальных переменных во множество хендлеров — это использовать какое-то обобщённое хранилище зависимостей и состояния, это либо context.Context, либо какая-нибудь map[string]interface{} Попробуйте написать развесистое приложение с большим количеством команд и подкоманд — и гарантированно окажетесь в ситуации, когда у вас есть 100500 геттеров и сеттеров для каждой зависимости в контексте. Дженерики — это не темплейты. Темплейты — это не дженерики. Мир станет лучше, когда люди запомнят это )

как ни странно я для себя понял что для десктопа бооьшие приложения я предпочёл бы писать на джабке всё равно когда у тебя появляются касты из interface{} и методы типа Equals методы для ошибок (потому что на обработку ошибок завязано много логики) го превращается в такую вот громоздкую джабку только с большим количеством проверок в рантайме

он возникает потому что единственный способ прокидывать зависимости вл фреймворке без глобальных переменных во множество хендлеров — это использовать какое-то обобщённое хранилище зависимостей и состояния, это либо context.Context, либо какая-нибудь map[string]interface{} Попробуйте написать развесистое приложение с большим количеством команд и подкоманд — и гарантированно окажетесь в ситуации, когда у вас есть 100500 геттеров и сеттеров для каждой зависимости в контексте. Дженерики — это не темплейты. Темплейты — это не дженерики. Мир станет лучше, когда люди запомнят это )

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

я лишь о том, что в общем случае утверждение "го намного производительнее джавы" - неверно

я лишь о том, что в общем случае утверждение "го намного производительнее джавы" - неверно

возможно даже для десктопа хуже, тк там практически нету io-bound задач, в которых го особенно хорош

jar-hell и xml весьма опосредованно относятся к ЯП

а кому в 18-м году нужен ЯП сам по себе без инфраструктуры и экосистемы? надо всё в комплексе же оценивать

Golang говно

Golang говно