На том языке из более менее быстрых, которые знаешь ты и твоя команда. Технически то, что называют Highload вполне может работать на Java, Scala, C++, Go. Но сначала определись, может у тебя тормозом будет архитектура, СУБД, какой-то IO?

erlang

Себе я бы взял Go. Именно для таких целей его и проектировали. И сторонних фреймворков на нем уже куча, что совсем облегчает дело.

Максимум можно выжать из С и С++. Лично так «сделал» джавера именно на такой задаче. Но, если ты с этими языками на «вы», то однозначно бери что-то другое, чтоб потом не рвать волосы. И выше правильно сказали - сперва оцени, где у тебя узкое место.

erlang

Форумный теоретик detected.

kPHP жи

Паша Дуров рекомендует

Как раз таки с C++ и С хорошо знаком но писал в основном прикладное ПО. Пожалуй именно этим путем и пойду.

Erlang + C/C++.

erlang

Форумный теоретик detected.

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

особенность его архитектуры заточена под большое количество одновременно обрабатываемых запросов
я не ожидал от лора чего-то иного - лор все так же трындит про плюсы и затыкает им каждую дыру

Еще один теоретик, erlang тормозной сам по себе, и упрешься ты не в количество соединений, а в скорость кода. А статьи, где erlang кого-то там обгоняет, рассчитаны как раз на таких теоретиков, которым легко и просто навешать лапшу.

Кстати, что-то живое на erlang, вроде CouchDB, использует внутрях для узких мест С, и даже так катастрофически сливает аналогам:

https://www.arangodb.org/wp-content/uploads/2012/08/results_big.png

В СouchDB нет кэширования, емнип, данные сразу начинают писаться на диск. Не для хайлода БД писалась, не для него.

В СouchDB нет кэширования, емнип, данные сразу начинают писаться на диск.

Если после каждой записи нет fsync (а с ним все было бы вообще печально, так сделано по дефолту в SQLite, например), то кэширование на себя берет ОС.

C++

C

Как варианта не хватает Common Lisp.

Емнип, то sync там после каждой операции записи.

Емнип, то sync там после каждой операции записи.

ТИП, это очень дорогая операция и статистика была бы гораздо хуже.

Under normal circumstances, your document is appended to the file, but not sync'ed, along with any other writes from other clients. Within one second, all of those writes are sync'ed and the header is updated.

А что ты будешь делать, когда твой код на сях/го/whatever перестанет справляться с нагрузкой? Думай сразу про горизонтальное масштабирование.

Все лоровские тимлиды пишут сразу гибкий, вертикально и горизонтально масштабируемый код на С/С++, без утечек памяти. Сейчас придет царь и скажет что RPC вообще не нужно, ибо он может на локалхосте на сишечке все посчитать.

Все лоровские тимлиды пишут сразу гибкий, вертикально и горизонтально масштабируемый код на С/С++, без утечек памяти

Не стоит передергивать, все зависит от задачи, бывает и так, что действительно проще написать код на С/С++, если используются специфичные библиотеки и требуется максимальная эффективность. Ну, а если весь сервер - просто прослойка между СУБД и пользователем (типичная задача в ынтерпрайзах), то конечно лучше взять, например, Java, тем более, что там это давно отработано чуть ли не до копипасты.

Я говорил в рамках конкретного топика, т.е. «highload rest». Вообще, если под задачу есть DSL, то, имхо, его первым делом и нужно попробовать использовать. Если у этого DSL'а есть средства для интеграции с кодом на С/С++ для участков кода со специфическими требованиями: производительность, специфика платформы или задачи, то использовать их (С/С++) в единственном лице не вижу смысла.

Вообще, если под задачу есть DSL, то, имхо, его первым делом и нужно попробовать использовать

Видел примеры, как на Java достаточно простую задачу решали именно с помощью готовых по-сути DSL, получали компактное решение, все супер, кроме того, что в секунду обрабатывалось 10-20 запросов. Но не беда - ведь решение уже заранее готово к масштабированию...

Если у этого DSL'а есть средства для интеграции с кодом на С/С++ для участков кода со специфическими требованиями: производительность, специфика платформы или задачи, то использовать их (С/С++) в единственном лице не вижу смысла.

Несомненно, проблема лишь в том, что обычно такие DSL не предназначены «для интеграции с кодом на С/С++», особенно, если на С/C++ организовано хранение и загрузка данных. А использовать, например, Java + tomcat + еще что-нибудь, просто, чтоб заменить библиотеку на плюсах или С, это мягко говоря неразумно и заставит вспоминать тебя самыми нелестными словами.

Год назад взял бы Go, но сейчас бы не долго раздумывая взял кложуру :-)

CouchDB написана на эрланге. Без вставок C, не надо.
https://github.com/apache/couchdb

CouchDB написана на эрланге. Без вставок C, не надо.
https://github.com/apache/couchdb

У вас src отклеился. А если его приклеить назад можно найти:

https://github.com/apache/couchdb/blob/1.6.x/src/couchdb/priv/couch_ejson_com... https://github.com/apache/couchdb/blob/1.6.x/src/ejson/encode.c

и т.п.