TGViewer
Channel Public Channel
Golang Дайджест

Golang Дайджест

@golang_digest

Самое интересное из мира Go: новости, статьи, проекты, сервисы, изменения в языке и др.

Посты публикуются не часто - только самое важное, с чем я лично ознакомился.

Поэтому можно не мьютить канал =)

Обратная связь: @justskiv
Subscribers
13.4K
Photos
47
Videos
1
Links
218
Recent Posts 20 shown
Post #363 2.59K
Golang Дайджест

This post (sticker, poll or similar) has no web preview. Open in Telegram

  • 👍 17
  • 🔥 10
  • ❤ 4
Post #362 2K

Forwarded from Николай Тузов

Дописал самый большой кусок статьи про Go 1.27 — раздел про постквантовые подписи.

В 1.27 приехал пакет crypto/mldsa и вся обвязка вокруг него (сертификаты, TLS). Обмен ключами добавили ещё в 1.24, а теперь очередь дошла до аутентификации — то есть на чистом Go наконец-то полностью собирается постквантовый хендшейк 🎉

Обычно этому разделу в обзорах уделяют незаслуженно мало внимания — многие плохо понимают в чём тут суть, и кажется, что это касается каких-то мифических "специалистов по безопаности". А те кто разбираются чуть лучше, думают что чесаться ещё рано, потому что достаточно мощных квантовых компьютеров ещё не существует. Но на самом деле, это касается всех нас уже сейчас.

В новом разделе я написал подробный ликбез про постквантовую криптографию, а также объяснил почему это актуально уже сейчас.

Также я там рассказал:

- Почему главная проблема ML-DSA — размер, а не скорость
- Зачем в crypto.Hash появилось значение MLDSAMu (которое хеш-функцией не является)
- Что со всем этим делать прямо сейчас

Сниппеты, как обычно, запускаются прямо со страницы статьи на актуальном go1.27. Можно сгенерировать ML-DSA-ключ, подписать сообщение и посмотреть, во что превращается минимальный самоподписанный сертификат: почти четыре килобайта против 217 байт у Ed25519. Бюджет TLS-хендшейка я нарисовал отдельным наглядным виджетом 🦄

Да, статья всё ещё не дописана, работаю над ней прямо сейчас. Остались рантайм, net/http, SIMD, тулинг и раздел про то, что может сломаться при апгрейде.

————

Возился с этим разделом дольше, чем с любым другим в статье: криптография — не та область, где можно писать по памяти, каждый абзац сверялся со стандартами, документацией и т.п.. Надеюсь, вам понравится ❤️

Начал писать про один пакет, а закончил рассказом про алгоритм Шора и решётки 😩

Кстати, если хочется отдельного разбора — как вообще устроены обмен ключами, подписи и шифрование, напишите в комментариях. Если тема востребована, сделаю. Ну и про постквантовую криптографию можно подробнее рассказать, раз уж я в это погрузился.
GoLang Guides Go 1.27: большой интерактивный разбор Разбор Go 1.27: дженерик-методы, движок encoding/json/v2, пакет uuid в stdlib, постквантовые подписи crypto/mldsa и профиль утечек горутин в pprof.
  • ❤ 17
  • 👍 9
  • 🔥 6
Post #361 3.35K

This post (sticker, poll or similar) has no web preview. Open in Telegram

  • ❤ 35
  • 🤯 17
  • 🔥 7
  • 👍 1
Post #358 4.05K

Forwarded from Николай Тузов

😐 Ультимативный разбор... Go 1.27?

Честно, не знаю зачем я это сделал, но я сделал.. Ну почти.

https://golang.guide/go-1-27/

Сначала я решил просто написать базовый обзор релиза. Но потом я увлёкся и не смог вовремя остановиться.

Мне хотелось не просто сухо рассказать об изменениях, а добиться глубокого понимания читателя — причины этих изменений, какие проблемы они решают, как реализовано, почему именно сейчас, какая история стоит за самыми интересными фичами. При этом, я старался писать так, чтобы всё это читалось интересно и легко.

В итоге, работа над статьёй так сильно затянулась, что когда она выйдет, сам релиз уже никому не будет интересен. Поэтому я решил опубликовать ту её часть, которая уже готова — это примерно 60%, и туда вошло всё самое интересное и важное:

- Дженерик-методы, которые десять лет обещали не добавлять
- Новый движок JSON v2
- Пакет uuid наконец-то в стандартной библиотеке
- Детектор утечек горутин, который переиспользует сборщик мусора — на мой взгляд, самое красивое, что есть в этом релизе

