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

другое дело, что вендоринг создает дополнительные проблемы

а, может быть, дело не в вендоринге, а в отсутствии общепринятого workflow и в отсутствии средств контроля library api

возможно, нам нужна тулза, которая при вендоринге будет делать слепок api, и при апдейте сравнивать, осталась ли совместимость. если нет - не будет апдейтить (или будет до последнего совместимого коммита, или еще как)

я думаю оно со временем устаканится и будем мы проектировать мощные api с параноидальной обратной совместимостью

я вот думаю - устаканится нейминг для веток

Ничто не помешает авторам менять поведение метода. Как это проверить? Внешне сигнатура не поменялась, а внутри происходит не то, что раньше

возможно, нам нужна тулза, которая при вендоринге будет делать слепок api, и при апдейте сравнивать, осталась ли совместимость. если нет - не будет апдейтить (или будет до последнего совместимого коммита, или еще как)

ну в принципе в стандартной библиотеке есть очень неплохие пакеты для разбора ast, так что слепить проверку методов не слишком сложно

Ничто не помешает авторам менять поведение метода. Как это проверить? Внешне сигнатура не поменялась, а внутри происходит не то, что раньше

от этого защиты нигде нет и быть не может. но речь-то не об этом

Ничто не помешает авторам менять поведение метода. Как это проверить? Внешне сигнатура не поменялась, а внутри происходит не то, что раньше

не важно насколько сложную проверку мы придумаем, автор всё равно сможет сломать, если захочет такие тулзы нужны для того, чтобы напоминать об изменениях самих разработчиков библиотеки

ну в принципе в стандартной библиотеке есть очень неплохие пакеты для разбора ast, так что слепить проверку методов не слишком сложно

@alek_si , по-моему, говорил, что есть уже такие

но в перле, например, где есть и cpanfile с фиксацией версии, и центральная репа, я регулярно въезжал в проблемы совместимости. так что универсальная таблетка не придумана пока

ну такое всегда на совести разработчика

не совсем

не будь у нас фиксации версий - проблемы бы не могли накопиться

Это первый уровень... дальше ведь транзитивные зависимости, когда проект зависит от двух либ, которые зависят от разных версий третьей либы 😱

ну такое всегда на совести разработчика

единственный способ гарантировать повторяеме билды - это упаковать исходники и все зависимости с компилятором в один тар гзип и возить с собой

Это первый уровень... дальше ведь транзитивные зависимости, когда проект зависит от двух либ, которые зависят от разных версий третьей либы 😱

да, с текущей реализацией путей импорта это не обойти

* их вообще не должно быть по-хорошему

ребят какую библиотеку выбрать для телеграмм бота на golang

https://github.com/olebedev/go-tgbot

Коллеги, очень нужна помощь экспертов. Кейс: надо делать очень много асинхронных http запросов в чужие сервисы (RTB) с установленным таймаутом. Как сделали: в гоурутинах создаем http.Client с таймаутом. Проблема: многие коннекты отваливаются по таймауту, даже те, которые гарантированно успевают ответить. По-видимому, переключение гоурутин происходит с запазданием, а таймер таймаута продолжает увеличиваться, пока не переключится на эту гоурутину, хотя сервис уже ответил/готов ответить быстро. Как решить данную проблему?

Может контекст с таймаутом в рутины передавать...

Тоже об этом думал, но с точки зрения рантайма чем это отличается от таймаута в хттп клиенте?

Вот у меня есть группа http запросов (допустим, 50), и мне надо, чтобы они гарантированно выполнились, либо закрылись через 100 мс после старта. Правильно ли я понимаю, что это надо создать для них глобальный контекст с таймаутом? В таком случае есть ли гарантия, что гоурутины с этими запросами будут активированы хоть раз до наступления этого таймаута?

А сколько у вас ядер, какова на них нагрузка и чему равна GOMAXPROCS?

32 ядра, нагрузка около 15%, GOMAXPROCS не выставляю, так как, насколько мне известно, с 1.5 версии она равна количеству ядер

Off-topic: так и знал, что этот баннер на гиктаймсе нарочно программно появляется позже, чтобы цтр понять

Вы думаете, что CPU не справляется?

Думал, но нет

А коннектов сколько?

Много) Тысячи. Но сейчас модуль написан на Scala и справляется

Эт понятно

А если поднять GOMAXPROCS до, скажем, 500 - изменится ситуация?

Мне любопытно

Надо попробовать

Имеет смысл посмотреть в сторону runtime.LockOSThread()

Но с колвом потоков все равно придется шаманить

Да вот непонятно

Надо диагностику проводить

А какой там таймаут?

100 мс

Короче проблема вроде стала более ясна

У нас количество коннектов никак не ограничено пулом

Надо сделать пул коннектов

Иначе серверу становится плохо

Никто не знает, как через стандартную либу сделать пул? Там есть что-нибудь встроенное?

http.Transport похоже

Есть у кого то примеры работы с eventlog на windows? Библиотека есть, а примеров нет

А в чем это плохо выражается?

А в чем это плохо выражается?

Я про то, во что оно упирается

GC начинает долго работать

По полсекунды

По полсекунды

в минуту?

Вот так это в графане выглядит

GC начинает долго работать

А что за версия go? Вроде, пауз такой длины быть-то не должно сегодня

а это точно пауза?

1.8

Вот так это в графане выглядит

а вы как часто замеряете?

Раз в 15 сек

А что за версия go? Вроде, пауз такой длины быть-то не должно сегодня

бывают же. Магии то не существует - много мусора, много пауз

Раз в 15 сек

то есть это 509мс на 15 секунд?

Но сами паузы должны быть короткие

Но сами паузы должны быть короткие

о нет

то есть это 509мс на 15 секунд?

На графике квантили

Но сами паузы должны быть короткие

они никому ничего не должны в общем-то

:)

На графике квантили

ну я пытаюсь понять что вы меряете и как

Нам же обещали короткий stoptheworld

Нам же обещали короткий stoptheworld

чувак, магии не бывает

пойми

Нам же обещали короткий stoptheworld

Вроде как не с чего ему быть коротким

в 1.9 ещё короче вроде

если ты нагенерил 60-80ГБ мусора мелкими объектами то у тебя stop the world будет огромным

Вот так это в графане выглядит

а попробуйте посмотреть с помощью https://github.com/davecheney/gcvis

Алогритмы те же, что и в JVM, если память меня сейчас не подводит

что бы ты ни делал

он больше информации даёт. И размеры мусора будут видно

но что в 1.8 и в 1.9 начинал gc дольше работать т.к. создавалась мнооого замыканий

Алогритмы те же, что и в JVM, если память меня сейчас не подводит

те что в JVM 5-ой или 6-ой