calculator212

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

Для этого есть worker pool, не нужно просто так бесконтрольно запускать горутины для такого. Суть в том, что ты создаешь воркер пул, в котором определяешь число горутин, после при помощи каналов шлешь в него таски на оплату

Просмотрев несколько тестов go vs java/c++/c#, то в большинстве из них он имел самое высокое время выполнения теста

В целом хотелось бы ссылки на тесты увидеть, т.к. можно абсолютно без проблем найти тесты которые будут показывать обратные результаты(что само собой не говорит об их корректности).

в том же сравнении с веб сервером на spring go имеет время ответа сервера (в одинаковых условиях) до 20% большее чем у java

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

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

Из плюсов то, что го удобно собирается в один бинарник со всеми зависимостями, простой в установке. Для веба имеет удобную библиотеку, которая позволяет писать на нём без доп фреймворков. В целом по моему опыту, тем кто пишет на языках типа явы он им не очень нравится, т.к. по сути людям приходится менять стиль написания кода, а нравится больше тем, кто пишет в стиле Си. В общем если вы любите использовать много абстракций и +/- сложное ООП, то го скорее всего не зайдёт, т.к. в нём придется перестраивать мышление.

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

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

Пытаюсь вернуть все имеющиеся модели из GORM, но сталкиваюсь с ошибкой

Желательно бы на структуру посмотреть

Error #01: json: unsupported type: func() time.Time

По описанию ошибки можно понять, что маршалеру не нравится то, что в поле стоит функция а не значение

Ведь соединений может быть как 2 так и 1_000_000+, что уже будет плохо и перебор всех элементов такой Map на каждом создание сообщения будет не очень хорошо сказываться, а так же, в примере это групповой канал, который может содержать так же от до 2 до бесконечного числа пользователей.

В общем это вполне рабочая ситуация. Mail ru делали что-то похожее и для таких ситуаций написали свою либу для работы с вебсокетами, тут статья, также вроде у них было еще видео на highload, где также объясняли проблемы и пути решения

правильно ли изменять тип переменой (в данном случае id со string на uuid) в хэндлере, или это необходимо делать в сервисе?

Зависит от ситуации, если без этого никак и особых проблем от смены не будет, то можно сразу в хендлере поменять. Если от этого изменения будут ломаться внешние клиенты, то тут придется уже по другому обходить эту проблему, например добавлять v2/api.

Здравствуйте я не понимаю как читать документацию?
Пишу в строке : документация c++
Выдает официальный сайт Майкрософт : https://learn.microsoft.com/ru-ru/cpp/cpp/?view=ms...
А дальше что читать?В каком порядке читать?

Так документацию вряд ли кто-то читает. Документацию обычно читают по конкретным вопросам. Т.е. либо человек примерно знает что ищет, либо он хочет уточнить какой-то вопрос. А читать 1000+ страниц сухой документации особого смысла нет

тут

но послушав 5 или 6 лекций по основам языка, я понимаю, что у меня абсолютно нет идей как применить эти знания на практике.

Прикол плюсов в том, что у плюсов наверное один из самых высоких порогов вхождения для написания какого-то полезного кода(по крайней мере среди си-подобных). Плюсы это прям игра в долгую:
1) сначала ты учишь базовые плюсы, которые не касаются стандартов, изучаешь что такое указатели и чем они друг от друга отличаются например int *const от const int * от const int *const и т.д. (непередаваое удовольствие в общем), изучаешь как работают указатели на практике и как работает память, пишешь сам базовые структуры хотя бы list, queue и пары других вещей, мб простую map сделаешь.
2) на плюсах из первого пункта почти никто не пишет сейчас, но они всё равно нужны для понимания языка поэтому дальше изучаешь стандарты c++11 - c++20, основные контейнеры, итераторы и т.д. немного можно коснуться многопоточки, чтобы понимать зачем оно вообще нужно
2.1) Изучение предметной области в которой хочешь работать, плюсовики сильно отличаются друг от друга, т.е. те кто пишут сетевые драйверы обычно не шарят за геймдев и сам код у них будет сильно отличаться, поэтому тебе будет нужно определиться с этой областью и уже изучать ее
2.2) Также тебе придется узнать, что такое системы сборок, т.к. многие либы в плюсах не устанавливаются одной командой как в питоне, а просят скомпилировать их и установить отдельно в системе и установить самому, и тебе самому придется для сборок нормальных проектов освоить хотя бы Cmake и make.
2.3) С кроссплатформенностью сейчас стало гораздо лучше (спасибо c++17 что добавил общее апи для работы с файлами), но если тебе что-то специифическое под винду понадобится, то тебе считай придется учить отдельный язык для винды (на мой взгляд питон было изучать чем апи винды)
3) В общем если ты пункты выше пройдешь, то скорее всего уже сам сможешь найти, что тебе делать дальше

Суть вопроса: есть ли какие-то пет-проекты для плюсов, которые можно реализовать после прохождения новых тем, или может быть плюсы уже не самая актуальная тема и стоит посмотреть в сторону других языков(может Rust?)

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

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

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

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

Можно сделать сервис авторизации который будет уметь работать с различными вариантами авторизации. В целом это обычное дело, когда один сервис использует JWT, второй куки, а третий передает Bearer в хидере и сервис аутентификации с этим уживается

игра должна уметь TXT-файлы (в идеале SCV или JSON, но можно и TXT)

Что это значит? Уметь делать или сохранять в txt, экспортировать? Непонятно что за пункт.
Первые два пункта никак не связаны с игровым движком, это реализуется стандартными средствами языка.

3. это должен быть небольшой 2D движок, а не Юнити/анрил и тд

Есть godot, если не нравится, то можно другой выбрать, у RPGMaker относительно узкие области применения, под капотом там вроде js, так что запросы на сервер отсылать можно будет

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

resp, err := http.Get("http://example.com/")
if err != nil {
	// handle error
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)

Вы сначала проверяете на ошибку и если ошибки нет, через defer закрываете соединение.
Второе - вам стоит почитать про http.Transport и некоторые особенности клиентов, т.к. даже соединения которые должны были закрыться могут висеть очень долго

tr := &http.Transport{
	MaxIdleConns:       10,
	IdleConnTimeout:    30 * time.Second,
	DisableCompression: true,
}
client := &http.Client{Transport: tr}
resp, err := client.Get("https://example.com")

Также желательно в самой системе посмотреть таймауты и настройки для tcp соединений (это не так часто нужно но если у вас много запросов клиентских, то может помочь).
Также можете поискать альтернативные клиенты и пулы клиентов, а также как правильно реюзать соединения

Получается так что в idleConnWait = {map[http.connectMethodKey]http.wantConnQueue} постоянно записываются новые элементы,

В целом есть вероятность, что "утечка" тут, но это очень легко проверить даже без профилировщика, т.к. эта мапа уникальна для каждого клиента, то можно напрямую проверять сколько клиент занимает памяти, но на самом деле есть большая вероятность, что проблема в том, что вы неправильно используете client, т.к. эта мапа периодически очищается и расти она должна только до определенного значения

- запись в выходной канал queuedData[i]

Вроде же это слайс структур fanInRecord, из каналов так только pause, видимо нужно добавить в структуру канал и туда писать, но мб я что-то не так понял

- разблокировка исходного канала с помощью pause."

Какой из каналов тут исходный? Но в целом механизм паузы реализуется либо через два канала pause/unpause, либо можно использовать один канал, который будет менять значение булевской переменной, которая определяет можно ли сейчас писать в канал или нет

в 2013 на английском и только в 2016 году на русском, а это почти 10 лет назад,

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