Во вторую половину войдут: постквантовые подписи, рантайм, net/http, SIMD и тулинг. Это я дописываю прямо сейчас, оно появится в той же статье.

Все код-сниппеты запускаются прямо из статьи на актуальном go1.27. Каждый из них можно редактировать и экспериментировать — не нужно открывать отдельный плэйграунд. А ещё я подготовил для вас наглядный виджет с демонстрацией механики работы детектора утечки горутин.

Я потратил на эту статью ОЧЕНЬ много времени. Возможно, стоило потратить на более фундаментальный гайд — тот же GC, над которым я также сейчас работаю. Но надеюсь, вам всё же понравится ❤️
Стоит ли писать подобные обзоры про новые релизы?

————

А ещё я прикрутил к сайту email-рассылку (и письмо про Go 1.27 туда ушло сильно раньше этого поста) и комментарии к статьям. Если вдруг заметите какие-то баги, пишите в комментариях, постараюсь оперативно поправить.

И не хулиганьте в комментариях на сайте!
👍

#article #go1_27
  • 🔥 43
  • ❤ 17
Post #357 6.01K
Golang Дайджест 🦄 Go 1.27: дженерик-методы, json/v2 в проде и профиль утёкших горутин 🟠Draft release notes — релиз ожидается уже в августе Главное — дженерик-методы Я писал об этом ещё на этапе пропозала, поэтому подробно описывать тут не буду. Вкратце: метод теперь может…
Вышел Go 1.27

https://go.dev/doc/go1.27

Подробный интерактивный разбор ещё готовлю, подкаст с обсуждением версии тоже будет. Следите за обновлениями ☀️
go.dev Go 1.27 Release Notes - The Go Programming Language
  • 🔥 31
  • 👍 9
  • ❤ 7
  • 🤔 2
Post #356 7.66K
📆Канал с разборами внутренностей Go и не только

Хочу порекомендовать вам ещё один канал, который сам давно почитываю — очень крутые глубокие разборы и авторский стиль, всё как я люблю.

Не реклама, честная рекомендация 🫶
Telegram Daria’s room Копаюсь в недрах Go, проектирую схемы, абстракции, а главное - учусь Буду рада пообщаться! -> @darya_smyr https://github.com/dariasmyr
  • ❤ 21
  • 🔥 13
  • 👍 5
  • 🤔 1
Post #355 7.15K
SIMD в Go 1.27

https://habr.com/ru/articles/1062972/

Раз уж в Go завозят SIMD, вот хороший разбор по нему.

Начинается с ликбеза — как процессор вообще складывает числа, что такое векторные регистры и полосы, почему одна инструкция может сложить восемь чисел за раз. Дальше автор берёт go1.27rc2 и проверяет всё руками на двух машинах: M3 Pro и i9-14900KF.

Напомню, что в 1.27 под флагом GOEXPERIMENT=simd обещают портируемый пакет simd: типы вида Float32s, у которых ширина неизвестна на этапе компиляции. Компилятор кладёт в бинарь четыре ветки (@simd0/128/256/512) и на рантайме выбирает нужную.

Основные тезисы разбора:

- Дизассемблер: FADD против VADDPS
- Откуда берётся ускорение — и почему обещанные 8x на практике превращаются в 5x
- Стена памяти: пока массив влезает в L3 — 5x, а дальше упор в память и 2.2x
- P-ядра против E-ядер и куда вообще сядет ваш бенчмарк
- Где SIMD не помогает

#go1_27 #article #performance #simd
  • ❤ 11
  • 🔥 6
  • 👍 3
  • 🤔 1
Post #353 8.79K
🦄 Go 1.27: дженерик-методы, json/v2 в проде и профиль утёкших горутин

🟠Draft release notes — релиз ожидается уже в августе

Главное — дженерик-методы

Я писал об этом ещё на этапе пропозала, поэтому подробно описывать тут не буду.

Вкратце: метод теперь может объявлять собственные типовые параметры. Долгое время такое приходилось писать в виде обычной функции:

// Было — только обычной функцией
func MapSlice[T, U any](s Slice[T], f func(T) U) Slice[U]

// Стало — можно методом
func (s Slice[T]) Map[U any](f func(T) U) Slice[U]


То есть, мы писали MapSlice(s, f) вместо s.Map(f). Потому что метод так не умел. Теперь умеет.

