Комментарии 27
Ну и в чём подробности? В ссылках на английские пресс-релизы? Скучненько.
Вышла Beta Go 1.18 с дженериками
Сначала люди годами рассказывают, что дженериков нет, потому что они не нужны, а если вам нужны, то вы не понимаете великий замысел. Теперь, видимо, будут переобуваться на лету.
Ждем exceptions, assertions, threads и что там дальше по списку.
Про дженерики вроде как уже несколько лет назад признали, что нужны и что будут думать как их делать, а про эксепшены пока все еще упорствуют, к сожалению.
Как-то нифига не клево, сделать лаконичный, немногословный язык и при этом заставлять пользователей так многословно эмулировать эксепшены. Все-таки эксепшены и обычные ошибки методов разные вещи, часто не пересекаемые.
Го вообще-то очень даже многословный :)
Вместо функциональных map, filter и тп - циклы, вместо тернарных выражений declare-if-else, вместо аннотаций - plain code или в лучшем случае go:generate и тп.
Я бы даже сказал, что го принципиально многословный, это такая часть go way, меньше магии - больше явного кода.
Ну это не отменяет того факта, что сначала они говорили что без дженериков можно обойтись
И придолжают говорить. 12 лет без них жили нормально и могли бы продолжить, если бы не придумали ничего годного. Дженерики это просто прикольная фича, но необходимости у языка в ней острой нет и не было. Авторы это понимали, поэтому разработка дизайна заняла столько, сколько потребовалось. Никто не собирался добавлять лишь бы что-то.
Есть некоторые подозрения, что вы не писали библиотек на go. Есть масса обобщенных алгоритмов, которые, ввиду отсутствия дженериков, кочуют из проекта в проект в виде копипасты кода с подстановкой типов. Только не говорите мне про кодогенерацию, пожалуйста. А вот исключения, действительно, не нужны, хотя какой-то альтернативный метод обработки ошибок вроде Maybe хотелось бы иметь, не спорю.
Когда это они говорили, извините? FAQ 2009го года сильно лаконичный, там про дженерики вообще ничего, ни плохого, ни хорошего, но в 2011м они уже говорили, что будут, но не сразу.
Эксепшенов не будет, это однозначно и точно. И поделом. У го у так есть два типа ошибок основных - паника и обычные ошибки. Эксепшенам здесь нет места, они приведут только к ухудшению читаемости и надежности кода. Это никаким место не эмуляция исключений. За эмуляцией лучше к свифт обращаться, где их сделали правильно и адекватно. Вот такие "исключения" в го еще могут появиться, которые совсем не исключения, по сути.
Сначала люди годами рассказывают, что дженериков нет, потому что они не нужны, а если вам нужны, то вы не понимаете великий замысел.
Не потому что не нужны, а потому что дизайн языка позволяет решать задачи, для которых Go применяется, без необходимости в дженериках. В Go нет такого ООП, как в других языках, которое создаёт ограничения, приводящие к тому что без дженериков становится невозможно решать определённые задачи.
В основном происходит как раз наоборот, когда люди, которые всю жизнь писали на джаве, до-диез и плюсах, с пеной у рта доказывают, как го загибается без дженериков и что они никому не будет нужен пока их там нет.
Это полезный инструмент, да. И он облегчит написание кода в некоторых случаях. Но в целом без них тоже неплохо, и в принятой имплементации всё равно есть некоторые недостатки.
Если бы дженерики были не нужны, стандартный массив не были бы дженериком неявным.
А так получается, что вшитому в язык типу можно то, что нельзя остальным.
Это и не нравится в подобных языках.
Ну вот пример, где дженерики нужны были изначально — sync.Map. Без дженериков тут конские приведения типов при каждом получении значения.
Найдите в этом примере признаки ограничений, созданных ООП, пожалуйста.
Как можно найти признаки ограничений, созданных ООП, в языке, где нет ООП?
Там где сейчас используется interface{} - дженерики не нужны, строго говоря. Они упрощают написание определенного кода, это правда. Позволяют оптимизировать исполняемый код, т.к. раскрываются на этапе компиляции, это тоже правда. Но в большинстве случаев, если вы пишете программы, а не теоритезируете, это не необходимость. Иначе бы никто не пользовался ни sync.Map, ни го в принципе.
Если использование interface{} и неудобные приведения типов считать за "дженерики не нужны", то возникает другой вопрос — а нужно ли в языке go вообще хоть что-то, включая сам язык go?
Можно же и без языка обходиться, ну будет немного неудобно, но в большинстве случаев, если вы пишете программы, а не теоритезируете, это не необходимость.
Вы очень ловко манипулируете фразами и передёргиваете, вместо того чтобы поддерживать конструктивный диалог.
Если вам изначально было не интересно ничего кроме того, чтобы подтвердить свою точку зрения — зачем было начинать?
Начнем с того, что в Go есть ООП, почти что самый классический, разве что можно методы вызывать, а не передавать объекту сообщения на обработку. interface{} - это выстрел себе в ногу и ломание статической типизации (весьма строгой замечу) через колено. Этот тип нужен, когда мы реально не знаем - что там (скажем, map[string]interface{}), в большинстве же случаев известен либо конкретный конкретный тип, либо набор типов. И передавая значение в функцию, я хочу знать, что передано значение неподходящего типа на этапе компиляции, а не во время отладки.
Ну это же не правда. Они всегда говорили, что дженериков пока нет, потому что они пока не знают, как правильно их реализовать.
Отрицание, гнев, торг, депрессия, принятие. Модель Кюблер-Росс
Это круто же, теперь можно один и тот же функционал использовать для разных типов. А еще появится больше полезных библиотек и фреймворков, которые не могли появится из-за этих ограницений. Того глядишь в следующей версии завезут исключения или как в расте Resut<T, E> и оператор "?", а потом всякие map, filter, аннотации и уже можно будет на него перекатываться)
Некоторые до сих пор против: https://github.com/golang/go/issues/48918
В Go есть кодогенерация, которая спасает.
Предположу, что сложность была не столько в добавлении дженериков, сколько в том, как их добавить не поломав структуру и идеологию языка.
Дженерики - худшее что сделали с Go за последнее время. Язык встал на скользкую дорожку усложнения и монструозности. Через десять лет будет ещё одна версия Java с пятью фреймворками, без которых никто ни строчки кода не может написать.
Вышла Beta Go 1.18 с дженериками. Подробности из блога Go под катом