Здравствуйте, Sheridan, Вы писали:
S>Система включающая в себя XXX менее надёжна, чем система без XXX.
Предлагаю при помощи XXX обозначить "исходники на С++".

</sarcasm>
Способ разговора при помощи сравнения "система с Х против система без Х" — неконструктивен. Эдак ты договоришься до того, что самолёт с одним двигателем надёжнее, чем самолёт с двумя двигателями.

Надо какие-то другие аргументы использовать. Нода, конечно же, не является манной небесной; но и абсолютным злом её назвать я тоже не могу.
Как по мне — это крайне интересная инициатива, поскольку проверяет границы реальности.
Ведь удивительная вещь, но уже 20% столетия за спиной, а до сих пор нет однозначного ответа для выбора технологии бэкенда.

С++ и С идут сразу в пень просто потому, что у них ошибки дорого стоят как в последствиях, так и в исправлении.
Нет никакой гарантии, что неаккуратно написанный код, который где-то там обратился по указателю после delete, не просто сломал страничку с 500 Internal error, а где-то там взял и поднасрал в совершенно чужие данные в хипе, и в результате в базу уехала какая-нибудь не та сумма проводки. И с внедрением асинхронщины и многопоточности шансы на вот такое только возрастают.
Дальше — безумно медленная компиляция означает долгий цикл разработки; то есть исправление косяка тоже будет крайне дорогим. За время, пока С++ собирает веб-приложение среднего размера, какое-нибудь дотнетное приложение успеет собраться, перезапуститься, прогнать тесты, и сделать коммит в main.

Дальше у нас что? Php, не к ночи будь помянут? Ухудшенный С++. Повсеместная Java? Монструозный ентерпрайз, стек-трейсы в 600 строк глубиной, трудная отладка. Зато — для любой пришедшей в голову задачи есть референс-реализация, и две-три-пять "нормальных" реализации на выбор. Да, многословно, да, скучно. Но зато — повсеместный язык, Lingua franca.
Как по мне — проклятие static typing, и достаточно отсталая виртуальная машина. То есть одновременно нужно писать много кода, и трудно сделать его по-настоящему быстрым.

Нода тут у нас выступает в роли смелого эксперимента "а занафига нам статик тайпинг, когда мы всё равно большинство ошибок ловим не компилятором, а визуально в браузере".
Плюс поверх этого внезапно Хейльсберг достаёт из шляпы кролика со встроенной уткой и так далее — "у нас есть static typing, да ещё и с таким выводом типов, что дотнетчики плачут от зависти!"

У меня остаётся некоторый червячок недовольства потому, что виртуальная машина-то там всё равно бестиповая! Это означает, что нода не может пользоваться преимуществами статик тайпинга так, как это делают настоящие компиляторы вроде С++ или дотнета.
Понятно, что тормоза начинаются только там, где интенсивные вычисления. А в вебе они у нас где? В известных местах — перекладывание байт в HTTP реквестах и распонсах. Отсюда искушение вынести всё это перекладывание как раз в натив, а прикладной код будет только клеем (здравствуй, нумпи!).
Но у меня с давних пор недоверие к билингвальным системам. Ну, вот в Delphi, когда мне не нравился чей-то готовый компонент, я мог поковыряться и навелосипедить свой, как мне надо — оставаясь в рамках того же языка и платформы. В шарпе — то же самое: очень редко мне приходится жалеть о том, что каких-то вещей (пока) не завезли в JIT/CLR, а всё остальное я могу напилить на том же шарпе.
А вот VB ужасен не только потому, что это плохой язык, а и потому, что OCX для него должен писать писатель на каком-то другом языке, где опыт VB совершенно неприменим.
Питон — то же самое: нормальную библиотеку для питона на питоне написать нельзя. Модуль ноды тоже в какой-то момент придётся писать не на JS.
Моя либертарианская сущность протестует: вы разжигаете рознь между платформой и прикладниками!

Здравствуйте, Sheridan, Вы писали:

S>>>Это происходит из за совокупности "ой ну всё же работает, трогать не надо", "за это не платят", "на это нет времени".
S>>>Первое — глупость, второе — бабло, третье...

I>>И снова от тебя ни одного конструктивного аргумента.
S>Кроме того что ты исключил из цитаты?

Вот твоя цитата:

Это происходит из за совокупности "ой ну всё же работает, трогать не надо", "за это не платят", "на это нет времени".
Первое — глупость, второе — бабло, третье...
Насчёт третьего — лучше потратить время на обновление/взаимодействие, чем потратить его-же на контейнеризацию и последующее сопровождение.

Где ты здесь видишь конструктив? Тебя не смущает, что вся индустрия исключая фанатиков навроде тебя, давно пошла по другому пути?

