🫶 Представлен второй релиз-кандидат Go 1.22

Официальный релиз совсем близко, но вы уже сейчас можете протестировать новые фичи языка!

📣 Анонс
🗃 Скачать

#новости

🔥Оптимизация производительности в Go на практике

Команда Sourcegraph делится опытом оптимизации некоторых базовых математических операций в Code AI и описывает различные этапы оптимизации, начиная с простой реализации на Go и постепенно углубляясь в оптимизацию: от loop unrolling до bounds check elimination.

Но настоящий прорыв произошел при использовании SIMD (single instruction, multiple data) и quantization. Этот опыт показал, насколько мощным может быть низкоуровневое программирование даже в таком высокоуровневом языке, как Go👇

🔗 Читать

⚡️Самые полезные каналы по Go в одной папке

В ней:
➖канал для подготовки к собеседованиям
➖интересные задачи
➖основной канал (этот)
➖книги по Go
➖лучшие вакансии из сферы
➖и наш чат, в котором можно общаться и задавать вопросы

Добавляйте 👉 тык сюда

📌 Подборка докладов с конференций Saint HighLoad++ и HighLoad++ 2023:

🌐 Внутренняя платформа для разработки и разработчиков: за что платит бизнес? / Александр Чубинский
🌐 Авито Автозагрузка: как качать миллионы фотографий в сутки / Евгений Толмачев (Авито)
🌐 Ах, как хочется вернуться, ворваться в монолит! / Павел Лакосников (Авито)
🌐 YTsaurus SPYT: помогаем планировщику Apache Spark быть ещё эффективнее / Алексей Шишкин (Яндекс)
🌐 YTsaurus: опыт эксплуатации хранилища из 180К дисков / Павел Сушин (Яндекс)
🌐 YTsaurus — это будущее DWH, и в Яндекс Маркете оно наступило / Филипп Козьмин (Яндекс Маркет)

🚀 Colly: полное руководство по высокопроизводительному веб-скрейпингу на Go

Руководство основано на документации и дополнено наглядными примерами от автора.

👉 Читать

🤔 Как исключить зависимости разработки из бинарных файлов в Go: по мотивам статьи Redowan Delowar

В настоящее время, в отличие от Python или NodeJS, Go не позволяет указывать зависимости разработки отдельно от зависимостей приложения. Однако автор предпочитает явно указывать зависимости разработки для лучшей воспроизводимости.

Работая над новым CLI-инструментом для проверки неработающих URL-адресов в файлах markdown, автор столкнулся с интересным соглашением: можно указать зависимости разработки в файле tools.go и затем исключить их при сборке бинарного файла, используя тег сборки.

Вот как это работает. Предположим, у нашего проекта foo есть следующая структура:

foo
├── go.mod
├── go.sum
└── main.go

Файл main.go содержит простую функцию "hello-world", использующую стороннюю зависимость:

package main

import (
    "fmt"

    // Cowsay - это сторонняя зависимость приложения
    cowsay "github.com/Code-Hex/Neo-cowsay"
)

func main() {
    fmt.Println(cowsay.Say(cowsay.Phrase("Hello, World!")))
}

Здесь Neo-cowsay — это зависимость приложения. Для инициализации проекта запускаются следующие команды:

go mod init example.com/foo   # создает файлы go.mod и go.sum
go mod tidy                   # устанавливает зависимости приложения

Теперь предположим, что мы хотим добавить следующие зависимости разработки: golangci-lint для линтинга проекта в CI и gofumpt как более строгий gofmt. Поскольку эти инструменты не импортируются напрямую, они не отслеживаются инструментарием сборки.

Но можно воспользоваться следующим воркфлоу:

1. Разместить файл tools.go в корневой директории.
2. Импортировать зависимости разработки в этом файле.
3. Запустить go mod tidy, чтобы отслеживать как зависимости приложения, так и зависимости разработки через go.mod и go.sum.
4. Указать тег сборки в tools.go, чтобы исключить зависимости разработки из бинарного файла.

В этом случае файл tools.go выглядит следующим образом:

// go:build tools

package tools

import (
    // Зависимости разработки
    _ "github.com/golangci/golangci-lint/cmd/golangci-lint"
    _ "mvdan.cc/gofumpt"
)

Теперь, если вы запустите go mod tidy, инструментарий Go будет отслеживать зависимости через файлы go.mod и go.sum. Вы можете проверить зависимости в go.mod.

Хотя зависимости разработки отслеживаются вместе с зависимостями приложения, тег сборки // go:build tools в начале файла tools.go скажет инструментарию сборки игнорировать их при создании бинарного файла.

Из корневой директории foo можно собрать проект, запустив:

go build main.go

Это создаст бинарный файл main в корневой директории. Чтобы убедиться, что бинарный файл не содержит зависимости разработки, запустите:

go tool nm main | grep -Ei 'golangci-lint|gofumpt'

Это не вернет ничего, если зависимости разработки не упакованы в бинарный файл.

Но если вы сделаете это для зависимости приложения, она выведет артефакты:

go tool nm main | grep -Ei 'cowsay'

Команда выведет:

1000b6d40 T github.com/Code-Hex/Neo-cowsay.(*Cow).Aurora
1000b6fb0 T github.com/Code-Hex/Neo-cowsay.(*Cow).Aurora.func1
1000b5610 T github.com/Code-Hex/Neo-cowsay.(*Cow).Balloon
1000b6020 T github.com/Code-Hex/Neo-cowsay.(*Cow).Balloon.func1
...

Если по какой-то причине вы хотите включить зависимости разработки в свой бинарный файл, вы можете передать тег tools при сборке бинарного файла:

go build --tags tools main.go

#tip

🧰Ginkgo — современный Go-фреймворк для тестирования, который создан на основе пакета testing и дополнен библиотекой Gomega.

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

👉 GitHub