Почему бекенд не пишут на С++?

Question

[NosferatuZodd]

Раз С++ такой весь из себя и супер быстрый, почему на нем не пишут бекенд? Почему предпочитают ту же Java, .NET, PHP, и т.д.? Java невероятно прожорлива (по сравнению с С++ понятное дело), C# .NET тоже вроде как медленнее, ну про PHP молчу, мне все таки больше интересны крупные проекты по типу банковских систем и т.д., где PHP разумеется места нет.

Comments

[Евгений Шатунов]

Dolphin

боюсь показаться глупым

Глупым быть не страшно, страшно быть тупым. Глупый осознает свое невежество и тянется к знаниям. Тупой боится своей тупости и поэтому лезет спорить не обладая знанием.
Твой вопрос уже задавался. Советую изучить все ответы и все комментарии там.

Answer 1

[Antony]

Разработка сильно быстрее - как следствие она дешевле и Time to market сильно ниже, что в реально жизни гораздо важнее производительности (не всегда, но в общем случае это так).
Арендовать еще один сервер очень часто может оказаться выгоднее, чем оплачивать лишних полгода разработки и выкатить продукт позже конкурентов.

Пока вы сделаете и отладите свое классное быстрое приложение, все уже давно будут использовать кривую медленную Васину поделку.

Comments

[NosferatuZodd]

Звучит очень даже логично, спасибо за ответ)

Answer 2

[DevMan]

потому что это никому не нужно: сложно и долго = дорого.
а узкие задачи бэка, где критичны скорость/ресурсы, вполне себе на нем пишутся.

Comments

[edward_freedom]

узкие задачи бэка

где то всплакнул один nginx

[DevMan]

edward_freedom, где-то всплакнул один неуч.

[Hemul GM]

edward_freedom, ngnix - это часть бэкенда - сервер. У ТС же, очевидно, вопрос о самой логике бэкенда. Обработка непосредственно запросов и отправка ответа. Что пишут на php, JS, питон и тд.
Ни кто тебе не будет писать сервер на питоне. На нем напишут обработчик запросов - cgi.

[edward_freedom]

Hemul GM, на плюсах можно так же подключить готовую библиотеку и с такой же скоростью и сложностью сделать сервер

[Hemul GM]

edward_freedom, я знаю. И не только на плюсах. Только это всё дольше и сложнее. Ни какие библиотеки не спасут от кривых плюсов.

[DevMan]

edward_freedom, хочешь рискнуть запилить CMS на плюсах?

[Евгений Шатунов]

DevMan, а зачем рисковать, когда можно просто взять: Wt, CppCms, Mongoose, Drogon, Pistache и, внезапно, React. И так далее, и тому подобное. Их много.
По каждой ссылке приведены цели существования такого проекта и его область востребованности.

[DevMan]

Евгений Шатунов, затем, что как часто бывает, готовое не умеет нужные задачи и требует напильника.

[edward_freedom]

DevMan, в чем проблема допилить предложенные им технологии?

[DevMan]

edward_freedom, в трудозатратах с околонулевым выхлопом.

[edward_freedom]

DevMan, вообще не понятно о чем ты пишешь. В чем проблема делать фронт на реакте, а с сервера получать и отдавать данные? Или ты только абстрактно можешь мыслить, без опыта в программировании?

[DevMan]

edward_freedom, не понимаешь? иди учись.

[Евгений Шатунов]

DevMan, мы живем в 22 году 21 века. Сегодня даже в комнатном термометре может стоять веб-сервер для выдачи показаний, статистики и настроек пользователю в браузер. Про чайники с управлением из браузера, думаю, говорить не стоит? Знакомо ведь?
Давай посчитаем трудозатраты и неоколонулевой выхлоп использования альтернативных технологий в подобных устройствах.

[DevMan]

Евгений Шатунов, а давайте разделять эмбедед и классический веб-дев, который крутится не на микроволновках и прочих холодильниках?
вопрос то читали?

[Евгений Шатунов]

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

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

[DevMan]