Из ограничений: методы интерфейсов свои типовые параметры объявлять не могут, и дженерик-метод не может реализовать метод интерфейса.

Другие изменения в языке:

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

// Было
u := User{Timestamps: Timestamps{CreatedAt: now}, Name: "Вася"}

// Стало
u := User{CreatedAt: now, Name: "Вася"}


Читать и писать в u.CreatedAt напрямую можно было всегда, а теперь и в литерале. Тикету одиннадцать лет 🙃

2. Компилятор наконец-то сам везде выводит тип:

func g[T any](T) {}
type S struct{ f func(int) }

// Было
s.f = g // ok
s = S{f: g} // ошибка, нужно g[int]

// Стало
s = S{f: g} // ok


Тип поля известен, T выводится однозначно — но в литерале это почему-то не работало. Теперь работает везде: литералы структур, массивов, слайсов и мап, отправка в канал, конверсии.

Griesemer в issue сам назвал это скорее багом, чем языковым изменением.

Доехал encoding/json/v2

И самое интересное — v1 теперь под капотом работает на v2. Поведение сохранено, тексты ошибок могут отличаться. Marshal примерно как был, Unmarshal заметно быстрее.

Мигрировать не обязательно, v1 API будут поддерживать и дальше. Если что-то сломается — GOEXPERIMENT=nojsonv2.

Goroutine leak profile доехал из экспериментального в стабильный

Искать тут: /debug/pprof/goroutineleak

Рантайм ловит утёкшие горутины через GC — если горутина заблокирована на примитиве, до которого не дотянется ни одна runnable-горутина (и ни одна из тех, кого те могли бы разбудить), значит разблокировать её некому. Ловит не всё, но большой класс — да. Сделал Vlad Saioc из Uber.

Что ещё интересного:

- Новый пакет uuid в стандартной библиотеке ✨

- Response.Body при Close сам дочитывает остаток тела — чтобы соединение ушло в пул, а не закрывалось. В разумных пределах и только для HTTP/1. Наш любимый io.Copy(io.Discard, resp.Body) можно выкидывать в большинстве случаев 🔥

- Некоторые аллокации мелких объектов (<80 байт) до 30% быстрее. В реальных allocation-heavy программах ~1%, бинарь +60 КБ

- strings.CutLast и bytes.CutLast — режут по последнему вхождению сепаратора

- net/url: URL.Clone() и Values.Clone()

- go doc умеет package@version и флаг -ex для примеров

- Unicode 15 → 17

- macOS 13 Ventura и новее. Как и обещали в 1.26

————

🟢 Дженерик-методы — та фича, которую ждали с самого выхода дженериков в 1.18. Как по мне, главный итог даже не «стало можно», а то, что перестанет расти пакетный неймспейс из функций, которые логически принадлежат типу.

А вот с json/v2 интересно. Тихо переключить v1 на новую реализацию — смелый ход, учитывая сколько кода в мире парсит этот пакет. Обещают такое же поведение, но так не бывает. Да и GOEXPERIMENT=nojsonv2 в релиз-нотах как бы намекает 🌚
Вполне можно ожидать, что в первые месяцы будем читать байки про «а у нас после апгрейда...».

uuid в стандартной библиотеке — это здорово. Сколько лет google/uuid был де-факто стандартом — пора уже добавить в stdlib.

Релиз ещё черновой, так что что-то может доехать или отвалиться.

————

Я сейчас готовлю большой интерактивный разбор этого релиза на своей новой платформе, которую недавно анонсировал. Если вам что-то из текущего поста было непонятно — после прочтения разбора поймёте, там я постарался изложить всё подробно и простым языком, да ещё и с живыми примерами.

Скорее всего, опубликую уже на днях (и разбор, и первую статью из обновлённой серии про планировщик).

#go1_27 #go_official #generics #json
  • 👍 57
  • 🔥 21
  • ❤ 12
  • 🤯 1
Post #350 8.88K

Forwarded from Go Update

⚠️ CVE-2026-42501 или почему вам нужно обновиться до Go 1.26.3/go1.25.10 ⚠️

Те кто давно работают с Go (или читают меня) знают, что целостность наших модулей гарантируется не только HTTPS транспортом до самой прокси, но и отдельной базой SumDB, которая хранит в себе хеши модулей подписанные приватным ключом. При этом сама база устроена так, что невозможно внести изменения в прошлые записи, без каскада изменений в новые, тк каждый блок «подписан» предыдущим.

