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👍24❤8🤯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
🔥48👍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.
🔥34❤1👍1