прокидывай логер через gin.Context если хочется логер в контексте, но не делай 2 разных контекста с непонятным временем жизни, что бы в gin.Context что-то добавить обычно добавляют middleware и там добавляют что-то в контекст, и ты прям там можешь при добавлении логера добавить ему уже какие-то данные запроса, и тогда когда надо будет что-то залогировать то в логере уже будут нужные данные что бы разобраться что произошло

всем привет, кому не лень, можете накидать какие архитектурные ошибки приложения в моем репозитории и указать критичные и некритичные моменты https://github.com/sku4/corrector? спасибо)

добавьте if err != nil { log.... quit <- nil }

нет ты объявляешь один логер на уровне мейн и передаешь этот логер в мидлварю которая его кладет в контекст джиновский

каждый раз при создании конекста не надо инициализировать новый логер

нужно ли вообще передавать контекст в NewHandler, если gin строит свой контекст?

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

а на уровнях service и repository меиновский?

тогда в main нельзя так делать: repos := repository.NewRepository(ctx) ?

если брать REST, то по логике лучше чтобы контекст все-таки шел по цепочке от handler-а джиновский, а не от main, верно?

а если ты в конструкторе передаешь контекст, то значит предполагаешь что объект который ты создаешь тоже будет короткоживущим

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

да, так и есть

огромное полотно получится

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

✏️ Потоковая обработка на go1.18 В версии 1.18 языка Go появились генерики, дающие возможность писать обобщенный код, то есть код, не зависящий от конкретного типа данных. Например можно написать код, обрабатывающий потоки данных - применить к ним одну и ту же функцию, отфильтровать, просуммировать и т.д., не завязываясь на конкретные типы данных. Так как я вижу потенциал в парадигме поточной обработки с помощью итераторов/стримов и теперь есть возможность реализовать ее в Go, я решил сделать это. Эта идея появилась у меня после данной публикации. В ней рассказывается о библиотеке для языка Go для обработки данных с использованием генериков. Я попробовал эту библиотеку в своем проекте и столкнулся с следующими недостатками: настойчивое использование IO[A], который по сути представляет собой func()(A,error) то есть любую функцию, которая может вернуть ошибку. При написании кода это создает неудобства, потому что нужно всё заворачивать в этот IO и код превращается в жонглирование io.Map и io.FlatMap. Видимо это вдохновлено библиотеками с чисто функциональным подходом. Сделано это было, чтобы была функциональная чистота, что в итоге не очень (как по мне) ложится на процедурность языка Go. Stream[A] это обертка над стейт-машиной. Стейт-машина в данном случае это структура, в которой либо ничего нет (конец потока), либо значение и продолжение (следующее состояние) машины. В итоге это создает две проблемы. Первая: чтобы создать стрим, нужно создать его продолжение, продолжение продолжения и тд. Единственный адекватный способ этим пользоваться, который я нашел - это рекурсия. Вкупе с отсутствием Tail call optimization это приводит к второй проблеме. Работа с стримами переполняет стек. Модель потока как стейт-машины была построена так, что переход к новому состоянию - вызов функции. Поэтому, чтобы обойти стрим целиком, надо уйти в рекурсию на глубину, равную длине потока. Построение типа Either[A,B]. По моему скромному мнению, это вообще тип, которого не хватает в Go и который разумно реализован в языке Rust. В библиотеке этот тип это структура, содержащая и элемент типа A и элемент типа B . Плюс булевое поле как способ идентификации какой из полей действителен на самом деле. Важно то, что по сути тип Either[A,B], семантика которого элемент типа A ИЛИ B, представляется в языке как пара из элемента типа A И элемента типа B. Не совсем очевидный интерфейс. Хотя это скорее я не до конца разобрался, что и почему. Так или иначе, я считаю, что построил интерфейс более простой и прямолинейный, не потеряв в общности. Читать дальше @Golang_google

Непонятно как из этого выходить. Но с другой стороны есть же модули. У тебя в проекте го 1.19 и ты юзаешь дженерики без оф, а то что импортируешь и ещё не перешло компилируется со старой версией на интерфейсах

1.19 ?

а clang это что?

При работе с числами с плавающей запятой нужно наперед понимать, какая необходима точность, округлять до этой точности, и с помощью математических методов проверять, обеспечивает ли алгоритм требуемую точность.

А есть парочка примеров кода?

А есть парочка примеров кода?

abs(number2 - number1) < 0.001

только сравнивать надо не разность, а модуль разности (в большинстве случаев)

Умножить на 0.5 почти в 2 раза быстрее чем поделить на 2

запустил бенчи, разница до 20%

Хотя возможно это из за преобразования типов еще

Друзья, а как корректно работать с числами с плавающей точкой в GO? var f1 float64 = 0.3 var f2 float64 = 0.6 t.Log(f1 + f2) // 0.8999999999999999

Меня занесло в Go из TypeScript. Сейчас пытаюсь пропатчить кое-что. Мне надо создать новую структуру типа TLSExtension. Я в GoLand жму на Go To Implementations, выбираю один из вариантов – меня перекидывает на SupportedVersionsExtension. И я вот никак не могу понять, каким вообще образом SupportedVersionsExtension имплементирует TLSExtension? У них и интерфейсы разные, и да и указания явного нет, типа type SupportedVersionsExtension implements TLSExtension. Может кто-нибудь объяснить что это?) Ну или ссылку кинуть?

https://github.com/shopspring/decimal как вариант

методы покажи

Я правильно понимаю, что это методы?

А можно как-то заставить компилятор следить за тем, чтобы тип имплементировал все методы? Например, если я изменю интерфейс, чтобы не забыть изменить все типы?

А можно как-то заставить компилятор следить за тем, чтобы тип имплементировал все методы? Например, если я изменю интерфейс, чтобы не забыть изменить все типы?

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

А можно как-то заставить компилятор следить за тем, чтобы тип имплементировал все методы? Например, если я изменю интерфейс, чтобы не забыть изменить все типы?