Вот это наброс на вентилятор https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md

Чем вам включение типов не наследование

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

Ну, по-моему это наследования никак не касается

по-моему это одна из ключевых разниц между наследованием и встраиванием

Вот это наброс на вентилятор https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md

Я же правильно понимаю, предок должен быть осведомлён о потомке, и мочь вызывать его методы и всякое такое?

что-то навскидку лучше не нагуглилось, а сам не могу что-то адекватное придумать)

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

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

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

Какие аргументы хотите? Технические? Мне нравится предложение, действительно сократит кол-во копипасты. Хотя конечно надо понимать, чтоб до релиза оно может доехать в совсем другом виде. Но пока выглядит достойно, читаемо. Гораздо интереснее наблюдать какие бурления ваших шоколадов начнутся в сообществе. Ну а во что макать - думаю, сами разбиретесь;)))

вообще - пока даже задачу, в которой генерики были бы уместны (кроме коллекций) никто не сформулировал

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

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

пока они не нужны вообще — то конечно не нужны и в генерализованном типе вы их не видите, потому что на Go их никто не пишет почти, кроме некоторых фанатиков а как только нужны какие-нибудь графы направленные, где у тебя ноды могут быть ещё и разного типа, так у тебя Go превращается в мешанину кастов, тайп свитчей и пустых интерфейсов да и просто можно поглядеть на такие прекрасные конструкции как map[string]interface{} на каждом месте, где надо работать с динамическими данными, и которые взрывается потому что где-то в глубине вместо int кто-то положил json.Number и ты не поймёшь в чём дело пока не пересмотришь большую часть кода приложения глазами а писать самому под конкретный тип бывает нетривиальной задачей в случае некоторых алгоритмов я понимаю что для CRUD это не нужно, но невозможность писать такие вещи просто и приятно как раз и ограничивает Go в CRUD

пока они не нужны вообще — то конечно не нужны и в генерализованном типе вы их не видите, потому что на Go их никто не пишет почти, кроме некоторых фанатиков а как только нужны какие-нибудь графы направленные, где у тебя ноды могут быть ещё и разного типа, так у тебя Go превращается в мешанину кастов, тайп свитчей и пустых интерфейсов да и просто можно поглядеть на такие прекрасные конструкции как map[string]interface{} на каждом месте, где надо работать с динамическими данными, и которые взрывается потому что где-то в глубине вместо int кто-то положил json.Number и ты не поймёшь в чём дело пока не пересмотришь большую часть кода приложения глазами а писать самому под конкретный тип бывает нетривиальной задачей в случае некоторых алгоритмов я понимаю что для CRUD это не нужно, но невозможность писать такие вещи просто и приятно как раз и ограничивает Go в CRUD

https://m.youtube.com/watch?v=6wIP3rO6On8#

ну а вообще, то конечно дженерики и типы суммы не нужны, так же как и непустые интерфейсы нет ничего такого, чего нельзя было бы сделать с помощью interface{}, switch и рефлексии вопрос в том, сколько убитых нервов и часов работы будет стоить вам отладка всего этого недо-питона

не будет ли лекарство горше болезни?

если это будет сделано в стиле го – минимализм и единство стиля, то думаю нет в любом случае, если этого не делать, то го просто помрёт

а если нашим уважаемым коллегам дать в руки генерики - они же понапишут такой херни, что будет у нас и вправду новый php

а пока они пишут свои касты интерфейсов к указателям без тестов

по большей части все же нет.

по большей части этот код все же генерируется

он должен генерироваться это подход здорового человека с большим количеством времени

пока они не нужны вообще — то конечно не нужны и в генерализованном типе вы их не видите, потому что на Go их никто не пишет почти, кроме некоторых фанатиков а как только нужны какие-нибудь графы направленные, где у тебя ноды могут быть ещё и разного типа, так у тебя Go превращается в мешанину кастов, тайп свитчей и пустых интерфейсов да и просто можно поглядеть на такие прекрасные конструкции как map[string]interface{} на каждом месте, где надо работать с динамическими данными, и которые взрывается потому что где-то в глубине вместо int кто-то положил json.Number и ты не поймёшь в чём дело пока не пересмотришь большую часть кода приложения глазами а писать самому под конкретный тип бывает нетривиальной задачей в случае некоторых алгоритмов я понимаю что для CRUD это не нужно, но невозможность писать такие вещи просто и приятно как раз и ограничивает Go в CRUD

вот как раз таки там где interface{} имеет место быть надо писать тесты, проверяющие корректность кастов. И ошибок таких быть не должно

надо делать так, как делать надо, и не надо делать так, как не надо поэтому сильная и статическая типизация не нужна )

я когда взял себе труд тесты писать, проблемы не правильных кастов interface{} ушли

надо делать так, как делать надо, и не надо делать так, как не надо поэтому сильная и статическая типизация не нужна )

Типизация говоришь не нужна

хм заменить все эти аргументы про interface{} на js или python и никакой разницы не будет вообще

конечно есть же тесты

скоро мы научим писать компилятор тесты за нас, чтобы он проверял что мы пихаем в interface{}

Наконец-то более-менее нормальный проброс ошибок будет!!!!