Евгений Шатунов, окей, бэк - ядро оси, без него никуда. а там си в разных ипостасях рулит безмерно.

только к прикладному применению вообще, и в контексте вопроса в частности, это отношения не имеет.

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

[Евгений Шатунов]

DevMan, да нет, я в курсе что CMS на базе React Native с доработками используют в качестве бекенда в определенных случаях. И это бывает даже коммерчески выгодно.
Не вижу в этом никаких проблем. Инструменты всегда выбираются от задачи. Если постановка задачи просит такое решение, то почему нет?

И, да, я настолько далек от веб-разработки, что меня можно считать полным профаном конкретно в классическом веб-деве. :)
Да, тег поставил я, опираясь на общее настроение вопроса и ответов.

[DevMan]

Евгений Шатунов,

я настолько далек от веб-разработки, что меня можно считать полным профаном конкретно в классическом веб-деве. :)

и это нормально. нельзя объять необъятное.

Инструменты всегда выбираются от задачи

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

[Евгений Шатунов]

DevMan, так-то все языки у людей сраные. :) Я на пыхе даже годик-другой отработал не по профилю еще в нулевых. Не могу ничего против него сказать, мне норм было.

Все авторы подобных вопросов и слыхом не слыхивали о том, что AOT или JIT в современном пыхе, яве, шарпе и так далее полностью нивелирует разницу все с тем же кодом на C/C++.
И решать начинает действительно скорость разработки и цена ошибки.

[DevMan]

Евгений Шатунов, о том и речь.

Answer 3

[Adamos]

На Крестах вам придется с нуля писать то, что в Питоне или Пыхе есть из коробки: работа со строками, датами, БД и пр. - то есть 90% всего бэкенда. А когда вы все это напишете и соберете в классы, чтобы удобно пользоваться - вы внезапно обнаружите, что написали все тот же Пых, только в формате велосипеда.

Answer 4

[Vitsliputsli]

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

PHP очень быстрый язык, используется в совершенно разных областях начиная от управления станками на производстве заканчивая финтехом. Выбор С#, Java, PHP, Python зачастую состоит в "тимлиду больше нравится", так здесь язык не имеет большого значения.
Почему не C++? Потому что долго и нет особого выигрыша в производительности. Так как отдельные модули требующие высокой скорости пишутся на Go или даже Си. А в остальном, дольше ждать ответы от базы и этих модулей, чем обрабатывать код Java или php.

Comments

[Vitsliputsli]

Andrei Brizhak,

Вот здесь, тесты испытаний фреймворков для Веба на основе, перечисленных Вами языков, включая "быстрый" PHP.

Что ж, вооружившись этим знанием, вы теперь можете ответить на вопрос автора. Т.к. на первой строчке C++ использовать надо его, а то, что так практически никто не делает, это от того, что они все идиоты. Получается так?
Либо перечитайте мой ответ и поймите, что для своих задач PHP быстрый, как в работе, так и в разработке, и потому пишут на нем, а не на Си или даже ассемблере.
Можно еще посмотреть на содержание тестов этих испытателей, порадоваться задачам нагенерить json-чики вида {"message":"Hello, World!"}, сгенерить html (когда ищем высокую производительность, самое оно генерить html на беке), ну и еще куда ни шло фетч и update, но опять же с непременной генерацией json и отдачей его по сети.
А потом возьмите реальный проект, в котором вас будет волновать скорость выполнения запросов в базе данных, скорость работы сложных модулей, уже написанных на Go, потому что это будут узкие места, а никак не скорость генерации json и фетча в популярных языках на основе синтетических тестов.

[Vitsliputsli]

Andrei Brizhak, верно, как и другие языки, как и Java, как и Python, можно и C#. Собственно об этом я и в основном своем ответе писал.
Тесты разобрал в прошлом комменте, если есть возражения готов обсудить. Могу лишь повторить, что выигрыш в несколько наносекунд на сборке json - это мелочи с потерей в других областях, и именно поэтому выбираем не C++, а то что проще в разработке. А генерить статику, когда ищем производительности - это очень странно.