__>jvm явный признанный лидер по scalability / perf.
Я бы тут разделил jvm и scalability / perf. Многие проекты написанные на java очень аккуратно и hardware-friendly долгое время являлись эталоном того как относительно кросс-платформенный и высокоуровневый код, может при этом показывать высокую производительность. Были версии jvm "заточенные" под определённые сценарии, которые позволяли выжать ещё больше. Но этот высокопроизводительный код не является "красивым" или написанным "с использованием всех фишек языка". Чаще всего это c-like код, с минимумом выделений памяти, пулами для часто используемых типов объектов, и т.п. Да такое работает быстро, но никакого отношения к jvm не имеет. Так аккуратно можно писать практически на любом языке. Но это нифига не "скоренько накидать, лишь бы работало".

Также врождённые проблемы jvm (отсутствие value-типов, "неправильные" generic'и) — становятся кандалами, замедляющими развитие и возможности оптимизации скомпилированного кода. Их пытаются решить тем же project Valhalla, но до самого решения ещё далеко, до его mass adoption ещё дольше, обновления существующих библиотек которые могут получить выигрыш в performance придётся ждать наверное до 2030-го.

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

В .NET сама парадигма async/await и стандарт использования Task<T> появились очень давно. Соответственно вся экосистема, все открытые или внутренние проекты используют одно и то-же tasks api. И как раз оно каждый релиз вылизывается всё больше и больше. Тоже есть какие-то родовые проблемы, которые, видимо, останутся навсегда. Но бьющих именно по производительности относительно мало закопайте делегаты!.

К примеру ни kotlin ни java вообще насколько я понимаю, не позволяют писать, alloc-free асинхронный код на future/task. В современном .NET это ещё с приседаниями, но уже можно делать. Более того, можно написать библиотеку которая будет отдавать клиенту alloc-free tasks, и при этом клиент сможет её использовать вообще не заметив отличий от обычной.

Для числодробильного кода в C# тоже очень много всего добавили. Но если это расписывать, получится уже не пост на форуме, а какая-то статья.

__>и новые языки вроде kotlin позволяют ускорить разработку. в чем смысл си щарпа в таком случае?
Небольшой знаток kotlin, но когда смотрел его последний раз — например вменяемого linq там не было. Функции map, filter, и т.п. я вменяемым linq не считаю. Т.е. по сравнению с java kotlin явно ускоряет разработку, а сравнивая с C# — большой вопрос. Многие вещи которые в C# можно закрыв глаза на оптимизацию сделать "лишь бы работало", тоже отсутствуют, например dynamic (для jvm).
Также по отзывам тех с кем работал (сам на kotlin не пишу, опять же) у kotlin есть свои корутины (и они вроде даже быстрее встроенных в JVM). Но при этом возникают сложности когда нужная библиотека для jvm вроде бы есть, но написана давно и на java. Соответственно использует устаревшие подходы к многопоточности, встроенный или даже самописные аналоги Future (для той самой performance), и т.п. В общем использовать можно, но уже не так удобно.

В scala сахара позволяющего писать продуктивный код больше, но из-за особенностей самой scala код написанный со всеми плюшками — после компиляции очень часто безумно неоптимален и создаёт огромный memory traffic на временных объектах. То есть high perf код без оглядки на "во что оно там развернётся-то?" не напишешь.

__>вы сказали — "если надо получить стабильное решение задачи и быстро то современный шарп имеет сотню очков форы". в чем это проявляется?
Долгое время программируя на C#, как и на других языках, был некий tradeoff. Что-то типа "тут используем весь доступный синтаксический сахар, пусть тормозит, но что-то зарелизим уже завтра" vs "тут надо заморочиться, вспомнить кучу глав из Writing High Perf .NET Code, и потом профайлером".
Последние годы команда .NET Core старательно подкручивает и оптимизирует даже между major релизами, так что на оптимизации можно забить всё чаще, и всё чаще встречаются случаи когда старые паттерны оптимизации больше не дают эффекта.
Собственно в той же теме

Автор: hi_octane
Дата: 02.04.20

я писал, что один из проектов мы начинали по сути как PoC. Изначально идея была разбить на части которые можно будет потом независимо дооптимизировать к релизу. Первую редакцию написать самым скоростным и простым образом. Получить некий эталон, на котором гонять юнит и интеграционные тесты. А потом доводить до ума компоненты по одному. И времени было заложено соответственно. Но случилось так что этот самый концепт-код выдал нужные скорость и стабильность сразу. Учитывая объёмы траффика которые через него проходят каждую секунду, и то как это было написано, такого тупо не должно было быть.

Одновременно с этим в C# постоянно добавляют ништяки для микро-оптимизаций. Т.е. если понадобится ускорить раза в 2 — то вполне есть понимание что делать. И это всё ещё будет читабельный и типизированный C#.