Функциональные опции в Go

https://habr.com/ru/articles/842594/

🤓 Я как-то писал в своём основном канале про паттерн Functional Options — этот подход мне нравится, и я часто его вижу. А если он вам даже и не нравится, то познакомится всё равно стоит, т.к. встречать вы его наверняка тоже будете часто.

Если же хочется погрузиться глубже, то вот вам свежая подробная статья на Хабре на эту тему (не моя!). Написано очень хорошо, мне понравилось — читается легко и приятно.

————

Предвосхищая ваши комментарии, про Configurable Object я тоже писал 🤓

#article

Готовим слайсы в Go: подробно о динамических массивах, строчках и ускорении

https://habr.com/ru/companies/yadro/articles/874480/

Ещё одна неплохая и очень подробная статья про слайсы с глубоким погружением.

Что разобрано:

- Внутреннее устройство слайсов и как растёт их capacity. Также затронут интересный момент про округление вместимости из-за особенностей хранения объектов в хипе, про который редко пишут

- Разные способы создания слайсов и когда какой вариант лучше (пустой слайс, make(len), make(0, cap) и т.д.).

- Передача слайсов в функции: по значению vs по указателю

- Работа со строками, конкатенация и оптимизации компилятора

- Подробный разбор bytes.Buffer vs strings.Builder и их особенностей

- Тонкости копирования при []byte → string и обратно

- Использование sync.Pool для переиспользования памяти — как не забыть "вернуть" объект в пул и почему со strings.Builder это не работает

- Сравнение разных способов конкатенации строк на больших и маленьких объёмах данных

И много ещё интересного.

Особенно порадовали бенчмарки в конце с неожиданными результатами — strings.Join() может работать эффективнее чем bytes.Buffer.

В общем, рекомендую к прочтению 👾

#performance #slices #strings #article

👴 Принципы работы и преимущества обновленной map в — Go 1.24

https://habr.com/ru/companies/simbirsoft/articles/899180/

Ещё один неплохой подробный разбор новой мапы в Go. Более простым языком и с цветными картинками ✨

#article

Писать или не писать простой код?

Предлагаю вашему вниманию две три статьи:

1. Пиши простой код
2. Не пиши простой код
3. Просто пиши код

Интересная и горячая дискуссия, которая нас с вами тоже касается, не пропустите.

От комментариев я пока воздержусь, но, возможно, чуть позже поделюсь и своим мнением по итогам 🌚

#article #discussion

🦄 Как на самом деле хранятся изображения?

- Перевод
- Оригинал

Фундаментальная статья, которая погружает в самые недра форматов изображений. Автор не просто описывает JPEG, PNG и GIF, а детально разбирает их внутреннее устройство, принципы сжатия. В общем, всё как мы любим.

Что именно разбирается:

- Основы: Краткий ликбез по пикселям, цветовым моделям RGB и RGBA.

- GIF: Подробно о палитре, анимации и о том, как стандартная библиотека Go (image/gif) кодирует эти изображения. Есть даже пример создания простого анимированного GIF на Go.

- PNG: Разбор структуры чанков (IHDR, IDAT, IEND), использование DEFLATE для сжатия, и очень интересный раздел о техниках фильтрации (Sub, Up, Average, Paeth), которые помогают улучшить степень сжатия. Автор также ссылается на реализацию этих фильтров в Go.

- JPEG: Глубокое погружение в механизмы этого формата

Статья довольно объемная, но читается интересно и неплохо расширяет кругозор.

Бонусом идут примеры кода на Go ❤️

#article #deep_dive

Самый.. детальный гайд по планировщику

https://nghiant3223.github.io/2025/04/15/go-scheduler.html

Случайно наткнулся на ещё одну статью про планировщик Go. Я бы не стал делиться подобным в очередной раз (тем более, уже есть шедевр на все времена 👍), но этот автор смог меня удивить — такой детальной проработки на эту тему я пока не встречал.

К тому же, статья довольно свежая: Apr 15, 2025

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

#article #english

Регламент для работы с ошибками в Go

https://habr.com/ru/companies/oleg-bunin/articles/913096/

Ну что, готовы в очередной раз обсудить работу с ошибками? 😩

#article

🔨Вероятно, вам не нужен DI-фреймворк