Но в ИБ сама безопастность это устойчивость самого слабого звена в цепочке. Достаточно одной маленькой ошибки, что-бы вся надежно выстроенная архитектура ИБ превратилась в пыль. Так и случилось в нашем случае.

Рассмотрим сценарий: при получении модуля от прокси, Go проверяет его хеш с использованием SumDB, блоки которой, как я уже говорил выше, подписаны приватным ключом. В псевдокоде это выглядит следующим образом:


for _, line := range sumdbResponse {
if line относится к нужному module@version {
if hash не совпадает {
return SECURITY ERROR
}
}
}
return nil


На первый взгляд, всё кажется логичным: если пришел ответ, проверяем хеш нужного модуля и при несовпадении валимся с ошибкой. При совпадении выходим из функции и продолжаем работу. Однако здесь кроется одна маленькая, но критичная деталь: что будет если нам вернут ответ без записей или запись про другой модуль? Скомпроментированная прокся может отдать специально подготовленный ответ, который наш клиент воспримет как правильный — достаточно выдать ответ с корректными хешами для любых модулей или даже выдать ответ без хешей. Поскольку go get пишет записи в go.sum с локально подсчитанного хеша, подмену никто не заметит, и тулинг спокойно продолжит работу, положив модуль от скомпрометированной прокси в go.mod/go.sum. Который, в свою очередь, будет использован компилятором при сборке проекта.

Т.е. перед нами классическая уязвимость которая позволяет организовать Supply Chain Attack (атака на зависимости), пример которой можно описать вот так:

1. Прокся отдаёт клиенту изменённый архив модуля, например rsc.io/foo@v1.0.0.
2. На запрос хеша возвращается валидный, криптографически корректный ответ от checksum database, но для другого модуля, например rsc.io/bar@v1.0.0.
3. go get видит: «ответ sumdb валидный, несовпадающего хэша нет» — и продолжает работу.

Т.е. вы получаете измененный модуль, у которого хеш оригинала можно узнать только после удаления go.sum и изменения прокси или использования direct в GOPROXY.

Проблема бы не была такой большой (ибо у большинства переменную GOSUMDB, отвечающую за источник правды о хешах, никто не трогает, а для загрузки тулчейна её вообще невозможно переопределить) если бы не два но:

• Директивы toolchain и go позволяют выбирать нужную версию компилятора автоматически, и при необходимости, скачивать её с той же самой прокси.
• go get всегда сначала спрашивает проксю, может ли та проксировать запросы до базы хешей GOSUMDB. Если ответ положительный, то она просто спросит её о хеше, вместо обращения непосредственно к GOSUMDB.

В этой ситуации фактически всю цепочку доставки модулей до клиента (и тулчейнов, если явно не запрещен автовыбор) контролирует один узел. Поэтому, если у вас изменена GOPROXY или вы не доверяете сертификатам TLS установленным в системе, то я очень рекомендую вам обновиться. При этом вам недостаточно обновить версию go (или toolchain) в файле go.mod, ведь изначальный тулчейн будет по-прежнему работать по старой логике. Нужно именно установить новую версию компилятора, заменив ту которая стоит «по умолчанию» в системе, а затем прогнать rm go.sum && go mod tidy в проектах которые могут быть скомпрометированы.

При всей опасности атаки, фикс у неё самый тривиальный: return nil просто заменили на


return module.VersionError(modWithoutSuffix, fmt.Errorf("verifying %s: checksum missing from sumdb response"+sumdbAbsent, noun))


П.С. Именно поэтому я рекомендую использовать приложения типа direnv для установки переменных GOPROXY или GOPRIVATE только для рабочих проектов.
Telegram Go Update Про go mod tidy | verify | download Задумывались ли вы о том, как именно Go проверяет целостность ваших скаченных модулей? Как наш тулчейн проверяет, что зависимости которые вы видите в своем проекте, соответствуют зависимостям которые видят другие разработчики?…
  • 👍 10
  • ❤ 7
  • 🔥 3
Post #349 8.43K
👴 Почему в Go нет тернарного оператора?

https://dburov.com/ru/research/go-ternary

Дмитрий Буров провёл большое исследование на эту старую добрую тему и попросил меня поделиться ей, чтобы собрать мнение сообщества — внизу статьи есть короткий опрос из 4 вопросов.

Вкратце, о чём материал:

- Позиция core-команды Go не менялась с 2009 года: ?: порождает непроницаемо сложные выражения, if-else «бесспорно яснее», языку нужна только одна конструкция управления потоком

