С++ for web development

Это фантастика.

А зачем, если тот же b9 компилирует весь твой быдлокод в машинное масло. Для питона есть руру, для hph есть кокой-то нирнор, jaba воще из коробки это умеет, и эту фичу даже впаривали лохам за деньги.

Просто я лузер, и не знаю сей. Так-то бы, конечно, юзал бы и в вебе и везде, только чтобы повысить своё ЧСВ, и обзывать всех неудачниками, не умеющих делать сайты на си.

Один чувак на хуябре рекламировал самописный онлайн-чат на C++. Ну я сходил туда один раз, увидел смайлы-колобки, как в квипе, и сделал SIGQUIT.

ИМХО

Использование компилируемого некроссплатформенного языка в вебе не имеет смысла. Вдруг сервер обновлять будете с x86 на amd64? Или с GNU/Linux на FreeBSD? Придется все перекомпилировать, а от этого могут появиться неочевидные баги. Только скрипты, только хардкор :)

кто из гигантов использует

Facebook, но там во-первых C, во-вторых, он генерится из PHP

Правда создатель(-ница) HipHop вроде трап.. окуратней.

Практика показывает что современные веб-фреймворки развалятся даже при обновлении пакетной базы. Так что один хрен.

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

Если ты задаёшь такой вопрос, то похоже твоим заказчикам пофиг на чём ты делаешь сайты, лишь бы работали. В таком случае могу посоветовать не тратить время на С++, а освоить D. На нём есть веб-фреймворк http://vibed.org/.

http://cppcms.com/
Оно вроде даже живое.

Практика показывает что современные веб-фреймворки развалятся даже при обновлении пакетной базы

В смысле при обновлении версии интерпретатора и/или сервера?

http://www.webtoolkit.eu/wt

Wt

http://phalconphp.com/

THE FASTEST PHP FRAMEWORK
Phalcon is a web framework implemented as a C extension
offering high performance and lower resource consumption.

Не стоит. Мало кто использует.

стоит использовать либо для выдачи данных через REST, например, или в качестве концептуального решения, вроде xojo, но там С++ «под капотом»

На go вроде сейчас модно писать всякие web-поделия.

Интерпретатора и/или местных единиц библиотек.

Использовать C++ для разработки именно фронтэнда не имеет смысла. Т.е. MVC модель в привычном понимании всяких RoR, Django etc тут не подойдет. На прошлой работе были проекты с фронтэндом на JavaScript и бекэндом на C++/fast-cgi.

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

Там просто инфраструктура не того уровня для веба. Но зачем это может быть нужно? Высокопроизвоидительные числодробилки? Так они не торчат в веб, они работают во внутренней сети, а в веб выдает данные все равно что-то более вменяемое для этой задачи.

Wt
</thread>

Тоньше, виктор, еще тоньше

Тоньше, виктор, еще тоньше

Кто такой виктор, да ещё с маленькой буквы?

Мне правда интересно.

Wt </thread>

А прочитать начальный пост не судьба, видимо.

ну а других вменяемых фреймворков-то вроде и нет, только наколенные поделия какие-то

http://www.youtube.com/watch?feature=player_detailpage&v=B9owuoiOHuU

например, высокие RPS для обработки специальным образом подготовленных данных (например, закэшированных, псевдодинамика всякая), всякий умный concurrency и прочий лютый бесчеловечный хайлоад (вплоть до того, чтобы под нагрузкой руками разруливать io и планировщики линукса). А еще есть всякие MPI и прочие кластеры, можно зафигачить на кластере обработку сообщений вместо rabbitmq

А потом все это запихнуть в HTTP и на порядок дольше отправлять в чей-то тормознутый канал и браузер? То что вы говорите, не фронтенд и бекенд, именно там и есть С++ иногда. Но с какой-то жабой или пайтоном оно обменивается данными потом отдельно.

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

Интересно было бы услышать современные ответы на тему: «идиотство или нет»

идиотство. Мы постепенно движемся к абстракциям всё более высокого уровня, а C++ в этом смысле регресс. Конечно C/C++ нужен и годен, но только там, где нужны и годны абстракции низкого уровня. За низкий уровень тоже нужно платить, и не дёшево.

Конечно, можно писать на C++ как на пхп, используя Over9000 готовых функций, вот только чем это лучше пхп?

и на порядок дольше отправлять в чей-то тормознутый канал

