@magnuz

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

0

@Fulcrum_013

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

Добавлено через 10 минут
Ну это специальные средства для его поддержки добавили в 11-ом стадарте. А так пользовалась эта штука еще при царе Горохе причем совместно и с Copy-On-Write Symantic и с двунаправлеными указателями и т.д.
Как мне угодно не получится с подкапотными боровами и т.д.
мне надо чтобы я сделал вот так:
и никаких висячих ссылок после этого не осталось. А для этого нужны библиотечные средства для создания которых нужны сырые указатели а так же автогенерация и автовызов деструкторов.
Т.е. по большому счету раст просто подкладывает свинью на каждом шагу и не более того.

0

@Custos

Вы уже уходите в крайности)

Получится) Для этого есть unsafe

0

@Fulcrum_013

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

0

@Custos

Как я упоминал выше, тема достаточно холиварная)
Понятое дело, что C++ разработчику с опытом нет смысла переходить на Rust и привыкать к его упоротому синтаксису (хотя не помешает поковырять ради расширения кругозора)
Посмотрим со временем во что выльется Rust
Хотя начало уже неплохое - http://www.extremetech.com/wp-... ervo-1.png

0

@Fulcrum_013

Ну и че дальше?
Для объектов классов имеем двунаправленные слабо-владеющие и слабые ссылки. Для буферов - Move и/или Copy-On-Write на выбор в зависимости от особенностей применения.
Боров на кой ляд нужен? Куда его вообще приткнуть? Он как понимаю самоудаление объекта не поддерживает так же как и смарт-поинтеры stl ? А с точки зрения теории принятия решений эта штука абсолютно необходимо в самоуправляемых иерархиях объектов, особенно полиморфных.

0

@andyj

А для чего нужны бинарные протоколы??? Не могу придумать ни одной задачи кроме медиа-потоков (аудио, видео, 5D, 6D...) и передачи сырых данных вроде торрентов.

0

@Fulcrum_013

Их парсить из текста в бинарку не надо. и по трафу экономия в сотни раз. При этом передача с фиксированным набором форматов записей делается гораздо проще.
НУ а передача описания форм, их подвязки к источникам данных, и сами данные таблиц и т.д?

0

@pvzh

Переходят, но не целиком, а в той части, где она хорошо подходит. Синхронный код, типа генерации большого ПДФ, остаётся на php. Или пишется на Python, Go, и т.п.

Раз воротит от асинхронщины и функциональщины, то и не надо такого счастья. По PHP на ХедХантере пока ещё достаточно вакансий.

0

@Fulcrum_013

0

@Curry

А что вы можете предложить для серверной части веба на С++ сейчас, а не через N лет по прошествии которых вы вангуете бинарные протоколы?
У любимого вами цппбилдера только зачатки веб фреймёрка. К тому же он платный и не портабельный.
Есть CppCMS немножко живая, требует для установки питон. Как и буст, впрочем. По крайней мере лет 10 назад ещё требовал, когда я его последний раз ставил. И это меня удивляет. Почему для установки С++ пакетов которые подразумевают что компилятор плюсов уже должен быть установлен, используется питон? Расписываются в том что считают С++ к этому не способным? Впрочем, половина буста тоже для взаимодействия с питоном, что как бы намекает для чего плюсы в современном мире предназначены.
Нет, мне то плюсы отчасти нравятся, я на них 10+ лет писал. А скрипты не нравятся (сейчас нет смысл снова объяснять почему), но реальный мир таков, что как скрипты зашли в веб во времена первых веб-хостеров, где только со скриптами можно было обеспечить безопасность хостера, так оно и осталось.

0

@korvin_

Нет такого правила.

1

@Fulcrum_013

С++ Builder и его средства создания 3-teir пиложений к примеру. И живет эта штука уже десятилетия.
НО собственно вопрос в том что не позволяет десктопные технологии UI расширить на web-клиент. Т.е. продвинутыми методами только серверная сторона делается. Клиентская как обычно.

