почему-то Брынцалов вспомнился

А зачем переходить? Оба бизнеса весьма маржинальны и сейчас тоже.

Если посмотреть что именно пишут на go - да, канкаренси нужно. Т.е. интересно было бы посмотреть на traefik сделанный на C#/Java/Kotlin

Скорее ит исчезнет как явление, чем перестанут водкой и лекарствами торговать.

есть, пить и болеть будут всегда, независимо от наличия и развития ИТ

Linkerd V1 сделан на скала, https://github.com/linkerd/linkerd

С другой стороны, traefik - это единственный популярный балансировщик не на С/С++

пошел ОПРОВЕРГНУТЬ тебя при помощи envoy, а он - тоже на с++ ))

И спорить между собой с применением подручных предметов в качестве оружия дробящего действия.
Так что полный список недооцененных специалистов: Хлебороб, Винодел, Доктор и Адвокат

Адвоката могут заменить на автомат и тогда нужны будут другие спецы :)

Если дотнет, то нужно смотреть, например, бенчмарки TechEmpower и Yarp (реверс прокси на дотнете), https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-release/ (там есть TechEmpower бенч - ссылка), https://github.com/microsoft/reverse-proxy/issues/40 тут есть сравнение с HAProxy, Nginx, Envoy местечковое. Ну и версии нужно смотреть последнии, говорят что вот ту перехо на .net6 azure съэкономил чего то там в миллионах баксов (или миллион?) https://devblogs.microsoft.com/dotnet/azure-active-directorys-gateway-is-on-net-6-0/ . Сорри, набор ссылок не то чтобы упорядоченный. Ну т.е эти специфичные или синтетические кейсы, но опр. представление может вполне дать. Тот же Озон просто имеет гоу и дотнет разрабов, какие были разрабы под конкретный сервис, на том и запилили, на сколько я знаю.

В конце цепочки все равно будет кто-то, кто разведет особо ретивых по углам.

Ага. Я тоже думал, что он на го, пока пару недель назад не сходил посмотреть

Посмотреть - это не только perf, но и код.  Т.е. я смотрю в https://github.com/microsoft/reverse-proxy/blob/main/src/ReverseProxy/Forwarder/StreamCopier.cs
который по факту цикл из read+write и выглядит это всё страшно(особенно если почитать комментарии вроде "Based on performance investigations" :)

На go это будет всего несколько строчек, а писать перекладывание байтов между стримами не надо, т.к. всё уже написано в стандартной библиотеке.
Если у стрима в который пишут реализован WriteTo, то может быть подтянул оффлоад через sendfile(2).

AFAIK, какое-нибудь копирование файла тоже оффлоадится в copy_file_range(2)

А вы на дотнете пишете? Ну и в целом, даже не вдаваясь в код, оптимален ли тот код и т.д., есть ли в нем боттлнеки? Команда дотнета оч. серьезно вкладывается в перформанс, очевидные места давно бы выпилили. Вплоть даже до оптимизаций за ради TechEmpower

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

Ну, на kotlin+graal было бы примерно то же )

Ну ок, вот тут примерно тот же код https://github.com/microsoft/reverse-proxy/blob/ca46305dc23519598d831c0fca64e0136476c89b/src/ReverseProxy.Core/Service/Proxy/StreamCopier.cs#L36

И это примитивный кейс, где байты просто перекладываются между парой стримов.

В жизни часто надо сходить в несколько разных систем(2-3 апи, пару бд) параллельно  и либо дождаться от всех ответа и собрать результат, либо выдать то что первое ответило и остальные отменить. Потом к этому добавляются рейтлимиты и таймауты для каждого api.

Я вот выше спросил, вы пишите на дотнете, понимаете что там за операции про ArrayPool<byte>.Shared.Rent(DefaultBufferSize);, смотрели ли тесты на перф?

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