en
Feedback
Thank Go!

Thank Go!

Open in Telegram

Неожиданный взгляд на язык программирования Golang. Конструктив от @mikeberezin с нотками сарказма от @nalgeon

Show more
1 297
Subscribers
No data24 hours
No data7 days
No data30 days
Posts Archive
Go 1.22 Вчера вышел Go 1.22 с интересными фичами: — Починили багу с замыканием счетчика цикла (большое дело!) — Цикл for range заработал по числам (прямо как в питоне) — Новый пакет для генерации случайных чисел math/rand/v2 — Роутинг с поддержкой переменных в http (наконец-то) Вместо сухих официальных релиз нотсов можно читать мои интерактивные с примерами.

Замыкание = гибкость Замыкания в Go используются повсеместно. Они позволяют универсально использовать один и тот же инструмент для работы в разных ситуациях. Вот, например, карта в пакете sync — sync.Map:

var m sync.Map
m.Store("alice", 11)
m.Store("bob", 12)
m.Store("cindy", 13)
Чтобы проитерироваться по карте, предусмотрен метод Range с такой сигнарутой:

Range(f func(key, value any) bool)
Но что делать, если мы хотим просуммировать все значения карты? Кажется, Range не дает такой возможности. Придется переписать все на питон. Ну или использовать замыкание:

total := 0
m.Range(func(key, value any) bool {
 total += value.(int)
 return true
})
Анонимная функция, переданная в Range, использует внешнюю переменную total как накопитель. Таким образом можно реализовать вообще любое поведение, не трогая сигнатуру Range. Полезная штука.

Как писать декораторы?
Anonymous voting

Декораторы Мой знакомый Редован поднял вопрос организации повторных попыток (retries) в Go. Это интересная тема, потому что ретраи — частный случай декораторов, которые на практике встречаются постоянно (мидлвари, транзакции или аудит тоже удобно делать через декораторы). В заметке он предлагает на выбор два подхода — рефлексию или дженерики. Мне не нравятся оба. Предпочитаю использовать замыкания, потому что с ними код проще и понятней. А вы что думаете? (опрос следует)

Значение ↔ указатель Если метод определен на значении, его можно вызывать и на указателе:

type Cat struct{}
func (c Cat) Meow() {}

val := Cat{}
val.Meow()

ptr := &Cat{}
ptr.Meow()
песочница И наоборот:

type Cat struct{}
func (c *Cat) Meow() {}

val := Cat{}
val.Meow()

ptr := &Cat{}
ptr.Meow()
песочница Дело усложняется, когда переменная имеет не конкретный тип, а интерфейсный. Работает почти всегда, кроме одной ситуации: метод определен на указателе, а интерфейсной переменной присваивают значение:

type Meower interface {
    Meow()
}

type Cat struct{}
func (c *Cat) Meow() {}

var ival Meower
ival = Cat{}
Здесь будет ошибка: Cat does not implement Meower (method Meow has pointer receiver) Подробности в go-вики

Многозадачность: примитивы синхронизации На курсе «Многозадачность в Go» вышли три новых урока! В них вы: — Досконально разберетесь с группами ожидания. — Научитесь ловить гонки и защищаться от них с помощью мьютексов. — Освоите семафоры, рандеву и барьеры. P.S. Помню, что обещал закончить курс еще в прошлом году, а он все никак. Если вы передумали проходить и хотите вернуть деньги — пишите в личку. https://stepik.org/a/133280

Так можно? go go func() {}()
Anonymous voting

Go 1.22: интерактивные заметки к релизу Release notes в Go традиционно сухие как прошлогодние сухари, а я люблю разбирать все новое на примерах. Поэтому решил оживить заметки к релизу 1.22 (выйдет в феврале) и добавил в них интерактивных примерчиков, чтобы вы могли попробовать новые фичи уже сейчас, прямо из браузера. https://antonz.org/go-1-22

Структура проекта в Go Любимое развлечение го-разработчиков — спорить о правильной структуре проекта. Вот и авторы Go наконец решили высказаться (очень вовремя, всего-то 6 лет прошло с момента появления модулей). Вкратце: — Для мелких проектов — плоская структура без каталогов. — Для более крупных — каталог internal с вложенными пакетами, публичные пакеты только при необходимости. — Каталог cmd — когда в проекте несколько команд. Что делать с прочими артефактами помимо кода (вроде документации и инфраструктуры) — скромно умолчали. https://go.dev/doc/modules/layout