Что лучше, а что хуже, определяется целям, сроками, ресурсами и тд. А у тебя похоже лучшесть существует сама по себе. Контейнеризация экономит вагоны времени, в т.ч. на сопровождении, обновлении, сопровождении и тд. Сейчас это настолько дешево и эффективно, что трудее придумать чтото лучшее.
Твоё предложение, фактически, это увеличение инвестиций — то самое время на обновление/взаимодействие. А за счет чего ты собираешься возврат инвестиций обеспечивать?
Уже вроде бы говорили много раз — вложения в производительность/качество софта в большинстве случаев или не окупаются, или окупаются с большим трудом.
И здесь надо вспомнить, что любой труд должен приносить заработок не только тебе, но и твоему работодателю.

Здравствуйте, Sheridan, Вы писали:

S>Все ошибаются, тут спорить сложно. Важно чтобы эти ошибки потом исправлялись. И тут уже неважно — память утекла или ещё что.

ну так вот если в проекте с кучей объектов можно отдать машине за ними следить, так и нужно сделать. Но не забывать, что сборка мусора — только инструмент.

S>

S>А как ты освобождаешь память, выделенную по голому указателю, если прилетает исключение?

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

Здравствуйте, Sheridan, Вы писали:

S>Ну раз уж перегибать то давай сразу писать чтобы без ОС на железо ставилось.

Дак разве ж это я перегибаю? Сам же выдал: чем меньше компонентов, тем надежнее. Число компонентов стремится к нулю, надежность, по твоей логике — к бесконечности. Имеем нечто, стстоящее из одной сущности, без всяких лишних компонентов. Счеты, например. А писать гусиным пером.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, vaa, Вы писали:

S>Ну здесь тоже говорят про 16 мб https://medium.com/@chyyran/calling-c-natively-from-rust-1f92c506289d
S>Возможно в DNNE все таки хостят сборщик мусора. Ну и 16 мб за сборщик мусора не такая уж и огромная затрата.
S> Прошу прощения за редиску

лень проверять, но вот на СОФ про ди compiled with dmd with debug info, statically linked: 77KiB
в ди тоже сборщик мусора.
по сравнению с первыми публикациями по 160Мб это конечно прогресс, но хотелось бы меньше.

Здравствуйте, Sheridan, Вы писали:

НС>>>>Все что нужно знать про полезность твоего кода.
S>>>А, у тебя качество кода измеряется в лайках?
НС>>Не качество, а полезность.
S>А при чём тут полезность если весь срач про качество? Было бы 100500 лайков — код сразу был стал качественным? Так сейчас происходит?

Успокойся — это ты про какое то мифическое качество. А тебе то совсем другое говорят.

Здравствуйте, Sheridan, Вы писали:

S>Надёжность системы зависит от надёжности составляющих её компонентов. Не бывает 100% надёжного ничего. И поэтому каждый добавляемый компонент будет делать систему менее надёжной.
S>И неважно — речь о количестве сервисов окружения для проекта или о количестве шестерёнок в коробке передач.
Зачем тогда увеличивают количество шестеренок в коробке передач? Чтобы тебе насолить? Или в итоге получившаяся надежность достаточна?

Здравствуйте, SkyDance, Вы писали:

SD>"Complexity has to live somewhere" (C)
SD>Более того, фрагментированные "organically grown" языки, среди которых джаваскрипт пожалуй что самый яркий пример "органик роста", куда хуже для понимания, чем спроектированные с нуля с определенными требованиями к дизайну.

Индустрия этого не подтверждает — те самые organically grown заполучают широкую аудиторию, а правильно спроектированные остаются в академическом использовании.

SD>На том же жаваскрипте не получится писать промышленный код без знания всяческих несвязанных друг с другом штуковин.

Прежде всего их нужно знать гораздо меньше, чем в джаве или дотнете.

SD>Другие языки — скажем, Haskell — имеют продуманный фундамент. Его сложнее понять на старте, но поняв, уже не требуется сверяться на каждый чих со stackoverflow в поисках подводных грабель. Поэтому на определенном этапе кривые обучения могут находиться выше или ниже, но в среднем разница будет невелика.

Странно что такое чудо никак не взлетит. 2 десятка лет делали stable release. С тех пор прошло еще 10 лет и как не было его в вакансиях, так и нет. За это время "убогий" жээс вытеснил всех конкурентов в браузере, обосновался на бакенде, пролез даже в микроконтроллеры, в самые разные приложения.

I>>Отсюда ясно, почему фронтенд-разработчики начинают работать чуть не на старте обучения.

SD>Это не из-за языка, а из-за короткого срока жизни их продукта. Бэкенд часто имеет длинный lifecycle, где требуется upfront investment, чтобы не пришлось переписывать все оптом, как это часто происходит с фронтом.

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

Здравствуйте, Sheridan, Вы писали:

S>·>В проектах же это некие условные единицы, к которым сводятся все ресурсы — стоимость рабочей силы, затраты на оборудование, лицензии, требуемое время завершения проекта, етс.
S>Думать над этим не работа программиста.
Технические решения профессионального программиста влияют на эти ресурсы. И он должен понимать какие и сколько ресурсов требует "Система включающая в себя XXX" и сколько другие системы.

Здравствуйте, vaa, Вы писали:

vaa>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, vaa, Вы писали:

S>>Ну здесь тоже говорят про 16 мб https://medium.com/@chyyran/calling-c-natively-from-rust-1f92c506289d
S>>Возможно в DNNE все таки хостят сборщик мусора. Ну и 16 мб за сборщик мусора не такая уж и огромная затрата.
S>> Прошу прощения за редиску

vaa>лень проверять, но вот на СОФ про ди compiled with dmd with debug info, statically linked: 77KiB
vaa>в ди тоже сборщик мусора.
vaa>по сравнению с первыми публикациями по 160Мб это конечно прогресс, но хотелось бы меньше.

Ну в .Net Native https://docs.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation#just-in-time-compilation
пишут

.NET Native включает в заключительные сборки приложения только тот код реализации, который фактически вызывается приложением. Особенно это касается кода сторонних библиотек и кода в библиотеке классов .NET Framework. В результате приложение больше не зависит от сторонних библиотек или всей библиотеки классов .NET Framework; вместо этого код сторонних библиотек и библиотек классов .NET Framework теперь является локальным для приложения.

.NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.

Примечание

.NET Native использует тот же сборщик мусора, что и стандартная среда CLR. В сборщике мусора .NET Native фоновая сборка мусора включена по умолчанию. Дополнительные сведения о сборке мусора см. в разделе Основы сборки мусора.

Здравствуйте, Sheridan, Вы писали:

S>Практика показывает что когда начинаешь думать про бабло — получается гавно. Поэтому думать про бабло не надо. Для этого есть специально обученные люди, у которых есть информация для того чтобы решать сколько можно потратить бабла.

У инженера как минимум есть варианты — быстро-долго. Отсюда ясно, что даже один инженер при должном усердии может выбрать такой вариант, что выйдет за рамки бюджета.
Отсюда ясно, что придется именно инженеру отвечать на вопросы
1. когда будет готово
2. сколько будет стоить клауд с подробным описанием того, что будет в этом клауде
3. какой объем функционала будет реализован

После этого заказчик выбирает то, что ему важнее, насколько срочно все нужно

Но, как мы много раз слышали, "тупой заказчик" @ Sheridan

Здравствуйте, Sheridan, Вы писали:

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

Такое много раз проходили — разработчики могут выбрать супер-надежный, супер-быстрый вариант, который заказчик заведомо не сможет проплатить ни сейчас, ни в будущем.

Как тогда быть?

Здравствуйте, Serginio1, Вы писали:

S> Ну в .Net Native https://docs.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation#just-in-time-compilation
S> пишут
...
S> .NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.

Так это пишут о размере зависимости для приложения. О размере самго приложения ничего не говорится.

Здравствуйте, Sheridan, Вы писали:

S>Практика показывает что когда начинаешь думать про бабло — получается гавно. Поэтому думать про бабло не надо. Для этого есть специально обученные люди, у которых есть информация для того чтобы решать сколько можно потратить бабла.
Неа. Практика показывает, что говно получается как раз тогда, когда не думают про бабло.
Потому что без бабла нет никаких критериев качества решения: на любой вопрос можно ответить "давайте зальём это баблом". Неудобный и многословный синтаксис? Давайте утроим размер команды. Сложно искать ошибки? Давайте нанимать более крутых разработчиков. Жрёт много ресурсов при эксплуатации? Купим в 10 раз больше серверов.

Здравствуйте, Sinclair, Вы писали:

S>Нода тут у нас выступает в роли смелого эксперимента "а занафига нам статик тайпинг, когда мы всё равно большинство ошибок ловим не компилятором, а визуально в браузере".
S>Плюс поверх этого внезапно Хейльсберг достаёт из шляпы кролика со встроенной уткой и так далее — "у нас есть static typing, да ещё и с таким выводом типов, что дотнетчики плачут от зависти!"

S>У меня остаётся некоторый червячок недовольства потому, что виртуальная машина-то там всё равно бестиповая! Это означает, что нода не может пользоваться преимуществами статик тайпинга так, как это делают настоящие компиляторы вроде С++ или дотнета.
S>Понятно, что тормоза начинаются только там, где интенсивные вычисления. А в вебе они у нас где? В известных местах — перекладывание байт в HTTP реквестах и распонсах. Отсюда искушение вынести всё это перекладывание как раз в натив, а прикладной код будет только клеем (здравствуй, нумпи!).
S>Но у меня с давних пор недоверие к билингвальным системам.

