Здравствуйте, VladiCh, Вы писали:
VC>Писать сервисы на C++ это такое...
А какая вообще разница на чём их писать? Всё зависит от того, что сервис делает. Язык определяется предметной областью.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, vaa, Вы писали:
vaa>>а вместе с компиляцией?
scf>$ time javac Hello.java
scf>real 0m0,315s scf>user 0m0,842s scf>sys 0m0,034s
scf>Но нужно понимать, что при старте ноде нужно парсить весь код, тогда как при инкрементальной компиляции пересобирается только один файл.
ну, получается хоть инкрементальная компиляция хоть нет java медленнее даже в старте байткода.
про ноду не уверен но по-моему это первая оптимизация которая делается в современных компиляторах пересборка только изменений.
dlang один из первых научился таким трюкам, у них даже есть утилита rdmd — запуск исходников.
но конечно тс нишевый, создавался как замена жс. не думаю что он будет хорош во всем. не "общего назначения" яп.
Здравствуйте, vaa, Вы писали:
vaa>ну, получается хоть инкрементальная компиляция хоть нет java медленнее даже в старте байткода.
наверное, я не очень хорошо объясняю)
При старте приложения движок должен выполнить три операции:
— инициализация самого движка (и нода, и джава делают это быстро)
— загрузка кода приложения в память: здесь нода позади, т.к. ей необходимо парсить и валидировать исходники из огромного кол-ва файлов, тогда как jvm грузит зипованный байткод из пары десятков архивов
— инициализация загруженного приложения: здесь нода тоже позади, т.к. работает она медленней JVM
Положение еще сильнее усугубляется тулчейном ноды — который написан на том же js, т.е. он тоже медленней аналогичного тулчейна JVM. Плюс транспайлеры — которые медленнее того же компилятора java, по тем же причинам.
Здравствуйте, Anton Batenev, Вы писали:
AB>Думаю, что подобный опыт мало у кого есть, т.к. на бэке nodejs практически никогда не используется — это все же фронтовый стек (хотя понятно, что при специфических вкусах фронт можно хоть на C++ писать, за примерами далеко ходить не надо).
Это мягко говоря не так — стоит поискать fullstack typescript вакансии, и сразу найдется уйма таких. И сам Node тоже встречается, но пореже, чем fullstack.
Здравствуйте, CreatorCray, Вы писали:
CC>А какая вообще разница на чём их писать? Всё зависит от того, что сервис делает. Язык определяется предметной областью.
Вообще есть. Язык, согласен, не принципиален, а вот платформа, исполняющая этот язык — очень даже принципиальна.
Серверные приложения пишут на managed языках, т.к. они безопасные. В них отсутствует memory corruption, 99.99% ошибок приводят к отказе в обработке одного запроса, тогда как в нативном языке возможно всё — от падения приложения до возврата некорректных данных на всех последующих запросах. Второй важный момент — автоматическая дефрагментация кучи, что позволяет приложениям работать под нагрузкой месяцами без проблем. В нативных языках добиться такого же эффекта сложнее на порядки.
Здравствуйте, Vermicious Knid, Вы писали:
vsb>>1. Легковесность. Стартует быстро, потребляет мало памяти. Если сравнивать с Java — небо и земля. VK>Java при этом работает в разы быстрее. А легковесность оказывается на практике не такая легковесная. Тот же Python жрет памяти в разы меньше.
Ну, не в разы. В джаве слишком много такого легаси, которое никак не ускорить. Джава обходит Ноду в основном за счет многопоточного процессинга.
vsb>>6. Совместимость с браузером. Какие-то куски кода можно держать общими между бэком и фронтом. VK>На практике этого никогда не происходит. В браузер ты например не засунешь модные ORM, почти никак не переиспользуешь бизнес-логику. VK>Ну и не нужно этого делать, от этого больше вреда чем пользы.
На практике стоит послушать практиков. Общий код это необязательно ORM или BL, хотя и такое возможно.
В браузере никто не юзает ORM по той простой причине, что открытая наружу БД это уязвимость, её закрывают всеми возможными способами, прячут за АПИ фасадом. Но если это вдруг не так — используй сколько влезет.
Например, бразуерный движок десктоп приложения навроде атом, электрон спокойно себе работает с ORM
Кроме того, общий код это например server side rendering, когда на сервере рендерит тот же код, что и в браузере. А еще всевозможные клиентские библиотеки, которые работают одинаково вне зависимости от платформы, браузер или нода.
Еще общий код это валидация инпута, что есть часть БЛ.
VK>Я использовал немного. На мой субъективный взгляд серверные библиотеки/фреймворки для Node.js — неюзабельный кал. VK>В сравнении с Python, Java/Scala/Kotlin, Go. Даже .NET Core выглядит неплохо на фоне Node.js.
Такое много писали про Жээс. И вот каким то чудом этот Жээс в браузере вытеснил всех прямых и непрямых конкурентов из этого самого браузера
— апплеты
— активикс — море таких
— сервелат
— флеш
— целый пласт разновидностей плагинов на С++
— практичечески все ЯП, которые в разное время поддерживались тем или иным браузером включая vbs, python(sic!), perl(sic!), rexx(sic!), tcl(sic!)
Здравствуйте, ·, Вы писали:
·>В общем, для фронта оно ещё норм, когда альтернативой является Javascript, но для бэка есть гораздо лучшие яп. Возьми java, гораздо стабильнее и предсказуемее. Если экзотики хочется с типами, то можешь в "интересных" местах прикручивать Скалу. По поводу легковесности — это как напишешь. Если всякие спринги выкинуть, то всё летает.
Шота я вижу, что количество кода на джаве превышает количество кода на Go, с его простынями для обработки ошибок. Ощущение, что любая задача на джаве требует мегабайты кода.
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, vsb, Вы писали:
vsb>>>Недавно рефлексировал и понял, что TypeScript мне кажется самым лучшим подходом для бэкэнда. В нём есть всё, чего мне не хватает в других языках/платформах.
S>>Blazor!! S>>https://www.telerik.com/blogs/whats-coming-blazor-dotnet-7
D>Минус за то что постоянно пихаешь линки без собственных мыслей
Ну там же все написано! Надо же читать. Блазор развивается при этом и с в качестве десктоп и мобилок MAUI.
То есть в браузере WASM, а на мобилках и десктопе нативно.
Ну и в браузере идет скрещивание AOT и интерпретатора.
Скрещивание WASM с получением с сервера данных отредеринных данных
Ну и больше событий прикручивают. Ну все пересказывать утомительно. Почитай!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
vsb>При всём при этом у меня нет особо опыта использования этого языка на бэкэнде. Поэтому интересно, что я упустил и почему всем не следует выкинуть всё кроме сабжа.
Есть одна большая дыра — event loop, который блокируется даже небольшими вычислениями. В других платформах такие легко выталкиваются в воркеры, а вот на ноде это может быть затруднительно по ряду причин.
Скажем, я тут написал ODATA реализацию на TypeScript, в ней сериализатор работает быстрее как джавовского, так и дотнетного, и обгоняет graphql как стоячего.
Но штука в том, что юзеры иногда тащут дикие объемы, до десятков мб, бесноватые, не иначе. Вот с такими пейлоадами нода блокируется намертво, и нет ни единого способа это облегчить, кроме как мастырить "зелёные потоки" унутре ноды и самому заниматься шедулингом.
Скажем, воркеры здесь не помогают, т.к. структурное клонирование сжирает чудовищное количество времени туда и обратно. Несколько помогает cluster, но и здесь рано или поздно случается та же беда. Лоадбалансер может выручить, но не сильно понимаю, насколько это эффективно.
Я то нашел решение для своего случая, но вот далеко не факт, что такое везде применимо.
Т.е. некоторые классы задач, которые явно или неявно требуют длинных вычислений, надо ограничить.
Соответсвенно Node используется или как простой бакенд, или как edge service, или api фасад.
Здравствуйте, Pauel, Вы писали:
P>·>В общем, для фронта оно ещё норм, когда альтернативой является Javascript, но для бэка есть гораздо лучшие яп. Возьми java, гораздо стабильнее и предсказуемее. Если экзотики хочется с типами, то можешь в "интересных" местах прикручивать Скалу. По поводу легковесности — это как напишешь. Если всякие спринги выкинуть, то всё летает. P>Шота я вижу, что количество кода на джаве превышает количество кода на Go, с его простынями для обработки ошибок. Ощущение, что любая задача на джаве требует мегабайты кода.
Во-первых, ты как-то проигнорировал Скалу на той же платформе. Плюс куча ещё других ЯП для любителей, типа кложуры, котлина и т.п.
А конкретно в яве никогда за экономией строчек не гнались. Там приоритеты другие — код простой, легко читается, легко поддерживается годами-десятилетиями, легко пишется, анализируется и рефакторится в IDE.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, rollcoin, Вы писали:
R>Как может помочь cluster и не помочь воркеры, если и те и другие используют клонирование?
cluster использует не клонирование, а пайп master<->child, что обходится дешевле структурного клонирования.
P>>Скажем, воркеры здесь не помогают, т.к. структурное клонирование сжирает чудовищное количество времени туда и обратно.
R>Что мешает использовать не клонирование, а передачу владения? Это собственно та самая фича, которую имеют воркеры и не имеют форки кластера.
Нету в жээсе такой вещи, как передача владения — жээс однопоточный, потому с т.з. жээса владение никуда не передаётся. Потому и пошли по пути структурного клонирвания. Во всяких движках околобраузерных такую вещь добавили, чтото навроде pass by reference. Но тогда ты сам должен следить за тем, что бы не трогать объект, пока там c ним в фоне идет процессинг.
Это далеко не всегда возможно, и приходится вводить всякие примитивы синхронизации, те самые мутексы и семафоры, что убивает весь профит.
Здравствуйте, ·, Вы писали:
P>>Шота я вижу, что количество кода на джаве превышает количество кода на Go, с его простынями для обработки ошибок. Ощущение, что любая задача на джаве требует мегабайты кода. ·>Во-первых, ты как-то проигнорировал Скалу на той же платформе.
Вроде прямо сказано, что речь про джаву.
·>А конкретно в яве никогда за экономией строчек не гнались. Там приоритеты другие — код простой, легко читается, легко поддерживается годами-десятилетиями, легко пишется, анализируется и рефакторится в IDE.
Я большей частью другое вижу — типичный джава код это сразу легаси, который только переписывать или оставить, как есть.
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, rollcoin, Вы писали:
R>>Как может помочь cluster и не помочь воркеры, если и те и другие используют клонирование?
P>cluster использует не клонирование, а пайп master<->child, что обходится дешевле структурного клонирования.
И каким магическим образом у тебя данные из процесса master оказываются в процессе child через пайп БЕЗ клонирования эти данных?
P>>>Скажем, воркеры здесь не помогают, т.к. структурное клонирование сжирает чудовищное количество времени туда и обратно.
R>>Что мешает использовать не клонирование, а передачу владения? Это собственно та самая фича, которую имеют воркеры и не имеют форки кластера.
P>Нету в жээсе такой вещи, как передача владения
JS не обнопоточный. Начиная с того, что весь ввод\вывод работает поверх пула тредов. Заканчивая тем, что каждый изолят — это отдельны поток. Изоляты — это воркеры, и например ифреймы, которые не соблюдают same-origin policy.
Здравствуйте, Serginio1, Вы писали:
S>>>Blazor!! S>>>https://www.telerik.com/blogs/whats-coming-blazor-dotnet-7
D>>Минус за то что постоянно пихаешь линки без собственных мыслей S> Ну там же все написано! Надо же читать. Блазор развивается при этом и с в качестве десктоп и мобилок MAUI.
Да они его уже несколько лет пихать пытаются, а воз и ныне там — не нужен (ни одного упоминания).
Я думаю закроют нафик этот проект через годик-другой на фоне экономии бюджета в грядущий кризис.
P>Во всяких движках околобраузерных такую вещь добавили, чтото навроде pass by reference. https://nodejs.org/api/worker_threads.html#portpostmessagevalue-transferlist
P>Но тогда ты сам должен следить за тем, что бы не трогать объект, пока там c ним в фоне идет процессинг.
Не должен, на то оно и ПЕРЕДАЧА ВЛАДЕНИЯ, которая у тебя куда-то исчезла из жс. Объектом в конкретный момент времени владеет только один ПОТОК и из другого ты сним ничего сделать не сможешь.
P>Это далеко не всегда возможно, и приходится вводить всякие примитивы синхронизации, те самые мутексы и семафоры, что убивает весь профит.
В жс есть SharedBuffers и futex представленный Atomic'ами но это совсем иной уровень абстракции. Они нужны как раз тогда, когда тебе надо обрабатывать большие объемы данных из нескольких потоков. Все точно так же,к ак и в других языках — можешь не использовать атомарные операции, и получай гонку.
В твоем изначальном посте ты жаловался на то, что 10Мб пользовательских данных у тебя нет возможности без оверхеда обрабаывать в фоне. Так вот есть. Берешь и передаешь свои 10МБ или 1000 в воркер БЕЗ КЛОНИРОВАНИЯ, обрабатываешь их, и так же передаешь обратно.
Здравствуйте, rollcoin, Вы писали:
P>>cluster использует не клонирование, а пайп master<->child, что обходится дешевле структурного клонирования.
R>И каким магическим образом у тебя данные из процесса master оказываются в процессе child через пайп БЕЗ клонирования эти данных?
Структурное клонирование намного дороже обычного копирования байтов.
R>>>Что мешает использовать не клонирование, а передачу владения? Это собственно та самая фича, которую имеют воркеры и не имеют форки кластера.
P>>Нету в жээсе такой вещи, как передача владения
R>Здрасти приехали.
Ну ок:
1. ArrayBuffer — скажи, пожалуйста, кто именно выдаст мне ArrayBufer на мой граф объектов, и за чей счет банкет?
2. structuredClone() — гы-гы
3. аналогично и с другими объектами, например, стримами итд.
R>JS не обнопоточный.
Жээс — однопоточный. Это значит, что инструкции яп выполняются ровно в одном потоке. Но этот поток оркестрирует тред пул для ио итд. Но это уже не жээс, а виртуальная машина, которая в браузере своя, в ноде — своя. Называть это жээсом некорректно.
