Go tests

👣 Go давно починил старую ловушку с замыканиями в цикле. Но concurrency всё ещё может кусаться. Что не так с этим кодом? package main import ( "fmt" "sync" ) func main() { nums := []int{1, 2, 3, 4} var wg sync.WaitGroup result := make([]int, 0, len(nums)) for i, n := range nums { wg.Go(func() { result = append(result, i*n) }) } wg.Wait() fmt.Println(result) } На первый взгляд всё нормально. i и n уже не общие для всех итераций. В современном Go каждая итерация получает свои переменные, поэтому старого бага с замыканием тут нет. Проблема в другом месте. `append` меняет slice header и может трогать общий backing array. Несколько горутин делают это одновременно. Значит, здесь data race, даже если loop variables теперь безопасные. Правильный вариант: ```go id="9f32ws" package main import ( "fmt" "sync" ) func main() { nums := []int{1, 2, 3, 4} var wg sync.WaitGroup result := make([]int, len(nums)) for i, n := range nums { wg.Go(func() { result[i] = i * n }) } wg.Wait() fmt.Println(result) } ``` Теперь каждая горутина пишет в свой индекс. Без mutex. Без channel. Без лишнего копирования переменных. Хороший тест на то, понимаешь ли ты Go после 1.22, а не просто помнишь старую страшилку про closures.

🔍Тестовое собеседование с Go Senior с опытом работы в Яндексе, EPAM и Uzum в этот четверг 16 июля(в четверг!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Go-разработчика. Как это будет: 📂 Маруф Караев, Senior в европйской компании, ex-Uzum, ex-Яндекс, ex-EPAM будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Маруф будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Маруфу Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Go-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_go_bot Реклама. О рекламодателе.

👣 Golang-задача с подвохом Версия: Go 1.23+ Что выведет код? package main import "fmt" func numbers(yield func(int) bool) { defer fmt.Println("iterator: defer") for i := 0; i < 5; i++ { if !yield(i) { fmt.Println("iterator: stopped") return } fmt.Println("iterator: after yield", i) } } func main() { for n := range numbers { fmt.Println("main:", n) if n == 2 { break } } fmt.Println("main: done") } Многие ждут, что после break итератор просто мгновенно исчезнет. Но в Go 1.23 появился range по функции. Под капотом yield возвращает false, если внешний цикл остановился через break. Ответ: ```txt id="5glpxa" main: 0 iterator: after yield 0 main: 1 iterator: after yield 1 main: 2 iterator: stopped iterator: defer main: done ``` Подвох в том, что `break` происходит во внешнем цикле, но функция-итератор получает сигнал остановки через `yield`. Если не проверить `!yield(i)`, можно продолжить работу после того, как потребитель уже вышел из цикла.

Что выведет код?

❓ Почему код падает и как это исправить Функция должна заполнить срез и мапу, но сейчас она падает с panic. В чём проблема? func fillData(s []int, m map[string]int) { // Добавляем в срез s = append(s, 10, 20, 30) // Добавляем в мапу m["count"] = len(s) m["total"] = 60 fmt.Println("Срез:", s) fmt.Println("Мапа:", m) } func main() { fillData(nil, nil) } 💡 Подсказка: срез и мапа ведут себя по-разному append к nil срезу работает нормально запись в nil map → panic 🔥 В чём ошибка m не инициализирована → это nil map в неё нельзя записывать значения

Хитрая Go-задача: package main import "fmt" type uint128 struct { Hi uint64 Lo uint64 } func f(φ uint128, β int) uint32 { return uint32(φ.Hi >> (63 - β)) } func main() { x := uint128{Hi: 0x8000000000000001} fmt.Println(f(x, 0)) fmt.Println(f(x, 1)) fmt.Println(f(x, 63)) } Вопросы: Что выведет код? Что будет при β = 64? Можно ли объявить одновременно beta и β? Ожидаемый ответ: 1 2 1 Подвох: сдвиг зависит от β возможен отрицательный shift обрезание до uint32 beta и β - разные переменные • Вам нужно понять, как работает сдвиг вправо заметить, что в конце результат режется до uint32 • увидеть, что при β = 64 получится отрицательный сдвиг: 63 - 64 = -1 и ещё понять, что beta и β в Go - это разные имена переменных То есть с виду задача про один shift, а на деле она проверяет сразу несколько знаний. Запустить код: https://go.dev/play/ Полезные ресурсы Go 🚀Max @golangtests

👣 Задача: что выведет программа? package main import "fmt" func main() { for i := 0; i < 3; i++ { defer fmt.Println(i) } for i := 0; i < 3; i++ { defer func() { fmt.Println(i) }() } for i := 0; i < 3; i++ { i := i defer func() { fmt.Println(i) }() } } Ответ: https://go.dev/play/p/pntndQy2jzo

🧠 Хитрая Go-задача про интерфейсы и память (x64) Код: package main import ( "fmt" "unsafe" ) type Foo struct { A int64 } type IFoo interface { Get() int64 } func (f Foo) Get() int64 { return f.A } func main() { var a int64 = 10 var s Foo = Foo{A: 42} var i IFoo = s fmt.Println(unsafe.Sizeof(a)) fmt.Println(unsafe.Sizeof(s)) fmt.Println(unsafe.Sizeof(i)) } Вопросы • Сколько байт занимает a на x64? • Сколько байт занимает s? • Сколько байт занимает i? • Почему размер i не равен размеру Foo? • Что реально хранится внутри interface{} в Go? Разберём по шагам, как это работает в Go на x64. Код: ```go var a int64 = 10 var s Foo = Foo{A: 42} var i IFoo = s ``` 1) Размер a unsafe.Sizeof(a) ```go int64 = 8 байт ``` На x64: a = 8 байт 2) Размер s ```go type Foo struct { A int64 }``` В структуре одно поле int64. ```go s = 8 байт ``` 3) Размер интерфейса i ```go var i IFoo = s unsafe.Sizeof(i) ```go На x64: ```go i = 16 байт``` Запустить код: https://go.dev/play/p/NLIG3q-jFc9