Собственно, у меня появилились сомнения после того, как я запилил таки ОДАТА фремворк для Ноды. Хотя мне и удалось существенно обогнать сериализатор дотнета, но потом я узнал, что юзеры имеют обыкновение тащить не 1кб-1мб данных с сервера, а 10 и более мб И без внятной поточности или её эмуляции не обойтись.
Вот здесь жээс хотя и отрабатывает быстрее дотнетного, но морозит эвентлуп. И никаких внятных встроеных средств побороть это нет.
1. webassembly
2. workers
3. async generators
4. ????

Из всего этого внятно смотрится разве что async generators. Остальные два дают чудовищное усложнение, т.к. одата это конская-конская система, конская-конская метадата. Нету варианта "посчитать кусочек на go в webasm". Придется отдавать в webasm чудовищную порцию функционала. Workers тоже интересная вещь — туда-сюда это пенальти на маршалинг и конские-конские издержки.

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

Собственно, как мне кажется, Нода с версии 10 в перформансе особо не продвинулась. От силы, процентов 30 разницы между версиями 10 и 18. Еще недавно в V8 в своё время написали "мы выяснили, что наши оптимизации хорошо справляются с синтетическими тестами и мало чего решают в реальных приложениях"
Собственно, сейчас они начали ускорять сам интерпретатор. Похоже, джит себя исчерпал. Как то так.

Есть вроде бы супер-мега-быстрая just-js, но шота я с ней не экспериментировал. В https://www.techempower.com/benchmarks/ just-js держится довольно высоко. Не проверял, что там за чудо.

Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, Serginio1, Вы писали:

S>> Ну в .Net Native https://docs.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation#just-in-time-compilation
S>> пишут
R>...
S>> .NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.

R>Так это пишут о размере зависимости для приложения. О размере самго приложения ничего не говорится.

Ну вот нативное приложение мало должно отличаться от того же GO со сборкой мусора. Там кроме сборки мусора никакой Jit компиляции нет, а значит и размер того Привет Мир не должен быть 17 мб.
Во всяком случае через DNNE http://rsdn.org/forum/flame.comp/8291260.1

Автор: Serginio1
Дата: 06.06.22

меньше 1мб

Здравствуйте, Serginio1, Вы писали:

S> Ну вот нативное приложение мало должно отличаться от того же GO со сборкой мусора. Там кроме сборки мусора никакой Jit компиляции нет, а значит и размер того Привет Мир не должен быть 17 мб.

Должно-не должно, но превьюшный hello world таки 17 Mb. Сомневась, что к релизу будет как-то заметно лучше.

S> Во всяком случае через DNNE http://rsdn.org/forum/flame.comp/8291260.1

Автор: Serginio1
Дата: 06.06.22

S> меньше 1мб

Это вообще не компилятор, а генератор нативных оберток, чтобы управляемые сборки из натива использовать.

SD>>PS: забавно, что про всякие там stock market большими буквами пишут "past performance is not an indication of the future performance". Про стартапы, однако, так не пишут.
I>Со стартапами примерно так же — перформанс приложения редко бывает индикатором перформанса бизнеса. На собеседованиях в стартапы к перформансу сильно слабый интерес. Максимум про вычислительную сложность спросят и все.

Уфф. Значение слова "performance" — это не про "потребление CPU". И на рынке акций тоже не о CPU на бирже думают.

НС>Нет конечно. Haskell это как раз классический пример "organically grown" языка. Он не создавался как язык, нацеленный на решение какой то конкретной прикладной задачи, это экспериментальная платформа для обкатки различных идей в построении языков. Дело не в том, organically ли язык растет или нет, а в том кто, с каким подходом и бэкграундом к языку прикладывает руку.

В данном случае рост иде не organically, а через вдумчивый дизайн концепций.

Organically — это когда "вот нам здесь потребовалось продырявить класс, и мы запилили friend".
Разница в том, что в случае с дизайном продумывается модель взаимодействия каждой новой фичи со всеми уже существующими. Так что не получается всяких там UB. В случае же с "органическим ростом" фичи приделываются без особого анализа того, как это затронет существующие и будущие фичи.

Опять же, дизайн позволяет рефакторинг языка только если у языка аудитория небольшая, и плохо работает, когда язык "очень популярен" — см. Питон 2 и 3. А когда пользователей уже много, то проще объявить это "новым языком" (Elixir, скажем).

Здравствуйте, Sheridan, Вы писали:

S>Практика показывает что когда начинаешь думать про бабло — получается гавно.

Это какая то очень странная практика у тебя. Потому что обычно наоборот — как перестаешь думать про "limitations imposed by practicality, regulation, safety and cost", то вот тогда то и получается гавно, причем с гарантией.

S> Поэтому думать про бабло не надо.

Нет. Поэтому ты — не инженер.