Go Update

Тем временем Go 1.21 не за горами. Релиз будет меньше эпохального Go 1.18, но нас все равно ждут интересные вещи.

Главные из них:
▸ Улучшенные восходящая и обратная совместимости: начиная с Go 1.21 компилятор встречая строку go x.yy.z (где > 1.21.0) в файле go.mod сам скачает и использует соответствующий тулчейн. Это поведение можно настроить. В следующих заметках я постараюсь раскрыть эту особенность.

▸ clear(x) builtin for maps: то, что мы раньше делали через range { delete … } теперь можно будет сделать одной строчкой. Необходимость подобного непонятна ровно до тех пор, пока вы не начинаете работать с ключами у которых тип данных это число с плавающей запятой. Для интересующихся — каков будет результат вот этой программы? Ответ на вопрос «а почему?» Расс Кокс дал еще в 2012ом году.

▸ min / max функции: еще минус один повод для насмешек от пользователей других языков и возможность для легкого изменения в популярные проекты на Go.

▸ Обобщенные функции для работы со слайсами и мапами: больше не нужно помнить как вставить код в середину слайса.

▸ Пакет log/slog: zap / zerolog теперь и в стандартной библиотеке.

▸ Вывод типов для дженериков поумнел: теперь можно писать вот такой код.

Расс Кокс публикует новую статью или итераторам быть?

Позавчера Расс выложил новую статью под названием Storing Data in Control Flow, смысл которой сводится к рассуждению о хранении текущих данных внутри горутины, а примеры кода содержат фактически прямую реализацию паттерна «итератор». Те кто давно следят за блогом тех-лида Go компилятора знают, что каждая статья обычно предвещает выход нового предложения по улучшению языка. Так было с vgo (который стал go modules), так было с дженериками, так было с телеметрией в компиляторе. Не всегда эти предложения находят отклик среди сообщества - например предложение по телеметрии пришлось полностью переработать, сменив модель с opt-out на opt-in.

Кто-то спросит - а в чем собственно проблема? А проблем две, в которых вторая вытекает из первой:
1. range поддерживает только встроенные типы данных (массивы, слайсы, мапы и каналы). Итерацию по собственным типам приходиться делать с помощью создания и вызова методов Next, Scan, Iter. Отсутствие общего паттерна не было большой проблемой до появления дженериков, релиз которых состоялся в Go 1.18. Но вот с их приходом и появлением обобщенных функций для работы с коллекциями (в том числе и в стандартной библиотеке), собственные коллекции данных начинают все больше ощущаться как второсортные. А работа с ними разительно отличается от работы с встроенными коллекциями, что приводит к невозможности, например, создания обобщенного кода для работы со списками и слайсами.
2. Для map невозможно реализовать итератор стандартными средствами, в отличии от слайсов и каналов, т.к. не существует возможности сохранить нашу текущую позицию в мапе. Безусловно можно воспользоваться пакетом reflect (а любители темной магии могут подключить unsafe и скопировать обьявления из стандартной бибилотеки), но эти способы несут проблемы как по удобству, так по безопастности и скорости выполнения. Ситуацию можно решить и через каналы, но скорость подобного кода будет оставлять лучшего, а главное всегда будет существовать риск утечки памяти, если вы забудете закрыть генерирующую горутину.

Запрос на итераторы в open-source сообществе Go и в корпоративных кругах назрел давно. Дискуссия созданная Расс’ом от октября 2022 показывает, что разработчики языка проблему видят и даже имеют варианты решения. А недавняя заметка от разработчиков компилятора показывает, что решение первой проблемы планируют в Go 1.22. Поэтому вполне вероятно, что уже к следующему году нас снова ждет относительно большое обновление языка.

Channel photo updated

Channel created