ну, я вот захожу на LinkedIn или ЖЖ, и они тормозят. И дело явно не в моем 100-мегабитном канале. И не в магистрали, могу показать трейс. Сам сайт тормозит.

глянь на всякие серверсайдные фреймворки. в которых на каждое действие на клиенте дергается серверный колбэк. Старый Vaadin, например (нового не пробовал). Под нагрузкой сервак становится раком. Я юзал викет - там то же самое было. А если там REST (привет, Playframework), то на каждый запрос нужно собрать контекст и потом куда-то его деть до того, как GC перестанет с этим справляться...

Насчет сокетов - хорощая идея, надо попробовать...

Если веб-приложение тормозит то тут всегда есть ряд факторов

1. Долго закачивается. Решения gzip, SPDY

2. Долго обновляется страница после клика. Решения: Ajax, web-socket, single page applications

3. Много одинаковых ресурсов перезакачивается. Решения: ETag, Last-Modified

4. Тяжелая страница в браузере. Решения: не использование JSF, GWT и прочих ужасов, использования Twitter Bootstrap, AngularJS, KnockoutJS, Backbone.

5. Медленные запросы в базу. Решения: денормализация, профилирования и уход от JOIN, кеширование, асинхронные запросы без подтверждений если можно.

6. Медленное конструирование страниц. Решения: переход к статике, предварительная отрисовка HTML в фоне после пакетной обработки (так делают вские вконтактики в выскоконагружеными пабликами)

7. Медленный ЯП. Это обычно не важно, вы просто слишком много всего делаете в запросе, нужно переделать приложение на подготовку максимально готовых к простому вычитыванию данных.

8. Немасштабируемый сервер. Решения: stateless приложения

9. Немасштабируемая база. Решения: Apache Cassandra, Riak - оптимизация под что угодно. MongoDB - для ленивых и стартапов, оптимизация на чтение.

10. Тормоза из-за периодических обновлений страницы. Решения: server side events, Comet, Web-sockets. Ну и надстройки всякие аля протоколов socket.io

11. Много статики. Решение: оставьте в покое ваш app server. Выложите статику на nginx, S3 или еще какой-то CDN

Вижу, разве что, смысл при реализации HTTP-фронтенда к какой-либо серверной C/C++ аппликации, например к SCADA-системе. В принципе, логика-то элементарная: один поток слушает порт и, при поступлении соединения, создает и передает задачу обслуживания клиента на полученном сокете на исполнение в thread-pool.

Там данные с искомого сокета в цикле неблокирующим образом (по таймауту, см., например, pselect(2)) читаются и скармливаются некоему «парсеру» HTTP-запроса до тех пор пока не будет получен полный HTTP-запрос. Далее на основании данных полученного HTTP-запроса нужно сгенерировать HTTP-ответ неким «композитором» и также неблокирующим образом послать его в сокет клиенту. Если по данным поступившего от клиента запроса имеется клиентская поддержка keep alive connection и клиент ее запрашивает, то повторить вышеуказанное в этом абзаце, а в противном случае закрыть сокет и завершить обслуживание. При этом в случае обрыва соединения или истечении таймаута приема/передачи данных происходит прекращение исполнения задания thread-ом из pool-а и закрытие сокета. При получении «кривого HTTP-запроса то же самое, разве что можно „для чистоты эксперимента“ бросить клиенту „400 Bad request“ перед закрытием соединения. Если превышен таймаут чтения, то можно оправить „408 Request Timeout“ из тех же соображений...

Как видим - все так просто, что можно даже не использовать „вспомогательных средств“, которые зачастую диктуют использование своего main-loop-а в своих же thread-ах, что в результате, как часто случается, может вылиться в то, что под определенный функционал их создатели просто не предусмотрели соответствующего callback-а. Так что остается, разве что, разобраться с этими „парсером“ и „композитором“, но HTTP-сообщения - это довольно простая и весьма подробно описанная в соответствующем RFC штука и написание этих компонент является не такой уж и ракетной наукой (см., например, 1, 2 и 3). Thread-pool делается „на раз“ с помощью любых thread-ов (C++11, boost, etc.), мьютекса и условной переменной.

