👴 Принципы работы и преимущества обновленной 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-with-me - хороший авторский канал по Go

@angrygopher

Автор очень старается и любит делиться своей экспертизой, рекламы нет, посты качественные.

В общем, хорошая и редкая находка в наше время, рекомендую.

Не реклама, честная рекомендация ❤️

#tg_channel

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

Совет: чтобы сделать свою ссылку более привлекательной, напишите к ней краткий комментарий — расскажите о себе и о канале. Либо сразу кидайте ссылку на приветственный пост, если он у вас есть.

Возможно, кто-то давно искал именно ваш канал! 🦄

————

Различные склады репостов, "полезных ссылок" без комментариев и прочие ленивые каналы не подходят, буду удалять.

🍌 За ссылки на не связанную с тематикой дичь буду сразу банить

Регламент для работы с ошибками в 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