Официальный релиз Go 1.18 состоится только через пару месяцев. Это первый предварительный выпуск Go 1.18, чтобы вы могли попробовать его и сообщить о проблемах. Go 1.18 Beta 1 — это огромный объём работы всей команды разработчиков Go в Google и участников проекта Go по всему миру. Нам очень хочется узнать ваше мнение.
Go 1.18 Beta 1 — первый предварительный выпуск, содержащий поддержку дженерик-кода с параметризованными типами. Дженерики — это самое значительное изменение в Go с момента выхода Go 1 и, конечно, самое крупное изменение в языке, которое мы делали когда-либо.
В любой крупной новой функции новые пользователи часто обнаруживают новые ошибки, и мы не ждём, что дженерики станут исключением; обязательно подходите к ним с соответствующей осторожностью. Кроме того, некоторые случаи, например определённые виды рекурсивных дженерик-типов, отложены до будущих релизов.
Мы знаем первых пользователей, которые остались довольны, и, если у вас есть сценарии использования, по вашему мнению особенно подходящие для дженериков, мы надеемся, что вы попробуете их.
Нами опубликовано краткое руководство о том, как начать работать с дженериками, и на прошлой неделе выступили с докладом на GopherCon. Вы даже можете попробовать новую версию в песочнице.
В Go 1.18 Beta 1 добавлена нативная поддержка фаззинга для автоматического поиска входных данных, которые приводят к аварийному завершению программы или возвращают неверные ответы. Появился режим рабочего пространства Go, позволяющий работать с несколькими модулями одновременно, что важно для больших проектов.
Команда go version -m, которая теперь записывает детали сборки, например флаги компилятора. Программа может запрашивать данные о собственной сборке через debug.ReadBuildInfo, а также при помощи debug/buildinfo может читать данные о сборке из других двоичных файлов.
Эта функциональность должна стать основой любого инструмента, которому необходимо создать спецификацию ведомость материалов ПО (SBOM) для двоичных файлов Go.
В этом году в Go 1.17 была добавлена новая конвенция вызова на основе регистров, чтобы ускорить работу кода на системах x86-64. Go 1.18 Beta 1 расширяет данную возможность на ARM64 и PPC64, и это увеличивает скорость на 20%.
Спасибо всем, кто участвовал в создании этого релиза, и особенно команде Google, которая в течение многих лет неустанно работает, чтобы сделать дженерики реальностью. Это был долгий путь, мы очень довольны результатом и надеемся, что он понравится и вам. Более подробную информацию смотрите в черновике описания релиза Go 1.18. Как всегда, если вы заметили какие-либо проблемы, пожалуйста, сообщите нам.
Научиться решать практические задачи на Go и других языках вы сможете на наших курсах:
Узнайте подробности акции.
Профессии и курсы
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также
Комментарии (28)
ncr
15.12.2021 19:44+23Вышла Beta Go 1.18 с дженериками
Сначала люди годами рассказывают, что дженериков нет, потому что они не нужны, а если вам нужны, то вы не понимаете великий замысел. Теперь, видимо, будут переобуваться на лету.
Ждем exceptions, assertions, threads и что там дальше по списку.
Politura
15.12.2021 20:58+2Про дженерики вроде как уже несколько лет назад признали, что нужны и что будут думать как их делать, а про эксепшены пока все еще упорствуют, к сожалению.
Как-то нифига не клево, сделать лаконичный, немногословный язык и при этом заставлять пользователей так многословно эмулировать эксепшены. Все-таки эксепшены и обычные ошибки методов разные вещи, часто не пересекаемые.
eyudkin
15.12.2021 21:31+13Го вообще-то очень даже многословный :)
Вместо функциональных map, filter и тп - циклы, вместо тернарных выражений declare-if-else, вместо аннотаций - plain code или в лучшем случае go:generate и тп.
Я бы даже сказал, что го принципиально многословный, это такая часть go way, меньше магии - больше явного кода.
iskateli
15.12.2021 21:51+1Ну это не отменяет того факта, что сначала они говорили что без дженериков можно обойтись
creker
16.12.2021 01:47-5И придолжают говорить. 12 лет без них жили нормально и могли бы продолжить, если бы не придумали ничего годного. Дженерики это просто прикольная фича, но необходимости у языка в ней острой нет и не было. Авторы это понимали, поэтому разработка дизайна заняла столько, сколько потребовалось. Никто не собирался добавлять лишь бы что-то.
Devoter
16.12.2021 11:07+2Есть некоторые подозрения, что вы не писали библиотек на go. Есть масса обобщенных алгоритмов, которые, ввиду отсутствия дженериков, кочуют из проекта в проект в виде копипасты кода с подстановкой типов. Только не говорите мне про кодогенерацию, пожалуйста. А вот исключения, действительно, не нужны, хотя какой-то альтернативный метод обработки ошибок вроде Maybe хотелось бы иметь, не спорю.
khim
17.12.2021 02:17+3Паника — это и есть исключения.
И да — панику удобно кидать и крайне неудобно ловить и это так и задумано.
khim
17.12.2021 02:12+1Когда это они говорили, извините? FAQ 2009го года сильно лаконичный, там про дженерики вообще ничего, ни плохого, ни хорошего, но в 2011м они уже говорили, что будут, но не сразу.
creker
16.12.2021 01:59+5Эксепшенов не будет, это однозначно и точно. И поделом. У го у так есть два типа ошибок основных - паника и обычные ошибки. Эксепшенам здесь нет места, они приведут только к ухудшению читаемости и надежности кода. Это никаким место не эмуляция исключений. За эмуляцией лучше к свифт обращаться, где их сделали правильно и адекватно. Вот такие "исключения" в го еще могут появиться, которые совсем не исключения, по сути.
gudvinr
15.12.2021 21:12+1Сначала люди годами рассказывают, что дженериков нет, потому что они не нужны, а если вам нужны, то вы не понимаете великий замысел.
Не потому что не нужны, а потому что дизайн языка позволяет решать задачи, для которых Go применяется, без необходимости в дженериках. В Go нет такого ООП, как в других языках, которое создаёт ограничения, приводящие к тому что без дженериков становится невозможно решать определённые задачи.
В основном происходит как раз наоборот, когда люди, которые всю жизнь писали на джаве, до-диез и плюсах, с пеной у рта доказывают, как го загибается без дженериков и что они никому не будет нужен пока их там нет.Это полезный инструмент, да. И он облегчит написание кода в некоторых случаях. Но в целом без них тоже неплохо, и в принятой имплементации всё равно есть некоторые недостатки.
MFilonen2
15.12.2021 21:49+13Если бы дженерики были не нужны, стандартный массив не были бы дженериком неявным.
А так получается, что вшитому в язык типу можно то, что нельзя остальным.
Это и не нравится в подобных языках.
0xd34df00d
16.12.2021 00:23+8В Go нет такого ООП, как в других языках, которое создаёт ограничения, приводящие к тому что без дженериков становится невозможно решать определённые задачи.
В хаскеле вообще нет ООП (настолько, насколько в достаточно богатом языке может не быть ООП), но без
дженериковполиморфизма в нём всё очень плохо было бы. Почему именно ООП?gudvinr
16.12.2021 03:01-5Потому что так вышло, что языки, имеющие схожую с Go область применимости, с которыми его сравнивают, и которые приводят в пример как альтернативы, это языки с ООП и дженериками/шаблонами.
DarkEld3r
16.12.2021 10:24+1О каких языках речь? Go довольно часто сравнивают с растом, но последний настолько же ООП, как и Go. Практически весь мейнстрим ООП-шный — это да, но тоже не вижу связи между ООП и дженериками.
mayorovp
16.12.2021 11:38+2Ну вот пример, где дженерики нужны были изначально — sync.Map. Без дженериков тут конские приведения типов при каждом получении значения.
Найдите в этом примере признаки ограничений, созданных ООП, пожалуйста.
gudvinr
16.12.2021 12:33-2Как можно найти признаки ограничений, созданных ООП, в языке, где нет ООП?
Там где сейчас используется interface{} - дженерики не нужны, строго говоря. Они упрощают написание определенного кода, это правда. Позволяют оптимизировать исполняемый код, т.к. раскрываются на этапе компиляции, это тоже правда. Но в большинстве случаев, если вы пишете программы, а не теоритезируете, это не необходимость. Иначе бы никто не пользовался ни sync.Map, ни го в принципе.
mayorovp
16.12.2021 12:56+2Если использование
interface{}и неудобные приведения типов считать за "дженерики не нужны", то возникает другой вопрос — а нужно ли в языке go вообще хоть что-то, включая сам язык go?Можно же и без языка обходиться, ну будет немного неудобно, но в большинстве случаев, если вы пишете программы, а не теоритезируете, это не необходимость.
gudvinr
16.12.2021 13:30-2Вы очень ловко манипулируете фразами и передёргиваете, вместо того чтобы поддерживать конструктивный диалог.
Если вам изначально было не интересно ничего кроме того, чтобы подтвердить свою точку зрения — зачем было начинать?Devoter
17.12.2021 06:59+1Начнем с того, что в Go есть ООП, почти что самый классический, разве что можно методы вызывать, а не передавать объекту сообщения на обработку.
interface{}- это выстрел себе в ногу и ломание статической типизации (весьма строгой замечу) через колено. Этот тип нужен, когда мы реально не знаем - что там (скажем,map[string]interface{}), в большинстве же случаев известен либо конкретный конкретный тип, либо набор типов. И передавая значение в функцию, я хочу знать, что передано значение неподходящего типа на этапе компиляции, а не во время отладки.
makarychev_13
15.12.2021 21:21+5В faq go с самого начала было написано, что они не против дженериков, просто сейчас якобы есть дела поважнее
dream_designer
15.12.2021 22:33+2Ну это же не правда. Они всегда говорили, что дженериков пока нет, потому что они пока не знают, как правильно их реализовать.
vyacheslavchulkin
16.12.2021 10:12-1Отрицание, гнев, торг, депрессия, принятие. Модель Кюблер-Росс
Это круто же, теперь можно один и тот же функционал использовать для разных типов. А еще появится больше полезных библиотек и фреймворков, которые не могли появится из-за этих ограницений. Того глядишь в следующей версии завезут исключения или как в расте Resut<T, E> и оператор "?", а потом всякие map, filter, аннотации и уже можно будет на него перекатываться)
makarychev_13
16.12.2021 11:33-1Того глядишь в следующей версии завезут исключения или как в расте Resut<T, E> и оператор "?", а потом всякие map, filter, аннотацииЭтого точно не будет. Кроме разве что map/filter/reduce. Если вам всего этого не хватает, то го точно не для вас.
NN1
16.12.2021 11:41-1Некоторые до сих пор против: https://github.com/golang/go/issues/48918
В Go есть кодогенерация, которая спасает.
Hoksmur
16.12.2021 12:45-1Предположу, что сложность была не столько в добавлении дженериков, сколько в том, как их добавить не поломав структуру и идеологию языка.
pin2t
16.12.2021 05:14-1Дженерики - худшее что сделали с Go за последнее время. Язык встал на скользкую дорожку усложнения и монструозности. Через десять лет будет ещё одна версия Java с пятью фреймворками, без которых никто ни строчки кода не может написать.
nickolaym
Ну и в чём подробности? В ссылках на английские пресс-релизы? Скучненько.