Добавлено через 2 минуты
Время на месте не стоит. Шареный хостинг уходит в прошлое. А в реалиях VPS а тем более выделенных серверов все совсем по другому.

0

@Curry

Какие конкретно сайты сделаны на билдере?
Наверное потому что это будет уже не web-клиент. И сейчас существуют десктопные приложения активно взаимодействующие с чем то в сети, обычное дело. И там протоколы могут быть бинарные. И это не называется web-приложением.
А Web - это html и т.д. И не нужно ставить свой софт - достаточно браузера. При чём все попытки засунуть туда машинный код и бинарные протоколы провалились. От ActiveX в браузере до Flash.
Я же написал "было" - прошедшее время. Сейчас то конечно можно и без скриптов. Правда остаётся проблема горячего обновления ПО серверной части. Подружить её со статической типизацией ещё ни кому не удалось, увы.

1

@Fulcrum_013

Во первых HTML не предназначен для создания UI которое все больше и больше требуется в веб-приложениях. Поэтому будущее за аюсолютно другим подходом - использование полноценных средств описания UI для организации ввода/вывода и обмена информцией с сервером, использующие HTML по назначению - для отображения формотированного текста.
На самом деле никакой проблемы с этим нет. Но главный вопрос в том что при правильном подходе к разработке это как таковое вообще не нужно.
Они как таковые даже не начинались. При этом как понимаю wasm и ActiveClient основанны на абсолютно другом подходе - докомпиляции в нативный байткода LLVM

Добавлено через 2 минуты
Ищите смотрите. Но как понимаю это сайты крупных корпораций потому что решения априори работает как выделенный серв. Лично с подобными решениями сталкивался исключительно в интранете разных контор.

Добавлено через 1 минуту
Типа плагины в десктопных приложениях не разу не подгружаются/выгружаются? Ну и вообще горячая смена кода она родилась для бинарного кода. только очень давно. Когда весь код не помещался в ОЗУ. взять те же предшественники dll - оверлеи к примеру.

Добавлено через 15 минут
На самом деле проблем с обновлением неактивного кода, как это в большинстве случаев работает со скриптами, вообще не существует. А для активного главный вопрос не в замене самого кода, а в патче стека и кучи, которые точно так же не решаемы в общем виде и для динамической типизации. Т.е. по большому счету ноды и т.д. переходящие от CGI-скриптов запускаемых шареным сервером (для которых проблемы горячей замены скриптов и не существует вне зависимости от того бинарные они или какие еще), к выделенному серверу HTTP серверу под каждое приложение в этом плане находятся в догоняющем положении. Но опять же проблема обновлений она становится проблемой только при использования антинаучных срамо-агильных псевдометодик разработки.

Добавлено через 57 минут
HTTP 2.0 вообще то бинарный.

0

@andyj

О чем вы здесь вообще говорите???

1) Вы давно ушли от темы ветки... "Учить Ноду нужно!" (мне это не нравится - хотие пообсуждать тенденции/потенциал/перспективы Веб-технологий - заводите отдельную тему... думаю раз в месяц админ не будет ее выкидывать в ветку "обо всем", а сейчас у нас похоже скоро очередная тема, полезная НОВИЧКАМ уйдет в мусор)

2) Веб это в первую очередь на 90% - ДИЗАЙНЕРСКОЕ решение под УЖЕ ВСТРОЕННЫЕ в компы/гаджеты браузеры! Большая часть фронтэндеров работают в Фотошопе и Кореле. Им приходится бороться за стиль каждой линии в менюшке. И это можно воплотить ТОЛЬКО средствами CSS. Браузеры вбрасывают кучу ресурсов в корректную обработку графики. Включая всевозможные 3х-4х цветные градиенты на кнопках и анимированость кнопок с вращением и заменением на другую и даже с основами 3Д. "Ад для дизайнера", но это "хотелки заказчика" за которые МНОГО платят!
Чтобы перевести ВСЮ эту графику на С++ прийдется попотеть. Да и инструменты для разработки дизайна фронтэнда куда хуже у С++ изначально (как и у ВСЕХ десктопных языков)!