- Проблема в том, что эта позиция никогда не подкреплялась реальными данными — только мнением авторов языка. Каждый новый proposal с 2019 года закрывается ссылкой на FAQ без содержательного разбора

- Дмитрий написал статический анализатор и прогнал 4 крупных репозитория: golang/go, kubernetes, terraform, traefik

- Нашёл 22 000+ паттернов, которые однозначно заменяются плоским тернарником (условный return, условное присваивание, раздутый конструктор, inline-выражение)

- От 10% до 16% функций содержат хотя бы один такой паттерн. То есть каждая 6-9 функция

И главный аргумент автора: команда Go запрещает оператор целиком из-за того, что его можно использовать во вложенном виде и получить нечитаемую кашу. Но другие языки давно решили эту проблему иначе — оставили сам оператор, а запретили именно вложенность: в JS через ESLint-правило no-nested-ternary, в C++ через clang-tidy, в PHP 8 вложенный ?: без скобок стал ошибкой компиляции. Go мог бы сделать то же самое через go vet, не лишая разработчиков плоских однострочников.

————

Тема холиварная, поэтому Дмитрию особенно важно собрать мнения — как тех, кто «за», так и тех, кто «против».

Выборка заведомо смещена (сюда придут неравнодушные), но цель не в репрезентативности, а в том, чтобы проверить: совпадают ли представления команды Go о восприятии этих паттернов с тем, что говорят сами разработчики.

В общем, предлагаю ознакомиться и выразить своё мнение.

#article #research
Dburov Тернарный оператор в Go – почему в языке нет «?:» и почему это может быть ошибкой Эмпирическое исследование: статический анализ публичных Go-репозиториев, разбор аргументов команды Go и proposal по добавлению условного выражения в язык.
  • ❤ 29
  • 🔥 14
  • 🤔 11
  • 👍 8
Post #343 10.2K
🟦 ❤️ Modern Go Guidelines от GoLand Team — чтобы AI-агенты перестали писать устаревший Go

https://github.com/JetBrains/go-modern-guidelines

Ребята из JetBrains сделали набор гайдлайнов для AI-агентов (Claude Code и Junie), чтобы те писали современный Go, а не код образца 2018 года.

Проблема реальная и знакомая каждому, кто пользуется ИИ-ассистентами для Go:

- Отсечка данных: модели не знают фичи, добавленные после их обучения. Claude Opus 4.6 обучен по май 2025 — про Go 1.26 он не в курсе.

- Частотный перекос: в тренировочных данных в разы больше for i := 0; i < n; i++, чем for i := range n. Модель выбирает то, что встречала чаще.

В результате агент вместо slices.Contains(roles, role) пишет ручной цикл на 7 строк, вместо new("hello") городит s := "hello"; &s, а про errors.AsType[T] вообще не слышал.

Что делает плагин:

- Определяет версию Go из go.mod
- Инструктирует агента использовать фичи только до этой версии включительно
- Покрывает всё от Go 1.0 до 1.26: cmp.Or, min/max, wg.Go(), b.Loop(), strings.SplitSeq, new(val) и т.д.

Как подключить:

- В Junie (GoLand) — работает из коробки начиная с версии 2xx.620.xx
- В Claude Code — ставится как плагин, активируется командой /use-modern-go

🟢Ребята из GoLand Team протестировали его на 40 примерах и убедились, что без гайдлайнов Claude Code пишет откровенно устаревший код.

————

А что на счёт go fix?

Как мы помним, в Go 1.26 полностью переписали go fix. Теперь это мощный инструмент с 20+ анализаторами-модернизаторами 👍

minmax
, rangeint, slicescontains, stringscut, mapsloop, forvar, newexpr и другие. Одна команда go fix ./... — и ваш код автоматически переписывается на современные идиомы.

Go Team сами признались, что LLM-ассистенты — одна из причин, почему они взялись за modernize-анализаторы. Чтобы в тренировочных данных было больше современного кода, нужно сначала модернизировать существующий.

Так решает ли go fix ту же задачу?

Частично — да. Если ваш агент написал for i := 0; i < n; i++ вместо for range n, go fix это подчистит. Но есть нюанс: go fix работает постфактум с уже написанным кодом, а гайдлайны JetBrains заставляют агента писать правильно с самого начала. Это два дополняющих друг друга подхода: один — «пиши сразу нормально», другой — «подстрахуем на всякий случай».

