DevMan

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

Сервер ждёт параметр countid в параметрах, а клиент передаёт его в теле запроса.

Рантайм обычно присутствует в прошивке устройства, а SDK един для всех.

Так же, как с обычным запросом - вызвать render, вернуть результат.

zero, one, two, three, four, five, six, seven, eight, nine = \
  [ lambda f = None, v = i: f(v) if callable(f) else v for i in range(10) ]

plus = lambda a: lambda b: b + a
minus = lambda a: lambda b: b - a
times = lambda a: lambda b: b * a
divided_by = lambda a: lambda b: b // a

Причин краша самих сборщиков не так много.
Чаще всего, это несовместимость версий используемых пакетов. Например, третий галп ни в какую не хочет запускаться под четырнадцатой нодой. Выход - обновиться до четвертого галпа или откатить ноду на компе до 8 (или 12, не помню уже).
Node-sass иногда вываливается с ошибкой несовместимости бинарника. Просто пересобираем бинарник.
Вчера отвалился vue-cli (давно не использовал). Я даже выяснять не стал, почему, просто выполнил npm i -g @vue/cli и все заработало. Опять же что-то там с версиями было.
Ну и т.д.

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

На GO, "православный" стек, это стандартный пакет net/http + какой нибудь внешний роутер, например chi, либо вообще не http/rest, а gRPC (если мы говорим об API).
Для БД чистый SQL, максимум какой нибудь маппер на структуру, типа sqlx(можно ещё использовать sql builder, но в IDE Goland хорошая поддержка чистого sql).

ORM очень не советую, есть конечно gorm(генерирует запросы не эффективно, N+1 при связях), для мелких проектов хватит, но вот со сложными запросами любая ORM не справляется.
Я категорически против ORM, так как за всё время моей работы в вебе, в любом проекте, самым слабым звеном всегда была ORM(долбит кучей запросов БД, когда на чистом sql это 1-2 запроса), либо программист, вместо того, чтобы написать запрос вида "SELECT SUM(amount) FROM book WHERE author = 'Petya'", достаёт все записи и суммирует это в коде(делает работу за БД + тратит ресурсы БД на чтение данных с диска и передачу их по сети).

Не нужно использовать фреймворки, это не даст опыта написания на go(как и в большинстве языков).
Go используют, где производительности других решений не достаточно, или нужна многопоточность, что фреймворки так себе обеспечивают.
Шаблоны в go практически не использую, пишу фронт на vuejs и обращаюсь к go api.
Есть генераторы документаций, но я тут не посоветую, их нужно тестировать отдельно, у каждого есть свои плюсы и минусы, сам использую другое решение(опишу в конце).

Самое главное, побыстрее понять, что на go нужно писать как на go, а не так как привыкли в других языках, потому-что, в нём нет привычных классов, строгая типизация, процесс живёт долго и могут быть race condition(гонка состояний) при многопотоке(веб сервер многопоточный), поэтому о подходах из php советую поскорее забыть.

В своих проектах(в проде), использую go только как сервис предоставляющий апи. Недавно начал использовать grpc-gateway(так как использую gRPC, но так же необходимо делать API доступное через web), проект позволяет описать всё что необходимо в proto файлах (см. gRPC), сгенерировать модели и обёртки под большенство языков + документацию в OpenAPI 2.0. Это не фреймворк, это обёртка над стандартным net/http, которая сразу валидирует и маппит данные на структуру.

Коротко:
Для новичка, советую забыть про фреймворки(они не помогут в изучении) и ORM(не эффективно).

Использовать для веб сервера:
net/http - встроен в го
chi(проще) или gorilla/mux - роутер

Для взаимодействия с БД:
sqlx - обёртка над стандартным пакетом sql, но позволяет сразу считывать данные в структуру, без ручного сканирования.

Просто представьте, что вы разрабатываете одну из следующих игр:

Бильярд
расчет траекторий шаров, с учетом приложенного к шару вектора силы и точки его приложения, вращательных моментов, эфекта торможения (гашения скорости) шаров со временем.

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

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

Космический симулятор
комплексное влияние источников гравитации друг на друга и на корабли, с учетом масс всех участвующих во взаимодействии объектов и как следствие их инерции

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

В $oldPrice и/или в $newPrice записано не число.

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

Хороший препод это не машина, как те совковые тетки которые нас учили. Это человек, который показывает как выглядит предмет, а не чистая сухая теория

может, вам нужен наставник, а не курсы?

Очевидно, надо увеличить размер шрифта.