P.S. Что касается web-framework-ов вообще - мне кажется не совсем удачной мысль о генерации на сервере кода отображаемых клиенту элементов управления. Вероятно, лучшим подходом будет тот, при котором сервер сначала отдаст клиенту JS-код (ExtJS, QJuery UI, etc.) для отрисовки GUI в броузере, а затем лишь отвечать на REST-запросы от последнего. В этом случае получается слабо связанное решение, подразумевающее легкую замену серверной при нетронутой клентской части и наоборот, да и бизнес-логика вменяемо разделяется на чисто клиентскую (View/Controller) и чисто серверную (Model).

А если там REST (привет, Playframework), то на каждый запрос нужно собрать контекст и потом куда-то его деть до того, как GC перестанет с этим справляться...

Конекст можно закешировать. И что бы в вебе завалить GC - это нужно сильно постараться. Большинстов объектов создаются на запрос, то есть быстроживущие и очень быстро прибиваются сборщиком молодого поколения. 1500 запросов в секунду к примеру на ноду никакой особой нагузки на GC на создают.

1500 запросов в секунду к примеру на ноду никакой особой нагузки на GC на создают

где-то видел тест RAD веб-фреймворков, в котором после 60к RPS на ноду оставались только два, один написанный на сях и с небольшим отрывом - на эрланге, конкретных имен не помню -) Олсо, memcached вроде может выдержать полтора миллиона RPS, тогда при 60к за один запрос можно отправить не больше 25 запросов к кэшу. Может, тут просто не memcached нужен, а сразу couchbase2..

Есть такое правило довольно грубое: все, что делает порядка 10^5 операция в секунду на Java уже требует некого Rocket Science, так что охотно верю. А ссылочки нету на тест?

Не знаю что ты подразумеваешь под web-development. Transmission-daemon вполне веб-приложение, написано на чистом си (браузерный клиент естественно на js). Посылать документики по http - уже есть apache, nginx. Хочешь динамики - написать простенький шаблонизатор с элементами клиента серверной СУБД - пожалуйста, но PHP уже есть. Переписывать отдельные, критичные к производительности блоки кода - пожалуйста. Не можешь начать кодить на чем-нибудь не на Цэ++?

Зачем изолировать языки программирования?

Срач хочешь разжечь?

Зачем изолировать языки программирования?

Хотя понимаю. Хотим рабочую силу подешевле?

Ну тогда PHP - это решение!

Хотя есть ещё одна версия - ты Цэ++ извращенец. Ну тогда извини - ты в меньшинстве - сам разрабатывай фреймворки или трахайся с проблемами *CGI; ищи себе подобных, группируйся.

Не, пока не нашел. Вот тест мемкаши: http://www.philchen.com/2008/06/18/how-much-can-a-memcached-server-handle

Насколько я помню, с одной ноды без keep-alive вообще проблематино выжать что-то больше 5k rps... Интересна методика тестирования.

А по теме: ну иногда пишут хайлоад на С++. Почему на нем? Что знают, на том и пишут. Не вижу проблем писать хайлоад на Java

  Плюсую этого господина. Go - низкоуровневый, при этом роутинг, сервер, печеньки и всё всё всё, для чего обычно пишутся микрофреймворки - являются частью языка. Над скоростью работают. Писать приятно, типизация строгая, статическая, сборщик мусора, ассоциативные массивы, строки, код выглядит компактно и красиво. Revel framework - вообще шикарная вещь.
  Для своих проектов под web перепробовал всё. Последний раз это был Erlang. Однако, Go - самое шикарное решение: можно сразу брать и писать непосредственно бизнес логику. Делать это быстро и с удовольствием.

Я одно время интересовался этим го. Штука интересная. Но если надо написать быстро есть питон. Что бы быстро работало есть Java. А зачем все вместе? Не бывает серьезных хайлоадов, которые пишутся за час. Да и с хайлоадом хрень - сборщик мусора и мониторинги и рядом не валялись с явой.

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

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

Ничего плохого нет. Только не получится быстро. Там 90% времени это ресерч, анализ логов, мониторингов, выработка дизайна, написание тестов, написание инфраструктурных компонентов. Никакой RAD фреймворк со своими батарейками уже не спасет. Нету там задачи «быстро интегрировать фичи».

Тот же фейсбук использует транслятор из пхп в С. Если использовать в тамком ключе, то вполне ок. В остальных случаях любой скриптовый язык позволяет разрабатывать в разы быстрее, ИМХО.

Тред не читать! @ Сразу отвечать! =)

ну, я вот захожу на LinkedIn или ЖЖ, и они тормозят

фронтенд тормозит, С++ тут ничем не поможет, линкендин вообще в плане фронтенда жесть