🌐 Похоже, что девопсов заменил ИИ

15 октября упал YouTube. Google починили всё за два часа, но причину не назвали.

20 октября остановился Amazon Web Services на 15 часов. Вместе с AWS полегли Docker, Postman, Snapchat, Roblox, Duolingo, Reddit и десятки других сервисов. Проблема была в DNS — системе, которая переводит адреса сайтов в IP-адреса для компьютеров.

Админу пришлось использовать инсомнию вместо постмана несколько часов.

💬 Коснулись сбои вас? Пришлось адаптироваться или просто ждали, когда пожар потушат 👇

Чтобы ваши приложения не падали нужно строить надёжную инфраструктуру. В этом поможет наш интенсив по архитектуре. Успевайте до конца октября, ведь там скидка закончится!

🐸 Библиотека Go-разработчика

#GoTalk

🔍 Как проверить тип переменной в Go во время выполнения

В Go есть несколько способов узнать тип переменной в рантайме. Разберём каждый подробно.

1️⃣ Type Assertion

Самый простой способ для проверки конкретного типа:

var i interface{} = "hello"

// Проверка с обработкой ошибки
s, ok := i.(string)
if ok {
    fmt.Printf("Это строка: %s\n", s)
} else {
    fmt.Println("Это не строка")
}

Когда использовать: когда нужно проверить один конкретный тип.

2️⃣ Type Switch

Элегантный способ для проверки нескольких типов:

func checkType(i interface{}) {
    switch v := i.(type) {
    case int:
        fmt.Printf("Целое число: %d\n", v)
    case string:
        fmt.Printf("Строка: %s\n", v)
    case bool:
        fmt.Printf("Булево: %t\n", v)
    default:
        fmt.Printf("Неизвестный тип: %T\n", v)
    }
}

Когда использовать: когда нужно обработать разные типы по-разному.

3️⃣ Пакет reflect

Для продвинутой работы с типами:

import "reflect"

var x float64 = 3.14

// Получить тип
t := reflect.TypeOf(x)
fmt.Println("Тип:", t) // float64

// Получить значение
v := reflect.ValueOf(x)
fmt.Println("Тип через Value:", v.Type())
fmt.Println("Kind:", v.Kind()) // float64

4️⃣ Форматирование %T

Быстрый способ для вывода типа:

var x = 42
fmt.Printf("Тип переменной: %T\n", x) // int

Когда использовать: для быстрой отладки.

Best practises:

• Избегайте reflect там, где можно обойтись type assertion или type switch

• Используйте type switch вместо цепочки type assertion

• Проверяйте ok при type assertion, чтобы избежать паники

• Предпочитайте интерфейсы вместо проверки конкретных типов

🐸 Библиотека Go-разработчика

#GoDeep

❌ 14 вопросов, после которых вам не перезвонят

Разбираем 14 вопросов, которые лучше не задавать на собеседовании: что не так с каждым из них и как переформулировать, чтобы получить нужную информацию без риска для репутации.

➡️ Прочитать статью

🐸 Библиотека Go-разработчика

✏️ Filter, Map и Reduce для слайсов

В Go нет встроенных функций для работы с коллекциями, которые есть в других языках. Хотите отфильтровать слайс или применить функцию к каждому элементу? Придется писать цикл вручную.

Библиотека pie решает эту проблему. Она добавляет привычные функции для работы со слайсами и мапами: Filter, Map, Reduce, Find и десятки других.

Примеры:

names := pie.FilterNot([]string{"Bob", "Sally", "John", "Jane"},
    func(name string) bool {
        return strings.HasPrefix(name, "J")
    })
// ["Bob", "Sally"]

name := pie.Of([]string{"Bob", "Sally", "John", "Jane"}).
    FilterNot(func(name string) bool {
        return strings.HasPrefix(name, "J")
    }).
    Map(strings.ToUpper).
    Last()
// "SALLY"

Для чейнинга есть три варианта обёрток, в зависимости от типа данных:

• pie.Of — работает с любыми типами, но набор функций ограничен
• pie.OfOrdered — для чисел и строк, функций больше
• pie.OfNumeric — только числа, доступны все функции включая математические операции

Требует Go 1.18+ из-за дженериков. Если работаете на более старой версии, есть v1 библиотеки без дженериков.

➡️ Попробовать либу

Своё приложение или либа = опыт. А опыт просто так не получить, но мы поможем.

🐸 Библиотека Go-разработчика

#GoToProduction

👨‍💻 Хвастайтесь своими машинками

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

