Было бы интересно посмотреть на opentelemetry в сравнении с этими библиотеками да, с одной стороны - лишняя абстракция, но с другой стороны удобство использования (универсальность и поддерживаемость). Плюс, реализацию экспортера можно написать используя викторию, и если всё остальное там достаточно оптимизировано, то по производительности сильно бить не должно
В примере со "словариком" что-то мне стало непонятно - допустим, в питоне это был массив "словариков", но в го - это уже массив структур. Можно было бы в го сделать массив мап map[string]any, и было бы так же коротко - только типизации бы не было - причем так же, как и в питоне. По хорошему, надо было бы и в питоне объявить структуру (класс), иначе тот, кто будет такой код за вами поддерживать - вам спасибо не скажет.
Присоединюсь к остальным комментаторам, примеров перехода с питона на го в статье я так и не увидел
Несколько раз упоминается PyPy, но было бы здорово увидеть конкретные примеры, где он делает "то же самое" - так же быстро? Или может быть даже быстрее? Может всё-таки зависит от ситуаций применения?
Только начал читать пример с UserID, сразу хотел указать на эту особенность
Возможно создать пустую структуру вне пакета, даже если все поля неэкспортируемые
Вот это было одной из головных болей, когда я писал на го
Каждый раз думаешь, ну напишешь ты свой тип с конструктором для валидации возможных значений, но ведь ничего не помешает другому разработчику инстанциировать этот тип без конструктора, или заполнить его поля произвольно, избежав все проверки
Ну а проверять в каждой функции по типу IzZero - ну уж нет, извините, в пхп насмотрелся на if ($a != null && is_array($a)) и т.д., больше не хочу
Понятно, что редис тут только для примера, но всё-таки, было бы интересно посмотреть как бы решалась проблема инвалидации кеша, т.е. мы успели обновить данные в бд, но ещё не успели удалить/обновить их в кеше - в этот момент может прийти запрос и из кеша вернутся неактуальные данные
Обойтись можно, но вот например, хочу итерироваться по xml/json/т.д. файлу и выдавать объекты поочередно,э. Например, когда не знаешь размер файла, и не хочется его полностью загружать в память
Для этих целей писать свой аналог Rows Аля sql.Rows или функцию, принимающую колбек выглядит как костыли
Я думаю что там подразумевается что storeMessageType складывает полученный слайс куда-то ещё в память, и GC не придёт за изначальным мегабайтным слайсом данных, т.к. на него ещё висит ссылка в виде 5-элементного слайса, который где-то висит в памяти
Было бы интересно посмотреть на opentelemetry в сравнении с этими библиотеками
да, с одной стороны - лишняя абстракция, но с другой стороны удобство использования (универсальность и поддерживаемость). Плюс, реализацию экспортера можно написать используя викторию, и если всё остальное там достаточно оптимизировано, то по производительности сильно бить не должно
Pgx с пятой версии поддерживает сканирование в структуры по тегам
См. pgx.CollectRows
В примере со "словариком" что-то мне стало непонятно - допустим, в питоне это был массив "словариков", но в го - это уже массив структур. Можно было бы в го сделать массив мап map[string]any, и было бы так же коротко - только типизации бы не было - причем так же, как и в питоне. По хорошему, надо было бы и в питоне объявить структуру (класс), иначе тот, кто будет такой код за вами поддерживать - вам спасибо не скажет.
Присоединюсь к остальным комментаторам, примеров перехода с питона на го в статье я так и не увидел
Несколько раз упоминается PyPy, но было бы здорово увидеть конкретные примеры, где он делает "то же самое" - так же быстро? Или может быть даже быстрее? Может всё-таки зависит от ситуаций применения?
a := "" + string(foo) + string(bar)b := "" + string(foo) + string(bar)
У вас две одинаковые строчки, хотя, наверное, подразумевалось по-другому
Только начал читать пример с UserID, сразу хотел указать на эту особенность
Вот это было одной из головных болей, когда я писал на го
Каждый раз думаешь, ну напишешь ты свой тип с конструктором для валидации возможных значений, но ведь ничего не помешает другому разработчику инстанциировать этот тип без конструктора, или заполнить его поля произвольно, избежав все проверки
Ну а проверять в каждой функции по типу IzZero - ну уж нет, извините, в пхп насмотрелся на if ($a != null && is_array($a)) и т.д., больше не хочу
У вас претензия к тому, что кто-то написал содержимое функции concMap за вас и упаковал в библиотеку?
Никакого негатива не подразумеваю, просто не понял суть комметария
Понятно, что редис тут только для примера, но всё-таки, было бы интересно посмотреть как бы решалась проблема инвалидации кеша, т.е. мы успели обновить данные в бд, но ещё не успели удалить/обновить их в кеше - в этот момент может прийти запрос и из кеша вернутся неактуальные данные
Обойтись можно, но вот например, хочу итерироваться по xml/json/т.д. файлу и выдавать объекты поочередно,э. Например, когда не знаешь размер файла, и не хочется его полностью загружать в память
Для этих целей писать свой аналог Rows Аля sql.Rows или функцию, принимающую колбек выглядит как костыли
А зачем `v := arr[i]` ? В 1.22 же как раз поправили неочевидное поведение переменных в range
Я думаю что там подразумевается что storeMessageType складывает полученный слайс куда-то ещё в память, и GC не придёт за изначальным мегабайтным слайсом данных, т.к. на него ещё висит ссылка в виде 5-элементного слайса, который где-то висит в памяти