3) Бэкэнд в принципе может быть создан на ЛЮБОМ языке! И тут уже идет война привычек и совместимостей. Для 90% задач УЖЕ хватает Ноды. Может и на 10-15% тормознутее С++ и все равно "под капотом" использует Си-шные технологии... Может и нет поддержки бинарных алгоритмов, но для веб-сайтов (на сегодня) это НЕ ВАЖНО! Пока хватает! И я не вижу на сегодня дефицита технологий для хотелок заказчиков! ИМХО JS, Java, PHP, Pyton, Ruby и... C++ на сегодня самые популярные языки для бэка! Но С++ - это язык "ядра" и зарекомендовал себя как "мега-надежный" и "мега-быстрый в работе", но... "долгий в разработке"! для большинства фрилансеров, которым платят "за решение", а не за "часы проведенные в коде" - это не самый лучший язык...

Возможно... лет через 5-10 в браузеры (зачем-то) встроят бинарность, переделав JS(следующая версия с частичной потерей совместимостью со старыми), встроенный в браузер как ЕДИНСТВЕННЫЙ (на сегодня) язык программирования... Но "про оттенки вкусов марсианских вин поговорим тогда, когда доберемся до Марса и посадим винград"(с)! Пока это ЛИРИКА! Ах как хорошо было бы... Ах весь мир (включая Майкрософт и Гугл) не понимают это... Ах это было бы 100500 раз быстрее... Ах, все к этому ну очень скоро придут, но браузеры пока не позволяют и от них похоже скоро откажутся... )) Нет спроса/заказов - не будет предложений/инструментов!!!

Добавлено через 1 минуту
Это вам (как веб-разработчику) сильно полезно? или это "инструмент на котором все построено", а не "инструмент которым вы МАНИПУЛИРУЕТЕ"?

1

@Fulcrum_013

Это наверное поэтому з/п у веб-деверов самые низкие в индустрии.
Поэтому зачем ограничивать свои возможности? Используйте С++. Тоже в принципе касается и фронтенеда. Она уже ВСЯ сделана на С++. Потому что всей непосредственной отрисовкой занимаются поткапотные дела раузеров и т.п. JS к этому пригоден чуть менее чем никак. Даже управление оной отрисовкой которое на 99,99% есть тупо переключение свойств готоых компонентов на JS растягиывется в километры быдлокода, даже там где код вообще не нужен.
Ну а в плане скорости разработки интерфейсов визуальные средства куда продуктивней любого кода. При этом вопрос переноса принципов визуальной разработки на веб - по большому счету только вопрос отказа от CGI. Остальное - нативные скрипты браузера и бинарные протоколы вытекают из удобства связи с нативной серверной частью, особенно при подходе обеспечивающем визуальный биндинг источников данных к элементам ввода, который устаняет разделение на бэк-енд и фронт-енд как таковое, заменяя их разделением на клиентскую и серверную часть кода на уровне компонентов.

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

Добавлено через 11 минут
Вообще то код на плюсах обычно на порядки коротче кода на любом скриптовом или манаджед языке. с учетом технологии web assembly - далеко не единственный. Так кстати о птичках за бугром уже начался переход на клиентскую часть на плюсах. Пока что правда это касается в основном очень крупных решений в которых JS уже давно превратился в многокилометровую невменяемую кашу. И подход по большому счету идет в фактичесски переписывания я-ля скрипты. Что не есть продуктивно. Но как бы со временем это однозначно приведет к технологии библиотеки компонентов отрисовки форм и таблиц данных на удаленном десктопе (т.е. внутри браузера), позволяющую реализовывать UI на 99,9% вообще без кода, точно так же как это делается для десктопа уже более 20 лет.

