Привожу цитату Дмитрия М., одного из членов программного комитета Golang Conf.

Короче: нету highload, это исключительно СНГшный термин — на западе такой термин вообще никто не понимает, и я не просто так кинул ссыльную на книжку, ибо правильный термин все же data intensive applications. В общем случае такие сетевые приложения возникают в двух случаях:

  1. Когда у нас много действий, которые нужно произвести за очень ограниченный промежуток времени.
  2. Когда у нас много-много запросов и ограниченное число ресурсов.

И тут речь в первую очередь про деньги. Причем в двух вариантах — деньги клиентов и деньги компании. В первом случае трейдинговая платформа не может позволить себе обрабатывать запрос минуту — это убьет любую логику на бирже. Во втором компании дешевле заставить работать систему быстрее, переписав код, нежели докупив еще несколько стоек в ДЦ (или несколько ДЦ в случае Гугла). Т. е. мы говорим про случай, когда выигрыш в производительности даже в 1–2% — это больше стоимости содержания штата крутых разработчиков.

Так вот, и вот тут начинается важное: когда мы начинаем подбирать языки под такие сценарии, мы начинаем смотреть на пропускную способность, latency, потребление памяти. И у всех скриптов с этим дела обстоят, мягко говоря, плохо, т. к. в отсутствии строгой статической типизации, минимального числа возможностей для динамического изменения кода во время исполнения, компиляторам приходится быть консервативными в оптимизациях. Плюс, если он есть, включаются еще затраты на сборку мусора (которая тоже не бесплатная даже в языках с подсчетом ссылок и ручным управлением времени жизни) — и тут GC может быть ориентирован под совсем другие сценарии, нежели нужные нам. Поэтому, например, самый оптимизированный код на Rust будет быстрее самого оптимизированного кода на Go: система типов плюс годы работы над бэкендом компилятора позволяют генерировать гораздо более оптимизированный код.