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