PRO Go

🔨ошибки: почему всё выглядит просто… пока не начинаешь писать свой код После основ большинство думает, что ошибки — это что‑то второстепенное. Тип 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Практика

🏴‍☠️ После истории со строками следующая типичная ловушка — слайсы. На базовом уровне кажется, что это просто удобный список. Сделал копию, поменял один — ожидаешь, что второй останется прежним. Но в Go всё устроено иначе. 🤓 Слайс — это не сами данные. Это структура, которая указывает на участок массива: указатель, длина и ёмкость. Поэтому когда вы пишите: a := []int{1, 2, 3} b := a b[0] = 99 оба слайса показывают одно и то же изменение. a и b — разные переменные, но память у них общая. 🦄 Отсюда и все странности, которые ловят почти все: - меняешь один слайс — меняется другой; - append иногда создаёт новый массив, а иногда продолжает старый; - структура со слайсом ведёт себя «не так», когда ты её копируешь; - отладка превращается в расследование, кто на что ссылается. 🍾И дело не в том, что Go чудит)) Просто модель памяти слайсов не укладывается в голове, пока её не объяснишь себе правильно. Как только начинаешь мыслить не списками, а окнами в массив, всё становится предсказуемым. Появляется понимание, когда данные действительно копируются, а когда ты просто создаёшь ещё одну ссылку на те же байты. Это уже шаг за пределы базового уровня 💪 Тут начинается тот самый взрослый Go, где ты не просто пишешь код, а понимаешь, как он живёт в памяти ❤️

💻Иногда мы так увлекаемся работой, учёбой и постоянным движением вперёд, что забываем о самом простом — о том, что отдых тоже часть пути. Без пауз невозможно сохранять темп, оставаться в ресурсе и продолжать учиться с интересом, а не через силу. После плотной работы над курсом я наконец позволил себе немного выдохнуть. Провёл пару дней на природе, в компании друзей — и это оказалось именно тем, что нужно, чтобы перезагрузиться. На фото и видео — мой верный песель Рюк. Он почти всегда рядом, во всех приключениях, и, кажется, отдыхает лучше меня. Если вам зайдёт такой формат небольших личных постов, буду иногда делиться моментами из жизни. Всё-таки мы тут не только PRO Go, но и про людей, которые этот Go изучают❤️

🤓Почему строки в цикле начинают тормозить? Многие наверняка сталкивался с этим моментом. Пишешь простой цикл, добавляешь символы к строке — всё выглядит логично и безобидно: s := "" for i := 0; i < 10000; i++ { s = s + "a" } 🤡Но запускаешь программу — и она начинает работать заметно медленнее, чем ожидалось. Вроде бы ничего сложного, просто добавляю букву, а ощущение такое, будто Go делает что‑то лишнее. И он действительно делает. Строка — это не пластилин, который можно растянуть. Это скорее стеклянная плитка: к ней нельзя просто «приклеить» кусочек. Каждый раз, когда ты пишешь s = s + "a", создаётся новая строка, копируется туда старая, добавляется новый символ — и так на каждой итерации. 💪 На маленьких примерах это незаметно. Но как только строка становится длиннее, а операций — сотни или тысячи, программа начинает тратить всё больше времени на создание новых копий. И вот тут приходит понимание: строки — это не просто «текст в кавычках». У них есть своя цена, свои правила и свои подводные камни. И если их не учитывать, код начинает работать медленнее, чем должен. Это уже шаг за пределы базового уровня. Дальше начинается разговор о том, как работать со строками так, чтобы и код был понятным, и программа не задыхалась от лишних операций❤️

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

🔨Я сейчас работаю над новой темой для курса, и признаюсь — сам получаю огромное удовольствие от процесса. Это не просто очередная глава, а материал, который позволит вам заглянуть глубже в то, как устроены программы и что происходит в моменты, когда они ведут себя «не так, как ожидалось»🏴‍☠️ Пока не буду раскрывать все детали, но скажу одно: эта тема поможет вам почувствовать себя увереннее в роли разработчика и даст новые инструменты для работы. 😩Уже совсем скоро...

👴 Сегодня хочу предложить вам небольшой, но очень показательный пример. Казалось бы — три строки, обычная переменная. Но именно на таких мелочах чаще всего и спотыкаются даже опытные разработчики. Посмотрите на код и попробуйте определить, что он выведет. А главное — почему именно так 👇

Когда база Go уже позади… 🤓На базовом уровне всё кажется понятным: переменные, условия, циклы, строки, функции. Но как только начинаешь писать что‑то своё — возникают неожиданные трудности. 🧐 Ты склеиваешь строки в цикле, а программа начинает тормозить. Почему так? Потому что строки в Go неизменяемые, и каждое «плюс» создаёт новую копию. 🧐 Ты работаешь со слайсами, копируешь один в другой, а потом вдруг меняется исходный. Оказывается, слайсы делят общую память. 🧐 Ты пытаешься обработать ошибки, но их становится так много, что теряешься, где именно всё упало и как это правильно логировать. 🧐 Ты читаешь чужой код и видишь конструкции вроде defer, а сам никогда их не использовал. И думаешь: «А зачем это вообще нужно?» 🧐 Ты пишешь одинаковые функции для разных типов данных, копируешь один и тот же код по несколько раз, и всё равно чувствуешь, что это костыли. А потом смотришь чужой проект — и там всё сделано элегантно и коротко, но ты не понимаешь, как повторить. ❤️Если узнаёшь себя — это нормально. Эти вопросы появляются у всех, кто выходит за рамки «основ». И именно они показывают, что пора двигаться дальше. 👉👉 В следующих постах мы будем подробно разбирать такие ситуации, чтобы шаг за шагом превратить базовые знания в уверенный Go‑код.

👴Многие уже освоили базу Go, сделали первые шаги, но в какой‑то момент ловят себя на мысли: «Я выучил основы… но куда идти дальше?» 🔨Ты прошёл основы — и это действительно круто. Но дальше почти у всех появляется ощущение, что уверенности в коде всё равно нет. И дело обычно не в синтаксисе. Настоящие сложности начинаются, когда нужно: — собрать программу во что‑то цельное, — понять, как правильно работать с ошибками, — разобраться, почему типы ведут себя не так, как ожидаешь, — читать чужой код и понимать, почему он написан именно так, — писать идиоматично, а не просто «чтобы работало». ❤️Если узнаёшь себя — это абсолютно нормально. Такой этап проходит почти каждый, кто выходит за рамки «основ». Потому что база — это только буквы алфавита. А вот писать на языке — совсем другая история. В следующих постах я покажу, какие ошибки делают почти все после «основ» и почему именно они мешают двигаться дальше