Как мы суслика яблоками кормили или эффективный backend на Go для iOS

Я ж явно указал три разных роута. Это принципиально, уж простите:

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

// схема запроса к апи
type ApiRequest struct {
    ReqFoo *ReqFoo `json:",omitempty"`
    ReqBar *ReqBar `json:",omitempty"`
    // и т.д.
}

//ApiRoute - просто кортеж
type ApiRoute struct {
    pred    func(*ApiRequest) bool                 // проверка формы запроса
    handler func(http.ResponseWriter, *ApiRequest) // ваша бизнес логика
}

//маршруты к апи
var apiRoutes = map[string]ApiRoute{
    "/foo": ApiRoute{
        func(r *ApiRequest) bool { return r.ReqFoo != nil },
        handleFoo,
    },
    "/bar": ApiRoute{
        func(r *ApiRequest) bool { return r.ReqBar != nil },
        handleBar,
    },
    // ...
}

//инициализация маршрутов апи
for path, _ := range apiRoutes {
    router.Get(path, handleAPI)
}

func handleAPI(w http.ResponseWriter, httpRequest *http.Request) {

    var apiRequest ApiRequest

    if e := json.NewDecoder(httpRequest.Body).Decode(&apiRequest); e != nil {
        handleError(w, httpRequest, e)
        return
    }

    x, ok := apiRoutes[httpRequest.RequestURI]
    if ok && x.pred(&apiRequest) {
        x.handler(w, &apiRequest)
    } else {
        handleUnknownRequest(w, httpRequest)
    }

    return
}

У меня в примере Ok — не от монады Result, а от http-заголовка «200 OK».

Хттп-ответ — та самя трихомонада, только не правильная и неудобная в использовании :-) Ваша prepareBar(json.data) может фэйлиться при анализе json.data, и в этом случае у вас будет что-то вроде Ok (BadRequest(resp1)), что на самом деле BadRequest(resp1). В Гоу не надо задумываться о таких вещах, соответственно ошибиться невозможно: если существует возможность ошибки вычислений, то функция возвращает два значения — полезные данные и ошибку. Вообще функции в гоу могут возвращать произвольное количество значений, а не одно, как в C#.

И это я ещё молчу про то, что на практике prepareBar(json.data) — асинхроннная, то есть код куда сложнее, чем тот, что вы привели. А в Гоу асинхронщина не нужна, соответсвенно там нет уродливых обёрток на подобие Task<T>

Дженерики — явно далеки от магии и коду только помогают.

Господин Брэд Фитцпатрик обещал джененрики в Гоу 2.0. Не думайте, что дженереки — это бесплатная фича. Расплата за дженереки в С# — это снижение скорости копиляции/сборки/jit-компиляции, усложнение структур данных, доп. когнитивная нагрузка, разрастание скомпилированных бинарников. И только в паре процентов случаев использование generic’ов дает реальный выигрыш в качестве кода. В 99% случаев это стандартный набор контейнеров и алгоритмов для произвольных типов данных. В Гоу их не добавляют не потому, что гоферы упоротые, просто пока ещё не нашли способа сделать это безболезненно.

Уж явно менее магические, чем рефлексия.

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

Смешно, молодец)

Посмотрим, кто будет смеятсья, когда вам выдадут ТЗ на разработку бэкенда к игре на Гоу :-) Go идеально подходит для сервера многопользовательской игры по следующим причинам:

• простая и эффективная работы с сетью. Не нужно никаких мозгодробильных epoll’ов с лапшой из калбэков на конечных автоматах;
• один сервер может с легкостью держать десятки или даже сотни тысяч клиентов. При этом каждый клиент обрабатывается простым линейным кодом в отдельном наборе горутин, а не притянутыми за уши акторам с многослойными бесполезными абстракциями, затрудняющими понимание кода;
• Задержки gc в последних версиях go не превышают 0.1 мс, в то время, как в C# они достигают нескольких сотен миллисекунд. С такими задержками в C# можно писать лишь сервера для пошаговых стратегий.

А если эффект параметризированный и вычисляется от кучи разных входных данных — баффов и дебаффов?

значит объекты баффов и дебаффов будут применены для модификации объекта stoneSkinn (или squad). Логично?