А есть ли смысл использовать C++ для web ?

И что из этого по ссылке опровергает мои слова?

Ну, например, вы излишне верите в горизонтальную масштабируемость. Если из-за тормозов Python-а или Ruby вам нужно 500+ серверов, то в современных условиях Python и Ruby могут послать в пешее эротическое для того, чтобы на том же Go потребовалось всего 50 серверов.

Статически типизированным го вообще назвать язык не поворачивается - https://play.golang.org/p/nIGfU_QAKY, строгим, может быть, да, но явно не статически.

Вам бы еще и матчасть подучить не помешало. Прежде чем утверждения про 99% и подобное делать.

А веб-сокеты типа дохера синхронные. Веб-сокеты нужны, когда есть двухсторонняя коммуникация - риалтаймовое обновление, чатики и прочая интерактивщина. И то, с ними можно дохера проблем огрести. С socket.io в первом ангуляре, мне приходилось с каждым событием $rootScope.$apply() вызывать, это хорошо, что страница в целом легкая была, а так бы вообще пришлось вотчеры вручную добавлять каждому свойству модели, т.к. socket.io вне контекста ангуляра работает.

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

Иди ты в сад со своими вебсокетами. Если бы ты перфоратор купил, то точно им бы и гвозди забивал и доски резал.

Съешь ещё этих мягких французских булок да выпей смузи.

Ваша убежденность противоречит тому, что было сделано в Instagram-е (ссылка была приведена выше). Это во-первых.

Во-вторых, в подавляющем большинстве случаев в Web-е никто не заморачивается на экономию ресурсов. За двумя-тремя исключениями, а именно:

• когда речь идет о реально больших нагрузках (масштабы Google, Facebook, Yandex, Mail.ru и т.д., разница между 10K серверами и 5K серверами там становится более чем заметной);
• когда речь идет о реально маломощных устройствах, для которых нужно управление через сеть;
• когда речь идет о снижении времени отклика. Как в примере с Instagram-ом, когда нужно сократить время расчета рекомендаций. Или как в ситуациях с аукционами для онлайн-рекламы.

Собственно говоря, для этих исключений лучше C/C++ и, сейчас, Rust-а, пока что ничего не придумали. Ну разве что сильно оттюненные Go, Java или D.

Будет ли связан с чем-то из этого ТС — хз, скорее всего не будет.

Ты не Григорий!

Вот в некоторых моих задачках как раз постоянно идет двухсторонняя коммуникация.

А чего тебе не нравится? Вебсокеты сейчас поддерживаются абсолютно всеми браузерами. Для серверного демона полностью наплевать, как отдавать данные: открывать обычный сокет и анализировать запросы, или же открывать вебсокет и непрерывно общаться. Второе даже удобней, т.к. позволяет значительно снизить нагрузку на сеть, если тебе 100 раз в секунду данные обновлять надо.

Зачем мне вебсокеты, если мне надо посмотреть очередную страницу форума на linux.org.ru? Чтобы написать свой велосипедный HTTP по ходу?

Зачем вообще придумали почтовые протоколы, FTP, ssh и прочую муть, если в каждой операционной системе есть замечательные сокеты, которые дают полную свободу творчества?

Ну так и ты не Михаил.

если мне надо посмотреть очередную страницу форума на linux.org.ru

Зачем страницы, если можно сделать «бесконечную ленту»: по мере прокручивания будут подгружаться новые сообщения, а ненужные будут удаляться (если, конечно, жабоскрипт в браузерах починили и delete в нем полноценно стал работать, а не жрать память).

Зачем вообще придумали ... протоколы

За шкафом! По http ты будешь забирать веб-странички со статикой, а динамику веб-сокетами забирать. Если не нужна быстрая реакция, то и старые добрые CGI сгодятся. А можно и вообще на сервере генерить толпу html и динамику обеспечивать сменой содержимого iframe'а.

