Найти в Дзене
PRO Go для продвинутых — полностью готов.
Последние посты были не просто отдельными заметками. Это были небольшие фрагменты из нового курса PRO Go для продвинутых. И да — курс полностью готов. Я вложил в него много времени, сил и энергии, чтобы получился спокойный, структурный и по‑настоящему продвинутый материал...
5 дней назад
🤓generics, когда понимаешь, что копипастить — это не путь
😩 Пишешь одинаковые функции для разных типов данных, копируешь один и тот же код по несколько раз, и всё равно чувствуешь, что это костыли. А потом открываешь чужой проект — и там всё элегантно, коротко, аккуратно. И ты такой: «Ну как? Как он это сделал?» Как выглядит боль Ты начинаешь с простого: func SumInt(a, b int) int { return a + b } func SumFloat(a, b float64) float64 { return a + b } 🤡И вроде всё нормально...
1 неделю назад
defer: штука, которую сначала не понимаешь
Ты читаешь чужой код и видишь defer. А сам никогда не использовал. И думаешь: А зачем это вообще нужно? Пока всё просто — функции короткие, ошибок мало, ресурсы не требуют закрытия. Но потом появляется реальный код — с кучей проверок, return в середине, и вдруг оказывается, что ты забыл что‑то сделать перед выходом. Как выглядит боль: func calc() (int, error) { if err := check(); err != nil { return 0, err } fmt.Println("start") if somethingWrong { return 0, fmt.Errorf("bad input") } fmt.Println("finish")...
2 недели назад
🔨ошибки: почему всё выглядит просто… пока не начинаешь писать свой код После основ большинство думает, что ошибки — это что‑то второстепенное. Тип error есть, где‑то он возвращается — и ладно. Но как только пишешь свой первый проект, всё резко меняется. Например, у тебя есть функция, которая что‑то делает: func divide(a, b int) (int, error) { if b == 0 { return 0, errors.New("bad input") } return a / b, nil } А в main ты видишь: result, err := divide(10, 0) if err != nil { fmt.Println("failed") } И всё. failed Что упало? Где? Почему? Что за bad input? Какой именно вход? Где искать проблему? Это реальная боль после основ: ошибки есть, но пользы от них ноль. Как сделать минимально лучше — и сразу полезнее func divide(a, b int) (int, error) { if b == 0 { return 0, fmt.Errorf("divide: b=0 is invalid") } return a / b, nil } func main() { result, err := divide(10, 0) if err != nil { fmt.Println("error:", err) return } fmt.Println(result) } Теперь вывод будет таким: error: divide: b=0 is invalid И сразу понятно: — что делали → делили числа — где ошибка → в функции divide — почему → b = 0 Минимальное изменение — а ясности в разы больше❤️ #GoПрактика
2 недели назад
🏴‍☠️ После истории со строками следующая типичная ловушка — слайсы. На базовом уровне кажется, что это просто удобный список. Сделал копию, поменял один — ожидаешь, что второй останется прежним. Но в Go всё устроено иначе. 🤓 Слайс — это не сами данные. Это структура, которая указывает на участок массива: указатель, длина и ёмкость. Поэтому когда вы пишите: a := []int{1, 2, 3} b := a b[0] = 99 оба слайса показывают одно и то же изменение. a и b — разные переменные, но память у них общая. 🦄 Отсюда и все странности, которые ловят почти все: - меняешь один слайс — меняется другой; - append иногда создаёт новый массив, а иногда продолжает старый; - структура со слайсом ведёт себя «не так», когда ты её копируешь; - отладка превращается в расследование, кто на что ссылается. 🍾И дело не в том, что Go чудит)) Просто модель памяти слайсов не укладывается в голове, пока её не объяснишь себе правильно. Как только начинаешь мыслить не списками, а окнами в массив, всё становится предсказуемым. Появляется понимание, когда данные действительно копируются, а когда ты просто создаёшь ещё одну ссылку на те же байты. Это уже шаг за пределы базового уровня 💪 Тут начинается тот самый взрослый Go, где ты не просто пишешь код, а понимаешь, как он живёт в памяти ❤️
3 недели назад
Если нравится — подпишитесь
Так вы не пропустите новые публикации этого канала