💬 Когда pointer ресивер предпочтительнее использовать, чем value ресивер в Go?

Первая причина — чтобы метод мог изменить значение, на которое указывает его ресивер.

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

В примере ниже, оба метода Scale и Abs имеют тип ресивера *Vertex, хотя метод Abs не должен изменять свой ресивер.

package main

import (
 "fmt"
 "math"
)

type Vertex struct {
 X, Y float64
}

func (v *Vertex) Scale(f float64) {
 v.X = v.X * f
 v.Y = v.Y * f
}

func (v *Vertex) Abs() float64 {
 return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

func main() {
 v := &Vertex{3, 4}
 fmt.Printf("Before scaling: %+v, Abs: %v\n", v, v.Abs())
 v.Scale(5)
 fmt.Printf("After scaling: %+v, Abs: %v\n", v, v.Abs())
}

В общем случае, все методы для данного типа должны использовать либо только pointer ресивер, либо только value ресивер, чтобы избежать путаницы и обеспечить согласованность.

⚡️Proglib запускает канал про ИИ для генерации звука

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

⭐️генерация голоса и музыки
⭐️замена и перевод речи
⭐️распознавание звуков

👉Подписывайтесь!

💬 Интерфейс и any (interface{}) в Go — это одно и то же? Объясните простыми словами.

Нет, это не одно и то же. Интерфейсы определяют контракты для типов, которые их реализуют.

any — это псевдоним для пустого интерфейса interface{}. Пустой интерфейс interface{} может содержать значение любого типа, поскольку он не требует реализации никаких методов.

💬 Почему crypto/rand в некоторых кейсах предпочтительнее использовать вместо math/rand для генерации ключей в Go?

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

Пакет math/rand отлично подходит для генерации псевдослучайных чисел. Но у этого метода есть серьезный недостаток: если кто-то узнает, как генерируются числа (начальное значение seed), он сможет предсказать будущие числа.

import "math/rand"

func Key() string {
    // rand.Seed(time.Now().UnixNano()) // deprecated
    r := rand.New(rand.NewSource(time.Now().UnixNano()))

    buf := make([]byte, 16)

    for i := range buf {
        buf[i] = byte(r.Intn(256))
    }

    return fmt.Sprintf("%x", buf)
}

Даже если мы инициализируем генератор с чем-то вроде текущего времени, уровень непредсказуемости или энтропии будет довольно низким. Это происходит потому, что вариации времени между запусками незначительны.

С другой стороны, crypto/rand предлагает лучшее решение для генерации чисел, которые криптографически безопасны. Эта библиотека разработана для полной непредсказуемости, используя источники случайности, предоставляемые ОС, которые обычно гораздо сложнее предсказать.

import "crypto/rand"

func Key() string {
    buf := make([]byte, 16)

    _, err := rand.Read(buf)
    if err != nil {
        panic(err)
    }

    return fmt.Sprintf("%x", buf)
}

Использование crypto/rand особенно необходимо для операций, таких как шифрование, аутентификация или любой другой контекст, где безопасность имеет критическое значение.

Опять же, если мы генерируем ключи для целей, не связанных с безопасностью, math/rand вполне подойдет.

💬 Когда процесс в Linux может не реагировать на SIGKILL?

🔸 Когда процесс является зомби-процессом, который уже завершился, но не освободил свои ресурсы. Зомби не может принимать сигналы и ожидает, что его родительский процесс считает его статус с помощью системного вызова wait.
🔸 Когда процесс находится в состоянии блокировки. Он выполняет неотменяемый системный вызов, такой как ожидание ввода-вывода или другого события, которое не наступило. Процесс не может завершиться, пока операционная система не вернет его в нормальное состояние.
🔸 Когда процесс является процессом init. Он не получает от ОС сигналов, которые не хочет обрабатывать. Процесс init может игнорировать SIGKILL, так как он является особым процессом, который отвечает за запуск и завершение других процессов.

💬 Что такое статическая компиляция/линковка и в чем ее особенности?

Линковка (или компоновка) — это последний этап сборки программы, когда все скомпилированные части кода и библиотеки объединяются в один исполняемый файл. Статически слинкованный исполняемый файл не зависит от наличия других библиотек в системе во время своей работы, так как все необходимые библиотеки встраиваются в итоговый бинарный файл.

Для включения статической компиляции/линковки в Go необходимо установить переменную окружения CGO_ENABLED=0 при сборке (т. е. `CGO_ENABLED=0 go build ...`). Это гарантирует, что все внешние библиотеки, от которых зависит выполнение кода, будут встроены в итоговый бинарный файл. Полученный бинарный файл можно использовать, например, в Docker-образе, основанном на scratch (т.е. не содержащем никаких файлов, чистая файловая система).

Однако, это накладывает некоторые ограничения и привносит особенности, которые необходимо помнить:

1. C-код будет недоступен. Некоторые модули из стандартной библиотеки Go зависят от C-кода, но они не являются критичными.
2. Не будет использоваться системный DNS-резольвер: Go будет использовать собственный DNS-резолвер.
3. Проблемы с проверкой x.509 сертификатов на MacOS: в некоторых случаях проверка x.509 сертификатов может не работать корректно.

Если итоговый бинарный файл планируется использовать в Docker-образе scratch, то также следует учитывать:

1. Корневые SSL/TLS сертификаты: для осуществления HTTP запросов по протоколу HTTPS нашему приложению, в образ нужно будет поместить корневые SSL/TLS сертификаты в /etc/ssl/certs.
2. Файл временной зоны: для корректной работы с датой и временем необходимо добавить файл временной зоны в /etc/timezone.

💬 Что значит work sharing и work stealing в контексте планировщика в Go?

Задача планировщика в Go — распределять запущенные горутины между потоками ОС, которые могут исполняться одним или большим количеством процессоров. В многопоточных вычислениях возникли две парадигмы в планировании: делиться задачами (work sharing) и красть задачи (work stealing).

🔹 Work-sharing: когда процессор генерирует новые потоки, он пытается мигрировать их на другие процессоры, в надежде, что они попадут к простаивающему или недостаточно нагруженному процессору.
🔹 Work-stealing: недостаточно нагруженный процессор активно ищет потоки других процессоров и «крадет» некоторые из них.

Миграция потоков происходит реже при work stealing подходе, чем при work sharing. Когда все процессоры заняты, потоки не мигрируют. Как только появляется простаивающий процессор, рассматривается вариант миграции.

В Go начиная с версии 1.1 планировщик реализован по схеме work stealing.

🧑‍💻 Статьи для IT: как объяснять и распространять значимые идеи

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

Что: семь модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций.

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

👉Материалы регулярно дополняются, обновляются и корректируются. А еще мы отвечаем на все учебные вопросы в комментариях курса.

💬 Каковы основные отличия HTTP/3 от предыдущих версий HTTP (HTTP/1.1 и HTTP/2)?

HTTP/3 отличается от HTTP/1.1 и HTTP/2 несколькими ключевыми аспектами:

1. Транспортный протокол:

🔸 HTTP/1.1 и HTTP/2: оба используют TCP для передачи данных. TCP обеспечивает надежную доставку, но может страдать от задержек при потере пакетов из-за необходимости восстановления всего потока данных.
🔸 HTTP/3: использует протокол QUIC (Quick UDP Internet Connections), который построен поверх UDP. QUIC обеспечивает быструю и надежную доставку данных с меньшими задержками, т. к. каждый пакет обрабатывается независимо.

2. Установка соединения:
🔸 HTTP/1.1 и HTTP/2: для установки соединения требуется несколько этапов, включая установку TCP соединения и выполнение TLS рукопожатия.
🔸 HTTP/3: снижает задержки при установке соединения за счет одновременного выполнения рукопожатия QUIC и TLS, что позволяет начать передачу данных быстрее.

3. Управление задержками и потерями пакетов:
🔸 HTTP/1.1 и HTTP/2: при потере пакета в TCP соединении, весь поток данных останавливается до тех пор, пока потерянный пакет не будет восстановлен, что увеличивает задержки.
🔸 HTTP/3: QUIC минимизирует влияние потери пакетов, т. к. каждый поток данных внутри соединения обрабатывается независимо. Это означает, что потеря одного пакета не блокирует другие потоки данных.

4. Мультиплексирование:
🔸 HTTP/1.1: не поддерживает мультиплексирование, каждый запрос требует отдельного соединения.
🔸 HTTP/2: поддерживает мультиплексирование, позволяя отправлять несколько запросов и ответов через одно соединение.
🔸 HTTP/3: также поддерживает мультиплексирование, но делает это более эффективно благодаря особенностям QUIC.

📌 Подробнее:

🔗 Cloudflare: What is HTTP/3?
🔗 Google: HTTP/3 Explained