This media is not supported in your browser
VIEW IN TELEGRAM
Я сам решу! Что нужно идти на Golang meetup by Sber — 6 августа в 18:00! 😉
В программе 3 доклада:
🔹 «Улучшаем качество отчётов нагрузочного тестирования с помощью Go, langchain и GigaChat». Антон Юрченко, Сбер
🔹 «Не ждите ковариантности в Go — берите дженерики в работу». Станислав Иванкевич, СберТех
🔹 «Покой и любовь в тестировании сервисов на Go». Макс Теричев, YADRO
А ещё — стенды, нетворкинг и фуршет ☺️
Участвуйте как удобно: офлайн в Москве или онлайн. Ждём вас — регистрируйтесь по ссылке! 👌
В программе 3 доклада:
🔹 «Улучшаем качество отчётов нагрузочного тестирования с помощью Go, langchain и GigaChat». Антон Юрченко, Сбер
🔹 «Не ждите ковариантности в Go — берите дженерики в работу». Станислав Иванкевич, СберТех
🔹 «Покой и любовь в тестировании сервисов на Go». Макс Теричев, YADRO
А ещё — стенды, нетворкинг и фуршет ☺️
Участвуйте как удобно: офлайн в Москве или онлайн. Ждём вас — регистрируйтесь по ссылке! 👌
❤3🤬2
🚀 Go в American Express: как язык покорил финтех‑гиганта
С 2016 года инженеры AmEx внедряют Go в масштабные продакшн‑системы. Вот 7 ключевых инсайтов из их опыта:
///text
1. Go Modules теперь полностью решают dependency‑хаос — даже за корпоративным прокси.
2. Конкурентность — мощная, но коварная. Goroutines → да, но с контролем: context, defer, sync и обязат@golang_booksельный
3. В обучение вложились серьёзно: тренинги, менторство и своя документация по idiomatic Go.
4. Golden Framework — единый шаблон с логгингом, graceful shutdown, health‑checks и observability по умолчанию.
5. Производительность контролируется через встроенные инструменты:
6. Observability first: метрики, логгирование и трейсинг легко интегрируются в общую платформу мониторинга.
7. Сообщество внутри: 1000+ инженеров в активных каналах, общие практики и постоянные митапы.
///
📌 А ещё Go прошёл Language Showdown: 140 000 req/s — быстрее Node.js, Java и почти вровень с C++. Это и стало поворотной точкой.
📎 Подробнее: https://americanexpress.io/go-at-american-express-today/
@golang_books
С 2016 года инженеры AmEx внедряют Go в масштабные продакшн‑системы. Вот 7 ключевых инсайтов из их опыта:
///text
1. Go Modules теперь полностью решают dependency‑хаос — даже за корпоративным прокси.
2. Конкурентность — мощная, но коварная. Goroutines → да, но с контролем: context, defer, sync и обязат@golang_booksельный
-race
в тестах.3. В обучение вложились серьёзно: тренинги, менторство и своя документация по idiomatic Go.
4. Golden Framework — единый шаблон с логгингом, graceful shutdown, health‑checks и observability по умолчанию.
5. Производительность контролируется через встроенные инструменты:
pprof
, бенчмарки, GC‑паузы — всё под рукой.6. Observability first: метрики, логгирование и трейсинг легко интегрируются в общую платформу мониторинга.
7. Сообщество внутри: 1000+ инженеров в активных каналах, общие практики и постоянные митапы.
///
📌 А ещё Go прошёл Language Showdown: 140 000 req/s — быстрее Node.js, Java и почти вровень с C++. Это и стало поворотной точкой.
📎 Подробнее: https://americanexpress.io/go-at-american-express-today/
@golang_books
🔥13😁4🥰2❤1
⏱ Почему в Go нельзя полагаться на системное время?
В этой разобрали интересный кейс: монотоное и «стеночное» время (monotonic vs wall clock) в Go.
🔍 В чём проблема?
time.Now() в Go возвращает смешанное время:
— *монотоное* (для измерений)
— *реальное «стеночное»* (часы системы)
Если неправильно использовать это время в вычислениях (например, при сравнении таймштампов), можно получить неожиданные баги:
— прыжки при изменении системных часов
— некорректные таймауты и дедлайны
— рассинхрон в распределённых системах
💡 Рекомендация: для измерений использовать монотоное время (`Since`, `Until`), а для логов и меток — преобразовывать только wall clock.
📌 Пример:
Но если сохранить time.Time в лог или БД и потом пересчитать разницу:
Если за это время системное время изменилось (например, ntpd подвинуло часы), elapsed может быть отрицательным или неверным.
💣 В распределённых системах это особенно опасно:
- Неправильные таймауты
- Нарушение дедлайнов
- Отказ retry‑механизмов
📌 Полный разбор
В этой разобрали интересный кейс: монотоное и «стеночное» время (monotonic vs wall clock) в Go.
🔍 В чём проблема?
time.Now() в Go возвращает смешанное время:
— *монотоное* (для измерений)
— *реальное «стеночное»* (часы системы)
Если неправильно использовать это время в вычислениях (например, при сравнении таймштампов), можно получить неожиданные баги:
— прыжки при изменении системных часов
— некорректные таймауты и дедлайны
— рассинхрон в распределённых системах
💡 Рекомендация: для измерений использовать монотоное время (`Since`, `Until`), а для логов и меток — преобразовывать только wall clock.
📌 Пример:
start := time.Now()
time.Sleep(5 * time.Second)
elapsed := time.Since(start) // работает корректно, потому что Go использует монотоное время
Но если сохранить time.Time в лог или БД и потом пересчитать разницу:
start := time.Now()
// сохраняем start куда-то...
// позже:
elapsed := time.Now().Sub(start) // ❌ здесь может быть ошибка!
Если за это время системное время изменилось (например, ntpd подвинуло часы), elapsed может быть отрицательным или неверным.
💣 В распределённых системах это особенно опасно:
- Неправильные таймауты
- Нарушение дедлайнов
- Отказ retry‑механизмов
📌 Полный разбор
👍11❤8🥰1