Дофига вариантов. Просто для C/C++ в вебе есть ниша лишь в области CGI или вебсокет-серверов. Второе удобней тем, что работает себе как демон и не тратит время на запуск на каждое сообщение. В принципе, можно как fastCGI сделать — тоже демон, в котором вместо процесса на каждое сообщение запускается поток — но это синхронщина, не люблю я синхронщину...

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

Для этого есть server-sent events

И реализуются они на вебсокетах =D

Зачем страницы, если можно сделать «бесконечную ленту»: по мере прокручивания будут подгружаться новые сообщения, а ненужные будут удаляться (если, конечно, жабоскрипт в браузерах починили и delete в нем полноценно стал работать, а не жрать память).

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

Затем, что мне может понадобиться перескочить сразу на сотую страницу, а не скролить как идиот до мозоли в пальце.

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

Это очень удобно, если собирать мусор, а не как во фконтактегах: ты на 100 записей прокручиваешь, и браузер убивает oom-killer (и хорошо, если браузер, а не что-то более полезное).

Хотя, я не уверен, что рукожопы, пишущие код браузеров, организовали наконец-то нормальные сборщики мусора: 5 лет назад ничего такого не было, поэтому странички с трансляцией mjpeg-видео приходилось каждые несколько минут перезагружать.

мне может понадобиться перескочить сразу на сотую страницу

Для этого элементарно заводится поле с вводом нужного номера. Или полоска «грубой» прокрутки. Удобно.

Слишком много телодвижений

Только первые полгода, потом по накатанной. Но это везде так.

И не надо С убогим обзывать, уродец!

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

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

build: failing

можно увидеть, что там не проходят тесты на двух платформах, а точнее на винде с mingw, что не удивительно, ибо mingw.

когда сможешь в закладки добавить «грубую» прокрутку - тогда и приходи.

а пока что лучше не лезь в веб, особенно со своим любимым убогим C.

А для меня удобно.

Элементарно это делается: сервер анализирует GET-запрос и «отматывает» тебя в нужное место.

Содержательная беседа.

Два смузи этой госпоже!

Да, Стас.

Не важно.

Хотя вот тех же Интернетиках всплывают темы о том, как подружить Node.js и C++. Мол, на Node.js и JS пишут принималку запросов, после чего запросы делегируют в плюсовую часть для каких-то тяжелых вычислений, после чего опять же на JS генерируют ответ.

Emscripten / WebAssembly

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

Вау. «EddyEm» — подумал я, читая. Потом увидел ник.

Для этого элементарно заводится поле с вводом нужного номера.

До этого руки криворуких реализаторов не доходят в 90% случаев.

Поэтому с учётом этого человеческого фактора: в топку.

это неудобно для юзера и всё

+1

Элементарно это делается: сервер анализирует GET-запрос и «отматывает» тебя в нужное место.

Прикинь, ты изобрёл листание страниц. И стоило корячиться?

Прикинь, ты изобрёл листание страниц. И стоило корячиться?

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

Страницы неудобно: долго ждать, пока очередные 50-100 сообщений подгрузятся. А «бесконечная лента» с этой точки зрения — как раз то, что нужно: пока одно сообщение читаешь, 2 следующих подгружаются.

А вот ничего подобного, как раз я (Эдди) и предлагаю бесконечную ленту и вебсокеты. Потому что нужно же как-то оправдать использование С в вебе в отрыве от управления железяками ☺

(а иначе тупо CGI на баше хватит: я еще лет 12 назад, когда в ПТУ преподом работал, сделал систему тестирования на гольных башевских CGI. Указываешь в GET-запросе этому CGI имя директории с тестами, и он уже читает там конфигурационный файл и выдает те или иные формы тестов).

Страницы неудобно: долго ждать, пока очередные 50-100 сообщений подгрузятся. А «бесконечная лента» с этой точки зрения — как раз то, что нужно: пока одно сообщение читаешь, 2 следующих подгружаются.