Админ недавно взял себе RTX3060. Да, не самая новая железка, но зато какая гордость!

💬 Похвастайтесь какие у вас комплектующие в комментариях 👇

🐸 Библиотека Go-разработчика

#GoTalk

🐸 Библиотека Go-разработчика

#GoGiggle

🎧 Короткие новости Go

Иногда самые полезные вещи — самые короткие. Как команды Unix: ls, cd, rm — всё по делу, ничего лишнего. Недавний эпизод подкаста Cup o' Go взял этот принцип на вооружение и выдал порцию Go-новостей без воды.

➡️ Послушать подкаст

Кратко про наши курсы: скидки до конца октября!

🐸 Библиотека Go-разработчика

#GoLive

🖥 Почему данные сбегают

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

Стек: быстрый и дисциплинированный

Представьте стопку тарелок. Положили одну, сверху ещё одну, потом ещё. Снимаете тарелки строго сверху — это и есть принцип работы стека. Последним пришёл — первым ушёл, то есть LIFO.

В стеке хранятся локальные переменные функций и информация о вызовах. Когда вызываете функцию, для неё создаётся стековый фрейм — туда помещаются все её параметры и локальные переменные.

Хип: гибкий и непредсказуемый

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

В хипе размещаются объекты, которые должны жить дольше одной функции, или размер которых заранее неизвестен. В языках с ручным управлением памятью вы сами очищаете память. В языках со сборщиком мусора тот сам решает, когда удалять неиспользуемые объекты.

Практический пример:

func createUser(name string) *User {
    count := 42  // в стеке
    user := &User{Name: name}  // escape to heap
    return user
}

func processData() {
    data := make([]byte, 100)  // скорее всего в стеке
    // ... используем data только внутри функции
}

Переменная count останется в стеке и исчезнет при выходе из функции. Структура User уйдёт в хип, потому что мы возвращаем указатель на неё — компилятор видит, что данные сбегают из функции.

Слайс data может остаться в стеке, если компилятор убедится, что он не покидает функцию и его размер разумен.

Как Go решает, что куда положить

Go использует escape analysis во время компиляции. Компилятор анализирует код и решает, может ли переменная безопасно жить в стеке:

// Останется в стеке
func stackAlloc() {
    x := 42
    fmt.Println(x)
}

// Уйдёт в хип
func heapAlloc() *int {
    x := 42
    return &x  // escape: возвращаем указатель
}

Можете проверить сами:

go build -gcflags="-m" your_file.go

Компилятор покажет, какие переменные сбегают в хип и почему.

В Go вы не управляете памятью вручную — компилятор и runtime делают это за вас. Но понимание разницы между стеком и хипом помогает писать эффективный код.

🐸 Библиотека Go-разработчика

#GoDeep

🖇 Человекопонятные адреса для локальных серверов

Caddy — это реверс-прокси, который превращает ваши localhost:8081, localhost:9000 в красивые myapp.localhost, blog.localhost.

Предположим, у вас есть локальный сервер на порту 9000. После установки Caddy выполните всего одну команду:

caddy reverse-proxy --from myserver.localhost --to :9000

Теперь ваш сервер доступен по адресу https://myserver.localhost. Бонус: Caddy автоматически предоставляет локальные TLS-сертификаты

Также можно создать Caddyfile с конфигурацией:

myapp.localhost {
    reverse_proxy :9000
}

myhugoblog.localhost {
    reverse_proxy :1313
}

Пусть все ваши проекты будут доступны по человекопонятным адресам вместо путаницы с портами.

➡️ Репозиторий Caddy

🐸 Библиотека Go-разработчика

#GoToProduction

🐸 Библиотека Go-разработчика

#GoGiggle

⚡️ Как не убить производительность работой со строками

Работа со строками в Go может незаметно съесть всю память и убить производительность. Разбираем, как избежать ненужных аллокаций и ускорить код в разы.

В Go строки неизменяемые. Каждое изменение строки = новая аллокация в памяти.

Пример проблемного кода:

func BuildURL(host, path, query string) string {
    url := "https://"     // Аллокация #1
    url += host           // Аллокация #2
    url += path           // Аллокация #3
    url += "?" + query    // Аллокация #4
    return url
}

Решение 1: strings.Builder с предвыделением

Всегда используйте strings.Builder вместо конкатенации через +:

// N аллокаций
func ConcatWrong(parts []string) string {
    result := ""
    for _, p := range parts {
        result += p  // Новая аллокация на каждой итерации!
    }
    return result
}