2. Сигнатура Функция Clone должна работать со срезами любых типов (срезы чисел, строк, структур итп), а также с типами, образованными от срезов (когда мы пишем собственный тип, используя срез в качестве базового). То есть функция должна принимать тип S, который либо сам по себе срез ([]E), либо образован от среза (~[]E), а тип элемента среза при этом не важен (E any). На птичьем языке дженериков в Go получается S ~[]E, E any. Такие дела.

1. Копирование Можно было бы вернуть просто s[:]. Но это была бы поверхностная (shallow) копия — так скопируется срез, а массив под ним окажется тем же, что был. Поэтому изменяя копию среза, изменим и оригинальный массив. Конструкция s[:0] создает срез нулевой длины (zero-length), который все еще ссылается на оригинальный массив. А s[:0:0] создает срез нулевой вместимости (zero-capacity), который ссылается на новый (пустой) массив. Поэтому, когда мы добавляем к клону элементы оригинального s — они попадают в новый массив. Это и обеспечивает глубокое копирование.

Довольно простая функция: разбор Вот функция, простотой которой наслаждается Ян:
func Clone[S ~[]E, E any](s S) S {
    return append(s[:0:0], s...)
}
Она выполняет глубокое (deep) копирование среза s: клонирует не только сам срез, но и массив под ним (как вы помните, срез — это легковесная структура, которая сама по себе не содержит данных, а содержит ссылку на массив). Легкую оторопь тут могут вызвать два момента: само копирование и сигнатура функции. Разберем оба.

Простая или непростая?
Anonymous voting

Довольно простая функция Ян Ланс Тейлор (один из авторов Go) считает, что это довольно простая функция:
func Clone[S ~[]E, E any](s S) S {
    return append(s[:0:0], s...)
}
А вы как считаете? (опрос следует)

Довольно простая функция Ян Ланс Тейлор (один из авторов Go) считает, что это довольно простая функция. А вы как считаете? ```func Clone[S ~[]E, E any](s S) S { return append(s[:0:0], s...) }``` https://go.dev/blog/deconstructing-type-parameters
Anonymous voting

Go ♡ SQLite Тут добрый человек Riyaz Ali сделал Go-модуль с набором полезных расширений SQLite: — кодирование/декодирование — динамический SQL — работа с файлами — текстовые функции — IP адреса — мат. статистика — UUID — CSV Если вы, как и я, неравнодушны SQLite — рекомендую! https://github.com/riyaz-ali/sqlean.go P.S. Небольшой анонс, чтобы два раза не писать. В сентябре возвращаюсь к курсу «Многозадачность в Go», так что если вдруг переживали за его судьбу — не переживайте ツ

Пишем менеджер пакетов на Go Как-то так вышло, что я написал менеджер пакетов на Go. А поскольку задачка оказалась интересной — подробно описал архитектуру и детали реализации. Так что если вам интересно посмотреть, как темы курса Thank Go! применяются на практике — рекомендую. Вот какие темы нашли применение в проекте: 1) Все из модуля «Основы», от базовых типов до интерфейсов и ошибок. 2) Пакеты, модули и тесты. 3) Работа с текстом. 4) Работа с файлами. 5) JSON. 6) HTTP. Исходники тоже доступны, разумеется. А еще там комментарии и тесты на каждый файл, благодать. Когда еще такое встретишь! https://antonz.ru/writing-package-manager/

📝 Узнаем больше о Go разработке Ребята из DevCrowd (а они же основатели классного подкаста Podlodka) проводят исследование Go-разработчиков: - Какие навыки для go-разработчиков самые важные - Какие инструменты используются в работе - Как попадают в профессию и куда из нее уходят - Полезные для развития каналы, курсы и книги Результаты будут в открытом доступе, а значит это отличный шанс узнать больше об индустрии. Опрос довольно большой, но интересный. Мне потребовалось 10 минут, чтобы вдумчиво его пройти. Давайте поучаствуем! Пройти опрос

Наш отдел дата-аналитики трудился не покладая рук, и подготовил ИНФОГРАФИКУ.
Наш отдел дата-аналитики трудился не покладая рук, и подготовил ИНФОГРАФИКУ.

Пока в комментариях идет битва за clear, отвечу на вопрос из посткриптума: Зачем делать встроенные min и max вместо дженерик-функций Ответ существует, но вам он не понравится. Процитирую авторов языка (с сокращениями): We have gone back and forth a few times on this proposal about min/max being builtins vs being in package cmp. There are good arguments on both sides. On the one hand, min and max are fundamental arithmetic operations much like addition, which justifies making them builtins. On the other hand, we have generics now and it would make sense to use generics to write library code rather than make them builtins. Even among the active Go language designers, our own personal intuitions differ on this. полный ответ 🤷‍♀️