Я хз, как там в Заполярье, а в наших краях проблемы медленной подгрузки текста вымерли вместе с модемами. Хотя говнокодеры, плодя страницы весом по 4-5 мегабайт, и пытаются затащить субъективное восприятие скорости сети обратно в девяностые.

Но даже если так. Есть три решения проблемы листания:

• Классическое постраничное: сложность реализации для среднестатистического кодера - копеечная, удобство - нормальное.
• Бесконечная прокрутка, как она сделана (как минимум) в 90% случаев: сложность реализации для среднестатистического кодера - средняя, удобство - полное говно.
• Умное листание с постепенной подгрузкой и возможностью перехода по страницам: сложность реализации для среднестатистического кодера - высокая, удобство - нормальное. Веротсность встретить вживую в вебе: стремится к нулю.

Ну ты понял, какой вариант я выберу, ага? :)

Вот будто нельзя помечтать!

В моих мечтах программисты пишут исключительно на С. Заботятся о ресурсах. Не пользуются хрюникодом. Не убирают обратную совместимость в новых версиях библиотек. И т.д., и т.п.

А в реальности они — уроды безмозглые, которым лишь бы наклепать быдлокода, и хрен с ним, как оно работает и что памяти жрет по 10ГБ! Вон, наглядный пример — разрабы огнелиса и хромоногого.

Насчет веба: я обычно одностраничники делаю (веб-морды), иной раз там iframe'ы какие-нибудь меняются или блоки. Мне нет нужды уйму текста выводить. Разве что есть смысл с выводом логов заморочиться, чтобы старые сообщения удалять из памяти браузера.

У меня есть намного бóльшая проблема: до сих пор ни в одном браузере нет адекватных средств для осуществления трансляции видео в реальном времени. Приходится mjpeg использовать. И перезагружать фрейм с картинкой каждые несколько минут, т.к. браузеры текут и не желают старые изображения из буфера выбрасывать!

Вон, наглядный пример — разрабы огнелиса и хромоногого

Ты просто не имеешь понятия о задачах, которые им приходится решать.

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

В моих мечтах программисты пишут исключительно на С. Заботятся о ресурсах. Не пользуются хрюникодом. Не убирают обратную совместимость в новых версиях библиотек. И т.д., и т.п.

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

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

Да, в мажорных версиях можно выкинуть все legacy, но блин, когда в минорных это делают... Я просто хочу взять, и убить разрабов ядра! Задолбали, сволочи!!! Только я под 4.10 переделал модуль ядра, изначально писанный неизвестно кем под 2.4, как опять нихрена не компилится! Да сколько ж можно, блин! Сволочи!!!!111

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

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

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

торопливость и манагерство порождают понос в программировании, недостаточное тестирование и уязвимости, в конечном итоге.

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

Это проявление типичного манагерства: наймём тыщу абизян и они нам случайным образом нажимая кнопки, за еду напишут «Войну и Мир».

Такого не бывает. Критические уязвимости появляются когда их находят и чаще всего находят их не при «нормальном тестировании». В подавляющем большинстве случаев, насколько я могу судить.

Впрочем, у анонимуса с 4.10 другого рода проблема - просто опять переделали АПИ. Хотя твой пассаж про стабильность тут тоже не в тему - прикажешь ему на 2.4 сидеть?

P.S. Капча «vigevano» меня просто оскорбляет.

Только я под 4.10 переделал модуль ядра, изначально писанный неизвестно кем под 2.4, как опять нихрена не компилится!

4.4 будет поддерживаться до 2022 года. Сиди на нём, какие проблемы.

прикажешь ему на 2.4 сидеть

Пусть на LTS ядрах сидит.

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

сидеть можно на любой версии, которая стабильно работает на железе. не нужно на сервер тащить последнее ядро. как раз на серверах не торопятся обновлять софт. работает - не трожь.

Ты это nvidia'овцам скажи!

Плюс еще многие другие железяки.

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

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