Сергей Горностаев

А теперь возьмите не синтетический тест, а реальную задачу сложнее перекладки json'ов, например, с шифрованием, дайте серьëзную длительную нагрузку и посмотрите латентность по процентилям.

https://hjr265.me/blog/adding-icons-for-go-built-w...

Или это просто такое количество кодовой базы на PHP накопилось, которую все дружно решили переписывать на Go

Скорее всего.

если да, то почему именно на Go?

Если компания решилась вложиться в переписывание продукта на другом языке, то у неё на это точно очень веские причины, вероятнее всего - проблемы производительности. В этом случае Go - очевидный выбор. Python, Ruby и JS не дадут никакого выигрыша относительно PHP. Хоть на языках из мира jvm и .net можно писать высокопроизводительный софт, но они скорее решают проблемы сложности огромных кодовых баз. С++ и Rust очень сложны и для прикладного софта применяются только в крайнем случае. Всякая экзотика, типа Erlang, Elixir и Haskell - это вообще редкий случай в энтерпрайзе. Go же одновременно очень прост и ориентирован на высокую производительности.

Чаще всего такие задачи реализуются не на Go.

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

Читать учебники и документацию, практиковаться, гуглить. Всë, как с любым другим языком, Go не особенный.

Курсы не нужны. Нужен учебник и пет-проект.

SQLite

какие задачи решает Go настолько хорошо, что это нужно писать именно на Go, а не на PHP

https://ru.wikipedia.org/wiki/C10k

Во-первых, ИБ - это больше бумажная работа, чем программирование. Во-вторых, если под ИБ предполагается своего рода штатный хакер, то смотреть надо в сторону C. В идеале ещё и с Ассемблером.

Во-первых, язык влияет на производительность программистов, а не программ. Узким местом может стать платформа, в вашем случае виртуальная машина CPython. Но при разработке сетевого ПО в целом и web-приложений в частности главный тормоз - это ввод/вывод. Издержки на него на порядки превосходят издержки на интерпретацию, так что последняя практически не влияет на производительность. В то же время CPython хорошо справляется с вводом/выводом с помощью Asyncio и способен решать проблему c10k.

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

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

Вышка не обязательна.