- Оригинал
- Перевод

Хорошая статья о том, почему DI-фреймворки в Go часто создают больше проблем, чем решают.

Вкратце суть статьи:

- DI — это просто передача зависимостей в конструкторы

- Фреймворки типа dig и wire часто пытаются исправить проблемы, которых нет, добавляя лишнюю сложность.

- Самый понятный и надёжный подход для большинства проектов — внедрять зависимости вручную.

————

Я полностью согласен с автором. Чем проще — тем лучше.

Сколько лет работаю с проектами на Go, и DI-фреймворки встречал ровно ноль раз (ну разве что QA себе иногда прикручивали, но им можно).

Что интересно, ни разу не ощущал, что мне без этого плохо. Всё прекрасно работает, всё прозрачно, без магии. Я всегда понимаю, откуда что берётся. Я чётко понимаю откуда что берётся.

Чего ради такие сложности? Чтобы main() был короче? Да он и так не супер большой, и заглядывать туда каждый день не приходится.

Кстати, сравните лучше эту тему объяснил Claude Opus 4. Его вариант выглядит намного проще и понятней, при всём уважении к автору статьи.
В любом случае, статьи от кожаных всё же имеют бОльшую ценность, т.к. передают реальный опыт, а не синтетический.

#article #di

Golang тихо умирает? 🙅‍♂️

- Перевод
- Оригинал (недоступен: This account is under investigation or was found in violation of the Medium Rules)

Автор статьи заявляет, что крупные компании начали "тихий отказ" от Go в пользу Rust, Kotlin и TypeScript.

Причины:

- Простота языка 👍
- Непредсказуемые паузы из-за GC 💪
- Бедность абстракций и неудобная обработка ошибок 😩

В качестве примеров приводятся Cloudflare, Dropbox и Amazon, которые частично заменили Go на Rust.

————

Звучит страшновато, конечно. Но есть нюанс: примеры автора выглядят скорее как исключения и диверсификация, а не отказ. Cloudflare и Dropbox переписали лишь части проектов, а вся остальная инфраструктура и дальше спокойно живёт на Go. Сами же Google, AWS и куча других активно инвестируют в язык, а сообщество стабильно растёт.

Да, Go отдал Rust-у узкую нишу «real-time без GC». И это логично — нельзя идеально закрывать сразу все сценарии. Но говорить про смерть Go рановато (и даже смешно): тот же Docker, K8s, Terraform, Grafana, Prometheus и весь облачный стек чувствуют себя отлично и никуда не собираются.

Ну и вот эта цитата особенно забавляет: ... Но эпоха, когда Go был будущим программирования? Она угасает.

А что, кто-то считал Go "будущим программирования"? 🙃

Итого: языки не умирают так просто. Сколько лет уже хоронят Java и PHP?

#article

Полноценное RAG-приложение на Go — безумие?

https://habr.com/ru/articles/930090/

Хорошая статья от начинающего разработчика, который решил пойти против течения и построить RAG-систему на Go, вместо привычного Python.
Спойлер: вышло интересно, хоть и с нюансами.

Получилась довольно нетривиальная система:

- 5 микросервисов с разделением ответственности
- Kafka в роли брокера сообщений
- Ollama для локального inference на собственной GPU
- gRPC-стриминг + SSE для передачи токенов в реальном времени (без вебсокетов)

👴 Учитываем, что это пет-проект, и архитектура немного перегружена ради учебных целей.

Узкие места и проблемы:
Главный bottleneck оказался в Ollama — весь трафик генерации и эмбеддингов упирается в неё, локальная GPU тянет всего один запрос за раз.

Мои мысли по оптимизации:

- Для продакшена точно нужен vLLM кластер или платные API (OpenAI/Anthropic)
- Kafka здесь оверкилл — NATS или Redis Streams справятся не хуже и проще в деплое
- Можно добавить кеширование эмбеддингов и результатов поиска
- Рассмотреть pgvector вместо отдельного векторного хранилища

В целом, статья полезная, и выбор Go вместо Python для RAG выглядит вполне логично — действительно, RAG это по большей части инфраструктура, а не ML-магия.

Особенно ценно, что автор честно описывает проблемы и не идеализирует решение.

#article #rag #llm