Мой совет: подключайте гайдлайны + гоняйте go fix после каждого обновления тулчейна. Ну или, как один из комментаторов на HN предложил, добавьте golangci-lint с modernize-линтером в CLAUDE.md — пусть агент сам за собой убирает.

🟠Важно! Проект свежий и полностью открытый, любой вклад приветствуются — можно добавлять поддержку других агентов, новые правила и любые улучшения. Ребята из GoLand Team будут только рады. Мне об этом лично сказали.

#ai #tools
GitHub GitHub - JetBrains/go-modern-guidelines: Help AI coding agents write modern Go Help AI coding agents write modern Go. Contribute to JetBrains/go-modern-guidelines development by creating an account on GitHub.
  • 👍 35
  • 🔥 12
  • ❤ 11
Post #342 8.43K
Golang Дайджест 🔨 Два активных proposal с жаркой дискуссией Proposal #1: Вернуть go mod init к здравому смыслу В Go 1.26 тихо поменяли поведение go mod init: теперь он выставляет в go.mod директиву go 1.25 вместо go 1.26. Идея была в том, чтобы новый модуль был "по умолчанию…
🔐 Go 1.26.1 — откат go mod init и мелкие security фиксы

https://go.dev/doc/devel/release#go1.26.1

Security-фиксы в crypto/x509, html/template, net/url и os — стоит обновиться.

Также тут мелкие багфиксы в компиляторе, go command, go fix, os и reflect.

Самое главное — откатили поведение go mod init обратно к здравому смыслу, о котором я
недавно писал. Быстро одумались 🧙

#go1_26 #release
go.dev Release History - The Go Programming Language
  • 👍 25
  • ❤ 8
Post #340 8.01K
🔨 Два активных proposal с жаркой дискуссией

Proposal #1: Вернуть go mod init к здравому смыслу

В Go 1.26 тихо поменяли поведение go mod init: теперь он выставляет в go.mod директиву go 1.25 вместо go 1.26. Идея была в том, чтобы новый модуль был "по умолчанию совместим" со старыми тулчейнами.

Проблема в том, что это ломает ожидания:

$ go version
go version go1.26

$ go mod init myproject
# go.mod теперь содержит: go 1.25

$ go build
./main.go: new(42) requires go1.26 or later


То есть читаешь про новые фичи Go 1.26, устанавливаешь его, создаёшь новый проект — и получаешь ошибку! Потому что go mod init тайком выставил тебе прошлую версию 😡

Автор proposal (и большинство комментаторов) считают это контринтуитивным: если хочешь поддерживать старые версии — осознанно понизь директиву сам. По умолчанию же должна быть версия твоего тулчейна.

Аргумент Go Team: "это полезно для совместимости при публикации модуля".
Контраргумент: forward compatibility в тулчейне уже решает эту проблему — если нужная версия не установлена, Go скачает её сам.

————

Proposal #2: UUID в стандартной библиотеке

Предложение добавить crypto/uuid в stdlib. Открыто ещё в августе 2023 (!!), обсуждение до сих пор живое.

Аргументы за очевидны: UUID нужен в каждом втором сервисе, google/uuid — один из самых популярных импортов в Go-проектах, и практически все языки уже имеют UUID из коробки — C#, Java, Python, JavaScript, Ruby. Go — исключение.

Статус в Proposal Projects — "Likely Accept", то есть Go Team склоняется к тому, чтобы принять. Шансы появления UUID в stdlib довольно высокие.

————

Мне тут даже комментировать нечего — решение про go mod init считаю крайне странным, надо вернуть его в норму.
Представьте лицо новичка в Go, который впервые создал проект 😄

🟢В списке релизов уже можно видеть, что в Go 1.26.1 это поведение откатят

Добавить генерацию UUID в stdlib давно пора.

Если подытожить, оба proposal отражают одно и то же: Go бережёт обратную совместимость и осторожничает с расширением stdlib — иногда в ущерб удобству разработчика.

#proposal #go1_26
GitHub cmd/go: change `go mod init` default go directive back to 1.N · Issue #77653 · golang/go Proposal Details I was surprised to see #74748 in 1.26. I think this behavior is confusing: ❯ cat t.go package main import "fmt" func main() { fmt.Println(new(42)) } ❯ go run t.go 0x4a524...
  • ❤ 21
  • 👍 15
  • 🔥 4
Post #338 9.15K
Golang Дайджест 🧬 Proposal: Generic Methods для Go Robert Griesemer (один из авторов языка) открыл proposal, который многие считали невозможным. Go FAQ буквально говорил: > We do not anticipate that Go will ever add generic methods Но теперь — возможно, добавят 👍 Суть…
🚨 BREAKING

