Писать или не писать простой код?
Предлагаю вашему вниманиюдве три статьи:
1. Пиши простой код
2. Не пиши простой код
3. Просто пиши код
Интересная и горячая дискуссия, которая нас с вами тоже касается, не пропустите.
От комментариев я пока воздержусь, но, возможно, чуть позже поделюсь и своим мнением по итогам🌚
#article #discussion
Предлагаю вашему вниманию
1. Пиши простой код
2. Не пиши простой код
3. Просто пиши код
Интересная и горячая дискуссия, которая нас с вами тоже касается, не пропустите.
От комментариев я пока воздержусь, но, возможно, чуть позже поделюсь и своим мнением по итогам
#article #discussion
Please open Telegram to view this post
VIEW IN TELEGRAM
Golang Дайджест
Писать или не писать простой код? Предлагаю вашему вниманию две три статьи: 1. Пиши простой код 2. Не пиши простой код 3. Просто пиши код Интересная и горячая дискуссия, которая нас с вами тоже касается, не пропустите. От комментариев я пока воздержусь…
Какой пост вам ближе? Желательно отвечать после прочтения всех трёх, благо они очень короткие.
Раз уж на то пошло..
Раз уж на то пошло..
Anonymous Poll
34%
1. Пиши простой код
6%
2. Не пиши простой код
25%
3. Просто пиши код
10%
Со всеми согласен
4%
Ни с одним не согласен
21%
Не знаю / Посмотреть ответы
- Перевод
- Оригинал
Фундаментальная статья, которая погружает в самые недра форматов изображений. Автор не просто описывает 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Golang Дайджест
Новый метод в Go 1.25 В Go 1.25 для WaitGroup добавят метод Go, чтобы упростить распространённый паттерн: func (wg *WaitGroup) Go(f func()) { wg.Add(1) go func() { defer wg.Done() f() }() }
Хорошая новость, мне очень не хватало такой штуки в стандартной библиотеке
Перешел с Kotlin на Go и написал AI-Chat
https://habr.com/ru/articles/910122/
Опытный Kotlin-разработчик пишет о том, как он знакомился с Go. Интересный взгляд на наш язык со стороны и возможность сравнить его с другой технологией.
#article
https://habr.com/ru/articles/910122/
Опытный Kotlin-разработчик пишет о том, как он знакомился с Go. Интересный взгляд на наш язык со стороны и возможность сравнить его с другой технологией.
#article
Хабр
Как я ушёл с Kotlin (Spring Boot) на Go (Gin) и сделал AI-чат с WebSocket и GPT-4
Меня зовут Артём, я занимаюсь коммерческой разработкой с 2019 года. Последние несколько лет я активно использовал Spring Boot для создания backend-сервисов на Java и Kotlin. Но в какой-то момент...
Самый.. детальный гайд по планировщику
https://nghiant3223.github.io/2025/04/15/go-scheduler.html
Случайно наткнулся на ещё одну статью про планировщик Go. Я бы не стал делиться подобным в очередной раз (тем более, уже есть шедевр на все времена👍 ), но этот автор смог меня удивить — такой детальной проработки на эту тему я пока не встречал.
К тому же, статья довольно свежая: Apr 15, 2025
В общем, рекомендую как следующий этап после этого ролика / статьи — они больше подходят для первого ознакомления с темой, а здесь более глубокое погружение с огромным количеством деталей.
#article #english
https://nghiant3223.github.io/2025/04/15/go-scheduler.html
Случайно наткнулся на ещё одну статью про планировщик Go. Я бы не стал делиться подобным в очередной раз (тем более, уже есть шедевр на все времена
К тому же, статья довольно свежая: Apr 15, 2025
В общем, рекомендую как следующий этап после этого ролика / статьи — они больше подходят для первого ознакомления с темой, а здесь более глубокое погружение с огромным количеством деталей.
#article #english
Please open Telegram to view this post
VIEW IN TELEGRAM
Melatoni
Go Scheduler
↑ ↓
@angrygopher
Автор очень старается и любит делиться своей экспертизой, рекламы нет, посты качественные.
В общем, хорошая и редкая находка в наше время, рекомендую.
Не реклама, честная рекомендация
#tg_channel
Please open Telegram to view this post
VIEW IN TELEGRAM
Golang Дайджест
Кстати, если вы тоже ведёте каналы про Go или разработку в целом, делитесь ссылками в комментариях.
Совет: чтобы сделать свою ссылку более привлекательной, напишите к ней краткий комментарий — расскажите о себе и о канале. Либо сразу кидайте ссылку на приветственный пост, если он у вас есть.
Возможно, кто-то давно искал именно ваш канал!🦄
————
Различные склады репостов, "полезных ссылок" без комментариев и прочие ленивые каналы не подходят, буду удалять.
🍌 За ссылки на не связанную с тематикой дичь буду сразу банить
Совет: чтобы сделать свою ссылку более привлекательной, напишите к ней краткий комментарий — расскажите о себе и о канале. Либо сразу кидайте ссылку на приветственный пост, если он у вас есть.
Возможно, кто-то давно искал именно ваш канал!
————
Различные склады репостов, "полезных ссылок" без комментариев и прочие ленивые каналы не подходят, буду удалять.
Please open Telegram to view this post
VIEW IN TELEGRAM
Регламент для работы с ошибками в Go
https://habr.com/ru/companies/oleg-bunin/articles/913096/
Ну что, готовы в очередной раз обсудить работу с ошибками?😩
#article
https://habr.com/ru/companies/oleg-bunin/articles/913096/
Ну что, готовы в очередной раз обсудить работу с ошибками?
#article
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Регламент для работы с ошибками в Go
Ошибки в приложениях неизбежны, но мы можем их смягчить и упростить отладку. Но как выбрать правильный способ обработки? В этой статье предлагаю разобраться, как организовать работу с ошибками в Go...
Forwarded from myStack
if err != nil остаётся
Команда Go решила не менять синтаксис обработки ошибок и закрывает все предложения по упрощению error handling - ни один вариант не получил широкой поддержки ни в команде, ни в сообществе.
Причины:
- Нет консенсуса, нужен ли такой синтаксический сахар
- Привычный способ error handling признан рабочим и идиоматичным
- Изменения усложнят язык и приведут к массовым изменениям в коде
Команда Go решила не менять синтаксис обработки ошибок и закрывает все предложения по упрощению error handling - ни один вариант не получил широкой поддержки ни в команде, ни в сообществе.
Причины:
- Нет консенсуса, нужен ли такой синтаксический сахар
- Привычный способ error handling признан рабочим и идиоматичным
- Изменения усложнят язык и приведут к массовым изменениям в коде
Golang Дайджест
Можете теперь присылать интересные материалы, которые, на ваш взгляд, стоит опубликовать здесь ❤️
Главное чтобы это было интересно и соответствовало тематике канала
Главное чтобы это было интересно и соответствовало тематике канала
Please open Telegram to view this post
VIEW IN TELEGRAM
Как устроены новые мапы в Go 1.24
https://habr.com/ru/companies/ru_mts/articles/915880/
Ещё одна неплохая статья про внутреннее устройство Swiss Map
#article #swissmap
https://habr.com/ru/companies/ru_mts/articles/915880/
Ещё одна неплохая статья про внутреннее устройство Swiss Map
#article #swissmap
Хабр
Как устроены новые мапы в Go 1.24
Привет, Хабр! Меня зовут Владимир Марунин, я ведущий разработчик в команде Clatch. Сегодня расскажу о новых мапах в Go 1.24: разберем изменения, посмотрим, что было и что стало. О мапах часто...
Golang Дайджест
Как устроены новые мапы в Go 1.24 https://habr.com/ru/companies/ru_mts/articles/915880/ Ещё одна неплохая статья про внутреннее устройство Swiss Map #article #swissmap
Пройти мимо статьи, которая сложнее инструкции к зубной щётке: 🙅♂️
В грубой быдло-форме объяснить автору, что разбираться во внутреннем устройстве чего-либо совершенно ни к чему:✨
Всё правильно, одному деградировать скучно, а вместе веселее!
————
Эх, помню времена, когда на Хабре токсично критиковали статьи за то, что они слишком простые.. А теперь за то, что слишком сложные😩
Не показывайте ему, пожалуйста, статью про планировщик !
В грубой быдло-форме объяснить автору, что разбираться во внутреннем устройстве чего-либо совершенно ни к чему:
Всё правильно, одному деградировать скучно, а вместе веселее!
————
Эх, помню времена, когда на Хабре токсично критиковали статьи за то, что они слишком простые.. А теперь за то, что слишком сложные
Please open Telegram to view this post
VIEW IN TELEGRAM
- Оригинал
- Перевод
Хорошая статья о том, почему DI-фреймворки в Go часто создают больше проблем, чем решают.
Вкратце суть статьи:
- DI — это просто передача зависимостей в конструкторы
- Фреймворки типа dig и wire часто пытаются исправить проблемы, которых нет, добавляя лишнюю сложность.
- Самый понятный и надёжный подход для большинства проектов — внедрять зависимости вручную.
————
Я полностью согласен с автором. Чем проще — тем лучше.
Сколько лет работаю с проектами на Go, и DI-фреймворки встречал ровно ноль раз (ну разве что QA себе иногда прикручивали, но им можно).
Что интересно, ни разу не ощущал, что мне без этого плохо. Всё прекрасно работает, всё прозрачно, без магии. Я всегда понимаю, откуда что берётся. Я чётко понимаю откуда что берётся.
Чего ради такие сложности? Чтобы
main() был короче? Да он и так не супер большой, и заглядывать туда каждый день не приходится.Кстати, сравните лучше эту тему объяснил Claude Opus 4. Его вариант выглядит намного проще и понятней, при всём уважении к автору статьи.
В любом случае, статьи от кожаных всё же имеют бОльшую ценность, т.к. передают реальный опыт, а не синтетический.
#article #di
Please open Telegram to view this post
VIEW IN TELEGRAM
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
- Перевод
- Оригинал (недоступен: 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Как разогнать TLS на Go до 100 Gbps — опыт Kinescope
https://habr.com/ru/companies/oleg-bunin/articles/913272/
Ребята из Kinescope показывают, как они добились скорости раздачи видео в 100 Gbps на обычных 1U-серверах, используя Go и kTLS.
Что интересного:
- Перенесли TLS-шифрование из user space в ядро Linux с помощью kTLS — получили zero-copy и минимальную нагрузку на CPU (1.4% при 40 Gbps)
- Обнаружили, что Let's Encrypt по умолчанию выдаёт RSA-сертификаты. Переход на ECDSA ускорил handshake в 40 раз (с 1.6 сек до 40 мс)
- Написали минимальный патч к стандартной библиотеке Go для поддержки kTLS — всё работает через обычные интерфейсы
- Решили проблему session resumption на множестве серверов простым способом — синхронизацией ключей между машинами
Интересный момент: когда из-за ошибки в конфиге весь трафик (40 Gbps) ушёл на одну машину — и она выдержала, хотя и "молотила" 600% CPU.
————
Хорошая статья с реальными продакшн-кейсами. Авторы не стесняются рассказывать про свои косяки (история с ChaCha и бабушкафонами) и показывают конкретные метрики.
Кстати, как заметил автор, в Go уже принято решение добавить поддержку kTLS в стандартную библиотеку — issue #44506 наконец-то сдвинулся с мёртвой точки.
#article #performance #tls
https://habr.com/ru/companies/oleg-bunin/articles/913272/
Ребята из Kinescope показывают, как они добились скорости раздачи видео в 100 Gbps на обычных 1U-серверах, используя Go и kTLS.
Что интересного:
- Перенесли TLS-шифрование из user space в ядро Linux с помощью kTLS — получили zero-copy и минимальную нагрузку на CPU (1.4% при 40 Gbps)
- Обнаружили, что Let's Encrypt по умолчанию выдаёт RSA-сертификаты. Переход на ECDSA ускорил handshake в 40 раз (с 1.6 сек до 40 мс)
- Написали минимальный патч к стандартной библиотеке Go для поддержки kTLS — всё работает через обычные интерфейсы
- Решили проблему session resumption на множестве серверов простым способом — синхронизацией ключей между машинами
Интересный момент: когда из-за ошибки в конфиге весь трафик (40 Gbps) ушёл на одну машину — и она выдержала, хотя и "молотила" 600% CPU.
————
Хорошая статья с реальными продакшн-кейсами. Авторы не стесняются рассказывать про свои косяки (история с ChaCha и бабушкафонами) и показывают конкретные метрики.
Кстати, как заметил автор, в Go уже принято решение добавить поддержку kTLS в стандартную библиотеку — issue #44506 наконец-то сдвинулся с мёртвой точки.
#article #performance #tls
Forwarded from Thank Go! (Anton Zhiyanov)
GOMAXPROCS для контейнеров
Параметр рантайма GOMAXPROCS определяет максимальное количество потоков операционной системы, которые планировщик Go может использовать для одновременного выполнения горутин.
Начиная с Go 1.5, по умолчанию он равен значению runtime.NumCPU, то есть количеству логических CPU на машине.
Например, на моем ноутбуке с 8 ядрами значение GOMAXPROCS по умолчанию тоже равно 8:
Программы на Go часто запускаются в контейнерах под управлением Docker или Kubernetes. В этих системах можно ограничить использование процессора для контейнера с помощью функции Linux, которая называется cgroups.
До версии 1.25 рантайм Go не учитывал ограничение по CPU (CPU-квоту) при установке значения GOMAXPROCS. Как бы вы ни ограничивали ресурсы процессора, GOMAXPROCS всегда устанавливался равным количеству CPU на хосте.
А теперь начал учитывать:
Если лимит CPU изменяется, рантайм автоматически обновляет значение GOMAXPROCS. Сейчас это происходит не чаще одного раза в секунду.
подробности
Параметр рантайма GOMAXPROCS определяет максимальное количество потоков операционной системы, которые планировщик Go может использовать для одновременного выполнения горутин.
Начиная с Go 1.5, по умолчанию он равен значению runtime.NumCPU, то есть количеству логических CPU на машине.
Например, на моем ноутбуке с 8 ядрами значение GOMAXPROCS по умолчанию тоже равно 8:
maxProcs := runtime.GOMAXPROCS(0)
fmt.Println("NumCPU:", runtime.NumCPU())
fmt.Println("GOMAXPROCS:", maxProcs)
NumCPU: 8
GOMAXPROCS: 8
Программы на Go часто запускаются в контейнерах под управлением Docker или Kubernetes. В этих системах можно ограничить использование процессора для контейнера с помощью функции Linux, которая называется cgroups.
До версии 1.25 рантайм Go не учитывал ограничение по CPU (CPU-квоту) при установке значения GOMAXPROCS. Как бы вы ни ограничивали ресурсы процессора, GOMAXPROCS всегда устанавливался равным количеству CPU на хосте.
А теперь начал учитывать:
docker run --cpus=4 golang:1.25rc1-alpine go run /app/nproc.go
NumCPU: 8
GOMAXPROCS: 4
Если лимит CPU изменяется, рантайм автоматически обновляет значение GOMAXPROCS. Сейчас это происходит не чаще одного раза в секунду.
подробности
This media is not supported in your browser
VIEW IN TELEGRAM
Когда: 17 июля
Ребята из Авито приглашают Go-разработчиков на встречу Avito Grill & Go, чтобы пообщаться, отдохнуть и вкусно поесть
В приятной атмосфере вы сможете:
- Поучаствовать в мемном Fast Food System Design
- Порешать код-челленджи
- Обсудить карьерные треки
- Перенять опыт напрямую от разработчиков Авито
Участие бесплатное, но регистрация обязательна
#промо
Please open Telegram to view this post
VIEW IN TELEGRAM