// 1 аллокация
func ConcatRight(parts []string) string {
    var b strings.Builder
    
    // Посчитать нужный размер заранее
    totalLen := 0
    for _, p := range parts {
        totalLen += len(p)
    }
    b.Grow(totalLen)  // Выделить память один раз
    
    // Писать без аллокаций
    for _, p := range parts {
        b.WriteString(p)
    }
    return b.String()
}

Решение 2: Переиспользование буферов через sync.Pool

Даже strings.Builder делает аллокацию при вызове .String(). Чтобы избежать этого, переиспользуйте буферы:

var bufferPool = sync.Pool{
    New: func() interface{} {
        b := make([]byte, 0, 4096)  // 4KB буфер
        return &b
    },
}

func GetBuffer() *[]byte {
    return bufferPool.Get().(*[]byte)
}

func PutBuffer(b *[]byte) {
    *b = (*b)[:0]  // Сбросить длину, сохранить capacity
    bufferPool.Put(b)
}

func BuildString(parts []string) string {
    buf := GetBuffer()
    defer PutBuffer(buf)
    
    for _, p := range parts {
        *buf = append(*buf, p...)
    }
    
    // Zero-copy конвертация (Go 1.20+)
    return unsafe.String(unsafe.SliceData(*buf), len(*buf))
}

Решение 3: Стековые массивы для предсказуемых размеров

Для строк фиксированного размера используйте массивы на стеке:

// heap allocation
func FormatIPWrong(a, b, c, d byte) string {
    return fmt.Sprintf("%d.%d.%d.%d", a, b, c, d)
}

// stack allocation
func FormatIPRight(a, b, c, d byte) string {
    var buf [15]byte  // Макс длина IP: "255.255.255.255"
    i := 0
    
    i += writeUint8(buf[i:], a)
    buf[i] = '.'
    i++
    i += writeUint8(buf[i:], b)
    buf[i] = '.'
    i++
    i += writeUint8(buf[i:], c)
    buf[i] = '.'
    i++
    i += writeUint8(buf[i:], d)
    
    return string(buf[:i])
}

func writeUint8(buf []byte, v byte) int {
    if v >= 100 {
        buf[0] = '0' + v/100
        buf[1] = '0' + (v/10)%10
        buf[2] = '0' + v%10
        return 3
    } else if v >= 10 {
        buf[0] = '0' + v/10
        buf[1] = '0' + v%10
        return 2
    }
    buf[0] = '0' + v
    return 1
}

Решение 4: String Interning для дедупликации

Если у вас много одинаковых строк (например, в логах), используйте string interning:

type Interner struct {
    mu   sync.RWMutex
    pool map[string]string
}

func (i *Interner) Intern(s string) string {
    i.mu.RLock()
    if cached, ok := i.pool[s]; ok {
        i.mu.RUnlock()
        return cached
    }
    i.mu.RUnlock()
    
    i.mu.Lock()
    defer i.mu.Unlock()
    
    if cached, ok := i.pool[s]; ok {
        return cached
    }
    
    i.pool[s] = s
    return s
}

// Использование
var logLevelInterner = NewInterner()

func ProcessLog(level string) {
    level = logLevelInterner.Intern(level)
    // Теперь все "info" указывают на одну строку в памяти
}

Как профилировать:

# Посмотреть аллокации памяти
go test -bench=. -benchmem

# Проверить escape analysis
go build -gcflags="-m" 2>&1 | grep "string"

# Memory profiling
go test -bench=. -memprofile=mem.prof
go tool pprof -alloc_space mem.prof

Главное правило: всегда измеряйте! Не доверяйте интуиции — используйте бенчмарки.

🐸 Библиотека Go-разработчика

#GoDeep

✏️ LeetCode-интервью: почему опытные разработчики их проваливают

Инженер с 10+ годами опыта провалил интервью, потому что не смог за 45 минут решить задачу на динамическое программирование, которую не видел с универа.

Есть аргументы за решение задач не собеседовании и против.

Никто не будет решать задачки с литкода на работе, но и код с O(n²) вместо O(n log n) сто процентов положит прод под нагрузкой.

Админ один раз перенервничал и забыл как найти середину отрезка на плоскости. Это полностью заруинило ему алгоритмическую секцию.

💬 Как вы думаете — задачи на собесе это ту мач или имеют место быть? Ждём ваше мнение в комментариях 👇

🐸 Библиотека Go-разработчика

#GoTalk