Roman K

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

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

Не всегда. Попробуй передай в пустой интерфейс и потом сделай switch type на этот интерфейс или даункастни его

nginx — это реверс-прокси
go — это яп.

в чём вопрос-то?

то как go может работать на ngnix?

nginx проксирует запрос в сервер на го, который пишет программист. Цепочка проксей может быть сколько угодно большой. Ты можешь поставить nginx -> nginx -> caddy -> nginx -> gin, никто не запрещает.

type PersonWriter[T any] struct {
  channel chan T
  jw      *JsonWriter
}

Когда нужно (а главное можно) выполнить CPU или IO bound задачи конкурентно. Вернёт ли БД ответы на, к примеру, два запроса быстрее, если их отправить в одно время, чем если их отправить последовательно — неизвестно, т.к. очень сильно зависит от контекста. В большинстве случаев — да.

Горутины — это как если бы в асинхронщине можно было выполнять CPU bound задачи и без дурацких await.

1. Открываешь сокет
2. io.Copy
Готово

Учитывая то что tcp гарантирует доставку и порядок пакетов, больше вообще не о чем беспокоиться. Кроме шифрования, если это важно

1. Нет, либо нет в 99.9999% случаев
2. Да, чтобы ограничить то, на скольких OS тредах может расположиться рантайм. Это прямо влияет на CPU-bound задачи и почти не влияет на IO-bound. Например, у тебя есть функция, которая перемножает матрицы. В канал поступают матрицы, есть 10 горутин, которые читают оттуда и умножают матрицы. Очевидно, что если GOMAXPROCS будет == 1, то все эти горутины будут жить на одном треде и будут "мешать" друг другу, задействуя не более одного ядра процессора. Если GOMAXPROCS будет 10, то каждая горутина может расположиться в отдельном ОС треде и считать себе там матрицы на "собственном" ядре.
3. Увеличится канал (sic!). Канал — это очередь. Канал без буфера — это "очередь", в которую можно добавить элемент только если с другой стороны этот канал кто-то пытается прочитать. Если такого нет — горутина будет ждать, пока этот канал кто-то захочет прочитать и наоборот, если кто-то читает канал, а с другого конца никто туда не пишет, то горутина будет ждать до тех пор, пока в канал кто-то не захочет записать. Если в канале есть буфер, то это уже становится полноценной очередью. Есть N слотов, если кто-то пришёл записать в канал, канал никем не слушается и там есть хотя бы один свободный слот — этот "кто-то" запишет в канал и пойдёт по своим делам и только если в буфере нет свободных слотов, то этот "кто-то" будет ждать, пока слот освободится. И наоборот, если кто-то слушает канал и в буфере канала уже что-то есть, то он сразу забирает первый на очереди элемент и уходит. Обычно это делают, чтобы сгладить нагрузку. Например, у тебя есть парсеры, которые что-то парсят, чтобы потом записать на диск. Но диск — штука непредсказуемая, может записать за 1мс, а может тупить 20мс. Довольно странно, если парсер будет ждать диск эти 20мс, хотя у него есть работа, которую он может выполнять прямо сейчас. Для этого можно создать буфер, куда парсер будет кидать данные СРАЗУ, а горутина, которая пишет на диск, заберёт их "когда-нибудь потом", когда диск перестанет тупить.

А что тут понимать-то? Представь, что у тебя есть два сервиса, которые общаются по JSON-RPC over HTTP. Приходит сервис1 к сервису2 и говорит, ну-ка бахни мне метод getSomethingOfSomething с аргументами вот такими. И всё это в виде JSON внутри HTTP body. Сервис2 идёт, смотрит у себя в реестре метод getSomethingOfSomething, вызывает его с аргументами и отдаёт результат. Легко? Легко. Теперь тоже самое, только вместо HTTP там HTTP/2, а вместо JSON — protobuf. То есть, два сервиса договорились, что в первых четырёх байтиках будет лежать, например, int32, в следующих восьми будет лежать float64 ну а там дальше ещё что-то будет лежать.

Легко

Хорошо живёт. Если имеется ввиду HTTP, то (обычно) на каждый запрос го пуляет новую горутину, после обслуживания запроса горутина умирает. Главная горутина живёт бесконечно долго (от запуска до shutdown'а)

Ты сначала смотришь ошибку, а потом забиваешь на неё, как будто ошибки не было и парсишь resp

Это не ошибка. Открой ЛЮБОЙ туториал по го, будь добр