Generic methods proposal официально принят — автор Robert Griesemer.

Это одно из самых ожидаемых изменений в Go после дженериков.
GitHub spec: generic methods for Go · Issue #77273 · golang/go Proposal: Generic Methods for Go A change of view. Background For clarity, in the following we use the term concrete method (or just method when the context is clear) to describe a non-interface me...
  • 🔥 34
  • 🤯 15
  • ❤ 4
  • 👍 1
Post #336 9.04K
Golang Дайджест 🧬 Proposal: Generic Methods для Go Robert Griesemer (один из авторов языка) открыл proposal, который многие считали невозможным. Go FAQ буквально говорил: > We do not anticipate that Go will ever add generic methods Но теперь — возможно, добавят 👍 Суть…
  • ❤ 6
  • 👍 4
Post #334 10.7K
🧬 Proposal: Generic Methods для Go

Robert Griesemer (один из авторов языка) открыл proposal, который многие считали невозможным. Go FAQ буквально говорил:

> We do not anticipate that Go will ever add generic methods

Но теперь — возможно, добавят 👍

Суть в том, что раньше дженерик-методы блокировались по цепочке: если методы могут принимать параметры типов, значит и методы интерфейсов тоже должны. А это не знали как реализовать эффективно — в Go тип реализует интерфейс неявно, поэтому компилятор не может знать заранее, для каких конкретных типов нужно будет скомпилировать метод.

Ключевой сдвиг в мышлении: метод — это не только способ реализовать интерфейс. Метод — это функция, привязанная к типу, удобная для организации кода и читаемая слева направо. Эти две вещи ортогональны.

Поэтому компромисс такой: методы могут быть generic, но не могут реализовывать интерфейсы с generic методами — их просто не будет. Вот как это выглядит:

type Reader struct{ … }
func (*Reader) Read[E any]([]E) (int, error) { … }


Reader не реализует io.Reader — и это нормально. Зато метод полезен сам по себе.

При этом изменение полностью обратно совместимо и не закрывает возможность добавить такое в будущем, если придумают как.

————

Дискуссия горячая — 156 комментариев. Кто-то радуется, кто-то боится усложнения языка, классика. За то и люблю наше сообщество ✨

Я сам редко работаю с дженериками, но при этом даже я не раз сталкивался с этим ограничением. Приходится делать standalone функции вместо методов — цепочки вызовов ломаются, читаемость страдает.

За я или против? Честно, не знаю — вопрос действительно непростой, если вникать глубоко в проблематику и доводы обоих сторон. Поэтмоу я предпочитаю делегировать столь сложные вопросы бородатым мужчинам — я в них верю! ❤️

Посмотрим, примут ли. Но сам факт, что Griesemer это открыл — уже хороший сигнал.

#proposal #generics
  • ❤ 28
  • 👍 11
  • 🔥 8
Post #333 5.96K

Forwarded from Tuzov AI Lab

😩 Go Team vs вайбкодеры

https://groups.google.com/g/golang-dev/c/4Li4Ovd_ehE

Кто-то залил CL (changelist, аналог Pull Request в системе Gerrit) в Go с тегом Co-Authored-By: Claude Opus 4.5 в описании коммита. Ian Lance Taylor это заметил и поднял вопрос в рассылке golang-dev: а вообще есть ли политика по поводу AI-написанного кода? Авторские права, CLA — всё это висит в воздухе.

Ответ Rob Pike:

> Это очень скользкая дорожка. Осторожнее с первым шагом. Рекомендую просто сказать: нет.

Через несколько дней Russ Cox написал огромный взвешенный ответ. И это, пожалуй, лучший текст о месте AI в разработке, что я читал за последнее время. Рекомендую вам ознакомиться с ним целиком лично.

Самый сочный кусок — про "танцующих слонов":

> Люди хвастаются кодовыми базами на сотни тысяч строк, которые никто никогда не смотрел, написанными в рекордные сроки. При ближайшем рассмотрении они неизменно оказываются скорее танцующими слонами, чем полезными engineering-артефактами.

То есть, они впечатляют, но только пока не присмотришься — слишком большие, медленные, много багов, и никто не знает как их поддерживать.

Его позиция: фундаментальные вещи software engineering не изменились. AI — это инструмент, как редактор или профайлер. Можно писать качественный код с помощью AI, но только если не отключать мозг. Контрибьютор всё так же обязан присылать код, который он сам проревьюил и обдумал — AI не снимает с тебя ответственности.

