- Оригинал
- Перевод
Хорошая статья о том, почему DI-фреймворки в Go часто создают больше проблем, чем решают.
Вкратце суть статьи:
- DI — это просто передача зависимостей в конструкторы
- Фреймворки типа dig и wire часто пытаются исправить проблемы, которых нет, добавляя лишнюю сложность.
- Самый понятный и надёжный подход для большинства проектов — внедрять зависимости вручную.
————
Я полностью согласен с автором. Чем проще — тем лучше.
Сколько лет работаю с проектами на Go, и DI-фреймворки встречал ровно ноль раз (ну разве что QA себе иногда прикручивали, но им можно).
Что интересно, ни разу не ощущал, что мне без этого плохо. Всё прекрасно работает, всё прозрачно, без магии. Я всегда понимаю, откуда что берётся. Я чётко понимаю откуда что берётся.
Чего ради такие сложности? Чтобы
main() был короче? Да он и так не супер большой, и заглядывать туда каждый день не приходится.Кстати, сравните лучше эту тему объяснил Claude Opus 4. Его вариант выглядит намного проще и понятней, при всём уважении к автору статьи.
В любом случае, статьи от кожаных всё же имеют бОльшую ценность, т.к. передают реальный опыт, а не синтетический.
#article #di
Please open Telegram to view this post
VIEW IN TELEGRAM
👍33❤11🔥5🤯3
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
🤔36👍25❤9🤯1
Как разогнать 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
🔥49👍6
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. Сейчас это происходит не чаще одного раза в секунду.
подробности
🔥35👍8❤6
🛠 AI агент в 400 строк кода на Go
https://ampcode.com/how-to-build-an-agent
Оличная статья от Thorsten Ball про создание собственного ИИ агента. Особая прелесть в том, что автор объясняет всё настолько просто и доступно, что осилить её можно буквально за полчаса, получив полностью рабочего агента (с перспективами для развития, конечно).
В общем, всё в лучших традициях его замечательных книг Interpreter In Go и Compiler In Go, но в формате короткой статьи.
Это очень полезное упражнение для понимания того, как агенты устроены внутри. Да и в целом, это очень весело, вдохновляет на собственные эксперименты.
Очень рекомендую, я уже написал по ней своего, и даже немного прокачал, просто веселья ради. Мне очень понравилось✨
Конечно, замену полноценному агенту вы таким образом не получите, впереди ещё много работы. Но главное, что отправная точка уже есть.
————
И вдогонку ещё одна статья на ту же тему от нашего соотечественника на Хабре
#ai_agent #diy #llm
https://ampcode.com/how-to-build-an-agent
Оличная статья от Thorsten Ball про создание собственного ИИ агента. Особая прелесть в том, что автор объясняет всё настолько просто и доступно, что осилить её можно буквально за полчаса, получив полностью рабочего агента (с перспективами для развития, конечно).
В общем, всё в лучших традициях его замечательных книг Interpreter In Go и Compiler In Go, но в формате короткой статьи.
Это очень полезное упражнение для понимания того, как агенты устроены внутри. Да и в целом, это очень весело, вдохновляет на собственные эксперименты.
Очень рекомендую, я уже написал по ней своего, и даже немного прокачал, просто веселья ради. Мне очень понравилось
Конечно, замену полноценному агенту вы таким образом не получите, впереди ещё много работы. Но главное, что отправная точка уже есть.
————
И вдогонку ещё одна статья на ту же тему от нашего соотечественника на Хабре
#ai_agent #diy #llm
Please open Telegram to view this post
VIEW IN TELEGRAM
Ampcode
How to Build an Agent
Building a fully functional, code-editing agent in less than 400 lines.
🔥37❤1👍1