Добавлено через 18 минут
Т.е. не нода - не более чем прослойка позволяющая собирать вместе уже готовый набор компонентов и ни шагу в сторону тратя на это километры кода.
В плюсовых же решениях подобные дела типа сборки уже пару десятилетий делаются вообще практически без кода. Код нужен только для расширения набора компонентов, что для JS вообще не доступно. Ну и какая вообще необходимость существавания такой скриптовой прослойки?
Свежо придание но верится с трудом. Ни одного дата-дривен решения на JS еще не видел. И причина как понимаю банальна - гигантское тормоза скриптов и ужасный оверхед по памяти всего что имеет GC на подобных решениях, в купе с полным отсутствием средств автоматического управления памятью работоспособных в подобных иерархиях и абсолютная невозможность создания таковых. Плюсы же с такими решениями, позволяющими сокращать код в сотни и тысячи раз, работают безо всяких тормозов с минимальным потреблением памяти и полной автоматикой управления памятью иерархий.

Добавлено через 10 минут
А я вообще не веб разработчик. Я просто разработчик. И мне как бы не интересно разделять разработку на веб десктоп и т.п. Мне интересны единые тулсы создания UI и биндинга его к источникам данных как для десктопа так и для веба так и для UI работающего внутри 3D сцены. При таком подходе бинарные протоколы гораздо удобнее. Хотя бы потому что можно пользовать единый формат описания форм и потоков данных без ненужного конвертирования в текст и обратно для web-UI.

Т.е. разница для любого удаленного UI она в результате только в либе непосредственного рендера UI из описания формы. Поэтому выпадение веба из бинарного мира далеко не на пользу вебу.

Добавлено через 6 минут
Т.е. разница для любого удаленного UI она в результате только в либе непосредственного рендера UI из описания формы. Поэтому выпадение веба из бинарного мира далеко не на пользу вебу. Именно поэтому HTTP 2.0 и сделали бинарным. И именно поэтому во всю разрабатывают технологии использованияв браузере нативных языков, которые гораздо удобнее в плане работы с бинарными данными и при этом на кучу порядко продуктивнее примитивного JS. Тащить же JS на серверную сторону а особенно туда где априори нужен выделенный серв - ну это мягко говоря сумасбродство.

0

@pycture

..веруйте, не сомневайтесь, даже если этого не видно. какое-то сектанское зомбирование. веб-сайтов на билдере нет, пока не доказано обратное.

3

@Fulcrum_013

pycture, А как вы определите вообще на чем сделан тот или иной сайт пока не получите доступ к софту серверной части?

Добавлено через 8 минут
Там есть решения позволяющие визуальное создание бэк-энда именно сайтов. При этом полный набор средств визуальной разработки аналогичный по назначения node.js тоже есть. Причем с самого его рождения. Но пилить на нем просто сайты-визиточки или даже социалочки - это по большому счету стрельба из пушки по воробъям. Основное назначение этих средств - мост к веб-интерфейсу для крупных информационных систем, для которх веб-UI только капля в море.

0

@ct0r

Тебе раст точно не нужен, лучше изучи плюсы нормально и научись дичь не нести.

2

@andyj

По количеству заказов на фриланс-ресурсах по написанию сайтов на С++билдере

Но умудрились уничтожить ветку ВЕБ-разработчиков и отправить ее в "священные войны"! ЗДЕСЬ обсуждают (обсуждали до вас) именно JS, а конкретно работу в Node.js! И в 99% применительно к WEB проектам... Где С++ места нет и в ближайшие 5-10 лет не будет!



p.s. У каждого языка свой "пласт" применения. У Node.js - преимущество перед другими языками в основном в том что на нем можно писать ОБЕ стороны проекта - и клиентскую и серверную. И даже в процессе разработки (и даже работы) перекладывать часть нагрузки с сервера на клиента без переписывания всего проекта... (я у себя на него половину батников переписал) А утечки памяти, отсутствие потоков, отсутствие бинарных сокетов - можно списать на юность языка! Либо появятся решения, либо язык будет вытеснен другим более гибким языком, где таких проблем меньше... Например go, pyton, ruby... и СИЛЬНО сомневаюсь что у С++ в этом вопросе есть хоть какие-то шансы!

0