Pragrammer

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

Тесты есть разные, Го примерно идет в ногу с Джавой и Шарпом, особенно в случае многопоточных нагруженных серверов. А если посмотреть сколько он потребляет при этом памяти, то даже выходит вперед по эффективности.

На Го очень просто писать многопоточность и асинхронность, не нужно думать об await-ах, каждая горутина имеет свой стек, что снимает с программиста много головной боли. Вся стандартная библиотека и большой набор библиотек с гитхаба из коробки поддерживают асинхронность и потоковую обработку данных, работать с этим сильно проще, чем в других языках. Соответственно, сложнее накосячить.

Но абстракций на Го очень мало, по сравнению с той же Джавой, он довольно бедно выглядит (что и дает простоту чтения кода). Это является минусом в определенных ситуациях, поэтому на Го стараются писать небольшие сервисы.

В итоге, легковесность горутин, легкость работы с ними и асинхронная модель из коробки (не создается тред на каждую рутину, а наоборот, рутины обрабатываются разными тредами по необходимости) привели к тому, что ниша Го это сервисы, которые упираются в ожидание ресурсов от каких-то внешних систем по сети. То есть, идеальный кейс для веб-сервера, который собирает под капотом инфу с БД и других сервисов. По сути такой сервис большую часть времени ждет ресурсов по сети, в Го это ожидание сделано очень эффективно.

Вы, фактически, пытаетесь использовать паттерн проектирования Active Record. Почитайте про достоинства и недостатки этого паттерна, посмотрите как его лучше готовить, и можете смело применять, если это подходит вашей программе и вам это удобно.

Однако, лично я считаю этот паттерн вредным, потому что он намешивает всё в одну кучу. Это моё субъективное мнение, и я вам его не навязываю. Я бы отделил мух от котлет, и оставил бы структуру чистой, т.е. только данные и какие-то методы, которые работают конкретно с этими данными из структуры, а взаимодействие с базой данных организовал бы через паттерн проектирования Repository. Т.е. мы делаем уже отдельную структуру ProductRepository, которая содержит в себе методы, принимающие и отдающие структуру Product, и уже в этих методах реализуем вызов базы данных.

Я набросаю вам простенький интерфейс для использования этого паттерна, а конкретную структуру, реализующую этот интерфейс вы уже напишете сами. Интерфейсы использовать в таких случаях считаю вообще обязательным условием. Например, так нам будет гораздо проще тестировать код, всё становится гораздо гибче. Ведь структурку Product вы сможете без проблем использовать не только при работе с базой, но и при передаче данных в другие системы, не волнуясь о лишних методах, висящих на ней. Так же вы сможете легко менять реализации репозитория, не меняя бизнес-логику проекта. (Это позволит, например, легко заменить базу данных)

package models

type Product struct {
	ID    int    `json:"id"`
	Title string `json:"title"` //Название
	Price int    `json:"price"` //Цена
}

type ProductGetter interface {
    GetAll() ([]Product, error)
    GetByID(id int) (Product, error)
}

type ProductCreator interface {
    Create(product Product) (Product, error)   
}

type ProductUpdater interface {
    Update(product Product) (Product, error)
}

type ProductDeleter interface {
    Delete(id int) error
}

type ProductRepository interface {
    ProductGetter
    ProductCreator
    ProductUpdater
}