Александр Павлюк

У вас проект не инициализирован, надо сделать go mod init имя
Вы пытаетесь добавить модуль как это делалось лет 7 назад, когда в Го не было модулей. Теперь надо все проекты делать через модули.
https://go.dev/blog/using-go-modules

После того как сделаете init, добавляйте модуль через
go get github.com/go-sql-driver/mysql@latest

Запускать рендер в Блендере в headless-режиме.

Это штатная фишка у Блендера
https://docs.blender.org/manual/en/latest/advanced...

Фабрику вообще не принято использовать в Го. Используйте вместо нее обычные конструкторы. Функцию New() в пакете, где у вас описан пользователь.

Когда с пользователем нужно что-то сделать, делайте это не методом самого типа пользователя, а функцией в пакете, который будет отвечать за проведение действий с пользователями. Если у вас разные пользователи и надо делать какую-то общую логику с ними, то пусть функции пакета, где будут действия с пользователем, принимают интерфейс, а не конкретный тип.

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

В вашей задаче нет циклов, почему в вопросе упоминается цикл?

У вас main написан так, что передаваевая в checkNil переменная никогда не будет nil.

Внутри checkNil вы перепутали равенство с неравенством. v != nil значит "v не равно nil", а у вас в этом случае выводится, что переменная пустая, хотя должно быть наоборот.

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

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

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

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

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

Prometheus это про метрики

Grafana это тоже про метрики

Судя по коду, вы сделали поддержку трейсинга в вашем приложении, а чтобы смотреть трейсы, нужно развернуть интерфейс Jaeger. https://www.jaegertracing.io/

Есть статья на эту тему https://habr.com/ru/articles/710644/

Основная проблема в том, что рейтрейсинг в том виде, что вы описали, хорошо работает разве что в мире, где все состоит из зеркальных поверхностей. Но в реальном мире практически все поверхности рассеивают свет в случайных направлениях в какой-то степени. Поэтому вам не хватит одного луча на пиксель, придется усреднить много лучей, чем больше лучей усредните, тем меньше будет шумов на картинке. Или использовать какие-нибудь хитрые вероятностные модели (Importance sampling, например).

Без этого всего освещение и поверхности не будут выглядеть реалистичными.

Докер ничего не знает про http, он только пробрасывает tcp-коннекты до вашего приложения. Так что проблема точно где-то в вашем коде. Скорее всего какой-то из конфигов локально у вас подключается, а в докер не пробрасывается, поэтому какие-то из ограничений внутри приложения не снимаются.

502 Bad Gateway обычно вылезает, когда ваше приложение запрос куда-то перенаправляет. Вы с файлом что делаете, сохраняете на диск или куда-то отправляете?

func main() {
	cmd := exec.Command("ffmpeg", "-i", "input.ogg", "output.mp3")
	res, err := cmd.CombinedOutput()
	if err != nil {
		fmt.Println(string(res))
		fmt.Println("error executing command:", err)
		os.Exit(1)
	}
}

Естественно, на системе должен быть установлен ffmpeg, потому что тут вызывается внешняя программа.

Вы не сможете себе в портфолио добавить микросервисную архитектуру просто написав ее в пет-проекте. Настоящие микросервисы можно пощупать только на масштабах больших компаний и их инфраструктуре, так что устраивайтесь джуном/стажером в какой-нибудь Авито или Озон.

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

Сделайте лучше хороший проект-монолит, отработайте навыки языка, БД, развертывания, гита, итд... на одном проекте. Будет гораздо полезнее.

В Го по-умолчанию переменные передаются по значению (то есть, копируются на стеке), но есть нюансы.

1. Мапы и каналы всегда передаются по указателю.
2. У слайса на стеке только дескриптор, так что он копируется, но данные, на которые слайс указывал, остаются там же в памяти, где и были.
3. Если вы явно передаете указатель, то тут все очевидно.
4. У интерфейсов копируется дескриптор, но т.к. в дескрипторе указатель, то тут все как со слайсами.