По авторским правам: Google's OSPO разобрался, используйте спокойно. Но интересно другое: Alan Donovan в треде заметил, что значительная часть CLs уже содержит LLM-сгенерированный код — авторы просто не признаются.

По Co-Authored-By — убрать. Причина прямолинейная: это бесплатная реклама AI-компаниям, и ничего больше. Юридически строчка бессмысленна (AI не может быть автором по US copyright), информации не несёт — непонятно кто что написал, и даже как маркер использования AI не работает: модель сама непоследовательно решает, добавлять её или нет.

————

Позиция Russ Cox мне близка, т.к. я лично сталкивался с подобными случаями даже на работе — когда разработчик перегибал с вайбкодингом. Работать с этим становится невозможно, проще переписать с нуля.

"Танцующие слоны" — это хорошее описание того, что происходит когда люди воспринимают AI как замену мышлению, а не как инструмент. Go team явно не собирается идти по этому пути ❤️

#goteam #llm #claude
  • 🔥 57
  • ❤ 33
  • 👍 14
  • 🤔 1
Post #331 7.65K
Go Update Обещают в ближайших постах в блоге рассказать больше о новом go fix и как оно работает внутри
🔧 go fix в Go 1.26 — автоматическая модернизация кода

Обещали, рассказали 📆
Пост в официальном блоге Go

Итак, в v1.26 полностью переписали go fix — теперь это полноценный инструмент автоматической модернизации кода, а не заброшенный реликт из ранних версий языка.

Как пользоваться:

$ go fix ./...       # исправить всё
$ go fix -diff ./... # только посмотреть что изменится
$ go tool fix help # список всех анализаторов


Примеры того, что он умеет автоматически исправлять:

- interface{} → any

- for i := 0; i < n; i++ → for range n

- strings.Index + слайсинг → strings.Cut

Или даже целые конструкции, например:

x := f()
if x < 0 {
x = 0
}
if x > 100 {
x = 100
}


Превратится в такое: min(max(x, 0), 100)
(хотя, на мой взгляд, так читается чуть сложнее, но тут дело вкуса)

- квадратичная конкатенация строк в loop → strings.Builder

Ещё одна интересная штука — синергия фиксов: один fix открывает возможность для другого. Поэтому иногда стоит запустить команду дважды.

————

Интересная деталь из статьи: одной из причин взяться за это стали LLM-инструменты. Они генерируют код в стиле "среднего по больнице" обучающего корпуса — то есть с устаревшими паттернами. Порой они даже отрицают существование новых фич, когда их явно просят их использовать 👍

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

#go1_26 #go_official #tooling
go.dev Using go fix to modernize Go code - The Go Programming Language Go 1.26 includes a new implementation of go fix that can help you use more modern features of Go.
  • 🔥 51
  • ❤ 5
  • 👍 3
Post #330 6.92K
Пишем JSON-парсер с нуля на Go

https://sushantdhiman.dev/lets-write-a-json-parser-from-scratch/

Sushant Dhiman разбирает, как написать JSON-парсер с нуля — от токенизации до AST.

Статья небольшая, но хорошо структурированная. Два основных этапа:

Токенизатор — проходит по строке посимвольно и разбивает её на токены: {, "key", :, 123 и т.д. Отдельно обрабатываются строки (с учётом экранирования), числа, литералы true, false, null.

Парсер — принимает токены и строит AST. Каждый узел — отдельный тип (StringNode, ObjectNode, ArrayNode и т.д.), всё через рекурсивный parseValue.

В конце задачка: попробуй преобразовать AST в нативные Go-структуры и использовать их. Неплохо для закрепления.

————

Традиционно люблю статьи «напиши X с нуля» — они хорошо прокачивают понимание внутреннего устройства привычных инструментов. Джэйсоны мы гоняем каждый день, даже не задумываясь что там внутри, а внутри всё хитро и интересно 👍

Код несложный, читается легко, исходники на GitHub.

#article #diy #parsing #ast
  • 🔥 25
  • 👍 10
  • ❤ 5
Older posts →

About this channel

How can I read @golang_digest without a Telegram account?
TGViewer shows the public web preview Telegram publishes for Golang Дайджест: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does Golang Дайджест have?
Golang Дайджест (@golang_digest) has 13.4K subscribers on Telegram, refreshed roughly every 30 minutes.
Does Golang Дайджест know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →