@magnuz

Я старый пхп-шник. Сейчас все переходят на году. Говорят что убер на года сделан и многое такое и говорят что у них производительность круче чем у пыхи. А как может быть производительность у них круче пыхи если там нет многопоточности. Есть какие-то хитрожопые асинхронные вызовы которые хер поймёшь. Хотя слышал что в последних версиях делают таки шаги к мультитредингу но как эксперимент.
Вот например такая задача. Из файла аксель импортнуть в таблицу все строки коих может быть овер 10000 отображая в прогресс баре процент сколько их импортнуто. Пыха решает такую задачу некрасиво и плохо. Пыха без демонических примочек. Но то что язык без мультитредства может решать такую задачу красивее я не могу поверить.

0

@Fulcrum_013

Добавлено через 1 минуту


Добавлено через 1 минуту
Зря сомневаетесь. Хотя бы потому что к примеру утечки памяти - это следствие использования GC.

Добавлено через 1 минуту
У него давно такое преимущество отсутствует. При этом JS сам по себе является недостатком с лихвой пересиливающим любые преимущества которых у node.js в общем то нет вообще.

Добавлено через 6 минут
Вы в этом так уверены? Веб-дев как индустрия столько не проживет в современном виде. Этот пузырь лопнет гораздо раньше.

Добавлено через 2 минуты
Нормально по вашему молится на stl и boost? Нет уж спасибо. Мои либы работают гораздо лучше и имеют гораздо более продуманный интерфейс.

0

@andyj

Зря вы вмешались в ветку с чужим языком... Лучше оставались бы в С++, чем ср...ть на другие языки! Позволили бы нам и дальше верить что у нашего языка есть будущее в отличии от вашего... )))

0

@Curry

Не нужно выпускать новые версии ПО?
Ещё как начинались. Возможность выполнять ActiveХ в IE и сейчас доступна, а Flash заняла скромную нишу воспроизведения роликов на ютюбе. А в пике популярности, в нулевые, на ней целые сайты делали.
То есть отсылаете меня в поиск за доказательствами ваших слов как адепты "инопланетянских" кругов делают?
Это очень примитивный способ обновления. И разбиения задачи на исполняемые модули тоже - в API плагинов обычно используются сырые указатели, и пр. в качестве аргументов функций. В общем случае, заранее неизвестно где пройдёт граница обновления, не факт что по плагину. Допустим мы захотели дополнить некоторую структуру полями которые не будут использоваться в не модифицируемой части программы. Это не сработает т.к. в старой части программы структура может неправильно скопироваться. Нужно передавать размер стуктуры. Но у нас могут быть вложенные структуры. Т.е. продумывая возможность модификации типов приходим к необходимости хранить описание этих типов.
Для динамической проще. С каждой переменной идёт описание что там в каком виде и как храниться. И даже если мы добавляем новое поле в динамическую структуру, то не знающий про такую модификацию код будет правильно выполняться для уже существующих полей.
А вы уверены что для скриптовых фреймвёрков не сделаны визуальные средства разработки?
React

0

@Fulcrum_013

Ни одна из этих технологий не работает как средство DHTML. они не более чем отрисовывают картинку в выделенный им для этого буфер.

Добавлено через 50 секунд
При научном подходе к разработке до конкретных изменений в предметной области обновлять собственно говоря нечего.

Добавлено через 7 минут
Если это называется дата-драйвен то я балерина.
Еще раз - каким образом определить на чем именно фурычит тот или иной сайт?

Добавлено через 2 минуты
Допустим что мы начали разработку с постановки задачи и любые дополнения структур в результате бессмыслены.

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

0

@Curry

При чём тут DHTML? Я привёл примеры бинарного кода выполняемого из браузера с двоичным протоколом (о чём вы мечтаете). И что они не очень то взлетают. DHTML ранее не упоминался в теме.
То есть вы ничего никогда не проектировали а только теоретизируете про научный подход. Тот же ваш любимый цппбилдер выходил многими версиям. Видимо там мне научный подход.
Адепты серверных технологий всегда могут привести примеры сайтов с их любимым бэкендом. Для состоятельности cppbuilder-а в этой области нужно привести примеры известных крупных сайтов о строительстве которых пишут статьи где упоминается что это сделали на нём. Такого нет. Другой вариант поиска вам уже указали - спрос на разработку сайтов на билдере. Такого тоже нет. Третий вариант - найти в генерируемых страницах упоминание бэкенда.
Вставляет ли своё "лейбл" в HTML билдер я не знаю, вы видимо тоже. Так что предъявить сайты им сделанные не можете.
По этому считаем что их нет. Что не удивительно. Не используют для этого С++.
Допустим мы выпускаем обновление поскольку от нас потребовали расширение функционала.
Это на С++ так.

0

@Fulcrum_013

Это везде так. Стек вызовов для активного кода патчить все равно придется. так же как и кучу.

Добавлено через 1 минуту
Там предметная область имеет свойство постоянно расширятся. Имеется в виду апи оси и стандарт компилятора. Опять же апдейты идут примерно раз в год а то и два.

Добавлено через 2 минуты
А вот как раз при том что WASM и NativeClient работают совсем не так как эктивиксы и флеши а именно замещают JS в плане работы с DHTML и объектами браузера.

Добавлено через 34 секунды
Структуры при чем?

Добавлено через 11 минут
Сайты которые на всем этом делают в подобном пиаре не нуждаются. Мало того они обычно не доступны для широкой публики. В основном это веб-мосты для внутренних информационных систем корпораций. Большая часть из них живет вообще исключительно в интранете.
А если бэкэнд генерирует не страницы а потоки данных а рендером страниц занимаются скрипты клиентской части?

Добавлено через 2 минуты
Еще раз. Просто сайты на билдере обычно не делают. Делают веб-мосты внешнего доступа к урезанному функционалу клиент-серверных систем, у которых преимущественно десктопный UI.

Добавлено через 1 минуту
Генерация страниц на 100% управляема разработчиком, если конечно пользуется такой анахронизм как рендеринг HTML а тем более серверный. Так что замарачиваться прилепливанием лейблы сделано на билдере точно никто не будет.

0

@Curry

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

Добавлено через 2 минуты
Так чего же вы советовали ТС обратить внимание не плюсы вместо node?

0

@Fulcrum_013

Дык плюсы то билдером не ограничиваются. Билдер это просто один из давно существующих примеров. При это веб-сервера для него не более чем побочный набор компонентов. А на будущее именно плюсы будут заходить в веб. В АСУТП подобные вопросы могут решаться исключительно многократным резервированием. А на спутниках тем более. При этом с апдейтом вопросы исчезают напрочь.

Добавлено через 1 минуту
Еще раз при чем тут структуры? Главная проблема в патче стека вызовов. При этом поток по любому придется останавливать так что о сохранении работоспособности никакой речи быть не может в принципе.

Добавлено через 2 минуты
В основном больше нигде. При этом многие остальные изменения решаемы изменением данных а не кода. Особенно это касается серверной части 3-tier решений.

0

@Curry

Вы ТС советовали плюсы для веба. Ему нужно сейчас, а не умствования что будет. Если не билдер то что используют сейчас для создания сайтов на плюсах?
И резервированием, и горячей заменой.
Это только в вашем выдуманном мире все программы разрабатываются на научном подходе, не содержат ошибок в продакшене, заказчик не требует их ту же переделывать и т.п. Собственно, так только начинающие заявляют, что они не ошибаются никогда, после успешного выполнения их первого хэловорда.

0

@Fulcrum_013

Некоторые корпорации вообще голые плюсы пользуют.

Добавлено через 2 минуты
Та они и в дебаге редко ошибки содержат если правильно делать.
Обычно нет. Именно для этого и проводится анализ предметной области чтобы переделывать не надо было а в подавляющем большинстве случаев перенастраивать данными.

0

@Curry

Конкретики маловато. И примеры стоит приводить сразу с отсылкой к сайтам - вот этот написан на голом С, вот этот на С++.

0

@Fulcrum_013

ну к примеру вот эти ребятки

Добавлено через 10 минут
Какая может быть вообще работоспособность если поток придется останавливать? Если что то и заменяется то подгружается новый плагин и новые задачи распределяются на него. Уже работающие досчитываются, и после того как все потоки использующие старый код завершаются он выгружается. Но это не более чем костыль там где не удосужиились сделать резервирование. И он не работает с подзадачами которые крутятся без завершения.

0

@korvin_

Flash давно выпилили в пользу HTML5

1

@Curry

Это у вас рассуждения на тему "как бы я сделал" вместо того что бы ознакомится с тем, как это делается и что это такое вообще. Например виртуальная машина Erlang имеет встроенную поддержку горячей замены, но вы всё равно про неё читать не будете потому что там GC. Я подозревал что там уже не флеш - слишком в ней дыр много и поддержку Адобе прекращает с 2020.
В общем, вы правы, и тогда тем более - не приживаются бинарные довески к браузерам.

0

@ct0r

С сайта этих ребяток:
Предложи им свои поделия вместо буста и почитай, куда они тебя отправят.

0

@Fulcrum_013

Да ради бога. Им виднее что им для их проектов удобнее. А мне виднее что удобнее для моих. Кстати так именно для такого подхода в плюсах все по максимуму выносится в библотечные средства, а не под капот складывается.

0

@Usaga

Вот и еще одна тема успешно превращена в болото бурлящего дерьма. Fulcrum_013, вы просто волшебник.

magnuz, изучать ноду имеет смысл только, если вы ничего кроме JavaScript не знаете и знать не хотите.

0