🔥 PrimeView - реальная производительность языков без маркетинга https://plummerssoftwarellc.github.io/PrimeView/report PrimeView - это живой бенчмарк, который сравнивает языки программирования на одной задаче: генерация простых чисел. Без синтетических тестов. Без “идеальных условий”. Только: * один алгоритм * одинаковые правила * реальные оптимизации от разработчиков Что показывают результаты: * C и C++ стабильно в лидерах * Rust и Zig уверенно конкурируют с нативным кодом * Go показывает сильные результаты при грамотной оптимизации * разница между реализациями внутри одного языка часто больше, чем между языками Ключевой инсайт: Производительность определяет не язык. Производительность определяет инженер. SIMD, работа с памятью, кэш-локальность и битовые оптимизации дают больший эффект, чем выбор технологии. plummerssoftwarellc.github.io/PrimeView/report

В Go nil - это не просто «пусто». Иногда это причина самых странных багов в продакшене. nil в Go - это не одно значение, а множество разных nil. 1. Interface и nil — ловушка var err error = nil fmt.Println(err == nil) // true var e *MyError = nil var err error = e fmt.Println(err == nil) // false (!) Почему так? Интерфейс в Go хранит: • тип • значение В этом случае: • тип = *MyError • значение = nil Интерфейс не nil, потому что тип задан. Именно так появляются ошибки вида: if err != nil срабатывает но внутри на самом деле nil 2. Typed nil vs untyped nil var p *int = nil var s []int = nil var m map[string]int = nil Все они nil, но разных типов. И Go сравнивает не только значение, но и тип. 3. Panic из-за nil внутри interface type User struct{} func (u *User) Name() string { return "John" } var u *User = nil var i interface{} = u i.(*User).Name() // panic Интерфейс не nil → метод вызывается → внутри nil → panic. 4. Частый баг с error Плохой код: func do() error { var e *MyError = nil return e } Правильно: func do() error { if somethingWrong { return &MyError{} } return nil } Главное правило Если работаешь с interface: • всегда проверяй, что возвращаешь чистый nil помни: interface != nil, если внутри typed nil https://sushantdhiman.dev/nil-in-go-is-not-what-you-think/