Здравствуйте, rollcoin, Вы писали:
P>>Но тогда ты сам должен следить за тем, что бы не трогать объект, пока там c ним в фоне идет процессинг. R>Не должен, на то оно и ПЕРЕДАЧА ВЛАДЕНИЯ, которая у тебя куда-то исчезла из жс. Объектом в конкретный момент времени владеет только один ПОТОК и из другого ты сним ничего сделать не сможешь.
У меня ничего не исчезало У меня вычисления требуют кучку всего подряд, эдакий граф объектов. Как это передать в воркер не используя structured clone не совсем понятно.
R>В жс есть SharedBuffers и futex представленный Atomic'ами но это совсем иной уровень абстракции.
Каким чудом мне сконвертировать свои данные в SharedBuffer, что бы не тратить время CPU ?
R>В твоем изначальном посте ты жаловался на то, что 10Мб пользовательских данных у тебя нет возможности без оверхеда обрабаывать в фоне. Так вот есть. Берешь и передаешь свои 10МБ или 1000 в воркер БЕЗ КЛОНИРОВАНИЯ, обрабатываешь их, и так же передаешь обратно.
В общем случае у меня изначально нет никакого SharedBuffer, ArrayBuffer итд. Идея понятна? Т.е. оверхед всё равно будет. А раз так, то не получится выносить в воркер только критичные участки кода. Придется выносить весь процессинг целиком, что увеличивает сложность решения.
А вот использование cluster даёт мне это всё почти забесплатно, строчек 10.
Здравствуйте, vsb, Вы писали:
vsb>1. Легковесность. Стартует быстро, потребляет мало памяти. Если сравнивать с Java — небо и земля.
Потребляет мало памяти — допустим. А как там дела с производительностью? А также с многопоточностью, причем именно с реальной многопоточностью, а не асинхронщиной? А также как там с параллельными вычислениями?
Здравствуйте, elmal, Вы писали:
vsb>>1. Легковесность. Стартует быстро, потребляет мало памяти. Если сравнивать с Java — небо и земля. E>Потребляет мало памяти — допустим. А как там дела с производительностью? А также с многопоточностью, причем именно с реальной многопоточностью, а не асинхронщиной? А также как там с параллельными вычислениями?
Всё плохо, в этом и проблема. Для некоторых вещей можно примастырить тредпул на вебворкерах. Но назвать это решением общего случая вобщем пока что нельзя.
Здравствуйте, elmal, Вы писали:
vsb>>1. Легковесность. Стартует быстро, потребляет мало памяти. Если сравнивать с Java — небо и земля. E>Потребляет мало памяти — допустим. А как там дела с производительностью? А также с многопоточностью, причем именно с реальной многопоточностью, а не асинхронщиной? А также как там с параллельными вычислениями?
С производительностью в моем понимании всё нормально для веб-приложения. С многопоточностью — средства определённые есть, но в целом лучше просто запускать N копий приложения (правда тогда может возникнуть вопрос о памяти, хех). На мой взгляд при адекатной архитектуре в производительность не упрёшься. Что-то критичное можно вынести в отдельный сервис, но это редкость. Обычно веб-приложение тупо ждёт байтов на одном из сокетов (клиенты, БД, другие сервисы) и при их получении немного трансформирует и пересылает. На это производительности хватит.
Здравствуйте, Pauel, Вы писали:
P>>>Шота я вижу, что количество кода на джаве превышает количество кода на Go, с его простынями для обработки ошибок. Ощущение, что любая задача на джаве требует мегабайты кода. P>·>Во-первых, ты как-то проигнорировал Скалу на той же платформе. P>Вроде прямо сказано, что речь про джаву.
О том и речь. Платформа одна и если каких-то языковых фич не хватает, можно сбоку приписать кусок кода на какой-нибудь Скале, с которой всё безшовно интегрируется. Далеко не все платформы такое позволяют.
P>·>А конкретно в яве никогда за экономией строчек не гнались. Там приоритеты другие — код простой, легко читается, легко поддерживается годами-десятилетиями, легко пишется, анализируется и рефакторится в IDE. P>Я большей частью другое вижу — типичный джава код это сразу легаси, который только переписывать или оставить, как есть.
Ну это твои эмоции. По факту с джавы мало кто уходит. Скорее наоборот.
Здравствуйте, Pauel, Вы писали:
P>Ну, не в разы. В джаве слишком много такого легаси, которое никак не ускорить. Джава обходит Ноду в основном за счет многопоточного процессинга.
Это те цифры, которые я лично наблюдал. Если говорить о разбросе latency, а не throughput, то как правило в Ноде вообще с этим печально.
На джаве можно написать медленный код, особенно если использовать разный энтерпрайзнутый мусор вроде Spring и Hibernate, но это значительно сложнее чем на Ноде.
P>Кроме того, общий код это например server side rendering, когда на сервере рендерит тот же код, что и в браузере. А еще всевозможные клиентские библиотеки, которые работают одинаково вне зависимости от платформы, браузер или нода.
Вот по этим словам сразу видно около-фронтэндера. Может быть еще расскажешь, что Next/Nuxt — хорошие фреймворки для server-side разработки?
P>Еще общий код это валидация инпута, что есть часть БЛ.
Валидация — незначительная часть логики. На фронте валидация обычно выглядит сильно иначе, так как нужно выдавать визуальные подсказки пользователю итп.
В своей практике я не видел случаев, когда можно было переиспользовать много кода между фронтом и бэком. Если можешь мне показать успешный пример такого подхода хотя бы среди open-source проектов — мне было бы интересно посмотреть.
Пока все что я видел — это очень смелые, но несерьезные эксперименты вроде фреймворков Meteor и SvelteKit/sapper.
P>Такое много писали про Жээс. И вот каким то чудом этот Жээс в браузере вытеснил всех прямых и непрямых конкурентов из этого самого браузера
С браузером немного другая история. Я от серверных библиотек/фреймворков ожидаю немного других характеристик в плане производительности, безопасности, и стабильности решения.
Вот с этим всем у экосистемы node.js исторически большие проблемы.
P>- апплеты P>- активикс — море таких P>- сервелат P>- флеш P>- целый пласт разновидностей плагинов на С++
Большая часть из этого отвалилось из-за проблем с безопасностью. Да и не все браузеры одинаково хорошо поддерживали все это.
Flash так вовсе убили волевым решением, а так он до сих пор прекрасно жил бы себе в своей маленькой нише.
Здравствуйте, scf, Вы писали:
scf>Вообще есть. Язык, согласен, не принципиален, а вот платформа, исполняющая этот язык — очень даже принципиальна. scf>Серверные приложения пишут на managed языках, т.к. они безопасные. В них отсутствует memory corruption, 99.99% ошибок приводят к отказе в
Языки вроде Rust и Pony — пример нативных языков где почти нет таких проблем. Там вообще решили многие изъяны как C++, так и managed языков. Однако что-то вала серверных приложений на них не наблюдается. Даже C++ значительно популярнее.
scf>обработке одного запроса, тогда как в нативном языке возможно всё — от падения приложения до возврата некорректных данных на всех последующих запросах. Второй важный момент — автоматическая дефрагментация кучи, что позволяет приложениям работать под нагрузкой месяцами без проблем. В нативных языках добиться такого же эффекта сложнее на порядки.
Erlang/Elixir с этой точки зрения вообще прекрасны, там все эти нюансы решены близко к идеалу. Отказоустойчивость — это как раз основной конек Эрланга. Но выбирают писать на них не только лишь все, вернее мало кто это делает.
Мы к сожалению не живем в идеальном мире. Вместо отличных языков/платформ, приходится выбирать из нормальных, заурядных и посредственных.
Здравствуйте, Serginio1, Вы писали:
S>Так что точно не закроют, а развивать будут
По мне так если это чудо за 5 лет не взлетело, то и дальше не взлетит, так и будет бежать по полю махая крыльями, голося и подпрыгивая, пока в овраг не грохнется
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, Serginio1, Вы писали:
S>>Так что точно не закроют, а развивать будут
bnk>По мне так если это чудо за 5 лет не взлетело, то и дальше не взлетит, так и будет бежать по полю махая крыльями, голося и подпрыгивая, пока в овраг не грохнется https://ru.wikipedia.org/wiki/Blazor 5 лет это Blazor Server. И им пользуются напрополую через SignalR . Это все Asp.Net
А вот Blazor WebAssembly всего 2 года. А AOT только год.
Они как раз и хотят ускорить компиляцию и сделать микс аот и интерпретатора https://www.telerik.com/blogs/whats-coming-blazor-dotnet-7
AOT (Ahead Of Time Compilation) Improvements
.NET 6 introduced the ability to compile Blazor applications to WASM, bringing faster performance at the cost of increased app bundle size (AOT-compiled apps can be as much as 2x larger).
Without AOT, your Blazor WASM apps run using a .NET IL (Intermediate Language) Interpreter. Whereas the Interpreter is implemented in WebAssembly, your app isn’t.
Conversely, with AOT, your app is compiled directly to WebAssembly.
Microsoft is considering introducing an AOT mixed mode for .NET 7, which would enable you to use AOT selectively, for specific parts of your app. With this, you could use AOT for the “hot paths” in your app (where performance matters) without massively increasing the size of your overall app.
As well as mixed mode, the team is exploring ways to improve AOT performance:
Tuning the AOT process (specifically to address areas where they currently have to bridge back to the interpreter, resulting in reduced performance)
Exploring further ways to trim unnecessary code in order to bring the overall app size down
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
vsb>При всём при этом у меня нет особо опыта использования этого языка на бэкэнде. Поэтому интересно, что я упустил и почему всем не следует выкинуть всё кроме сабжа.
По мне так все отлично с тайпскриптом
Проблема будет на бэкенде, если на бэкенд есть заметная нагрузка. Однопоточность платформы если есть 128 простаивающих ядер это шоу-стоппер.
Ну и всяких классных плюшек C# да хотя бы типа linq у него (пока?) нет, хотя тот же typeorm например уже что-то.
Здравствуйте, ·, Вы писали:
P>>·>А конкретно в яве никогда за экономией строчек не гнались. Там приоритеты другие — код простой, легко читается, легко поддерживается годами-десятилетиями, легко пишется, анализируется и рефакторится в IDE. P>>Я большей частью другое вижу — типичный джава код это сразу легаси, который только переписывать или оставить, как есть. ·>Ну это твои эмоции. По факту с джавы мало кто уходит. Скорее наоборот.
Наоборот. Дотнет это те, кто не захотел идти в джаву. Нода — оно же. Го — оно же. Раст — оно же.
·>А за что именно ты минуснул это
Здравствуйте, Vermicious Knid, Вы писали:
VK>Это те цифры, которые я лично наблюдал. Если говорить о разбросе latency, а не throughput, то как правило в Ноде вообще с этим печально. VK>На джаве можно написать медленный код, особенно если использовать разный энтерпрайзнутый мусор вроде Spring и Hibernate, но это значительно сложнее чем на Ноде.
Смотри сам https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html
P>>Кроме того, общий код это например server side rendering, когда на сервере рендерит тот же код, что и в браузере. А еще всевозможные клиентские библиотеки, которые работают одинаково вне зависимости от платформы, браузер или нода.
VK>Вот по этим словам сразу видно около-фронтэндера. Может быть еще расскажешь, что Next/Nuxt — хорошие фреймворки для server-side разработки?
Ты ошибся. Next и Nuxt это не для сервер-сайд, а для фулстек разработки на ноде. Это дает бенефиты с т.з. стоимости разработки и управления командами.
Для сервер сайд используются другие вещи, например Nest.
P>>Еще общий код это валидация инпута, что есть часть БЛ.
VK>Валидация — незначительная часть логики. На фронте валидация обычно выглядит сильно иначе, так как нужно выдавать визуальные подсказки пользователю итп.
Тем не мнее, значительная часть библиотек используются и там и там.
VK>В своей практике я не видел случаев, когда можно было переиспользовать много кода между фронтом и бэком. Если можешь мне показать успешный пример такого подхода хотя бы среди open-source проектов — мне было бы интересно посмотреть.
Я же сказал — почти все клиентские библиотеки. Что тебя не устраивает?
VK>Пока все что я видел — это очень смелые, но несерьезные эксперименты вроде фреймворков Meteor и SvelteKit/sapper.
Не в курсе, что это.
VK>Большая часть из этого отвалилось из-за проблем с безопасностью. Да и не все браузеры одинаково хорошо поддерживали все это.
Разумеется, конкуренты не просто так убились, а у них были проблемы которые не смогли устранить. О чем и речь.
VK>Flash так вовсе убили волевым решением, а так он до сих пор прекрасно жил бы себе в своей маленькой нише.
Убили не просто так, а потому что была хорошая альтернатива.
Здравствуйте, vsb, Вы писали:
vsb>При всём при этом у меня нет особо опыта использования этого языка на бэкэнде. Поэтому интересно, что я упустил и почему всем не следует выкинуть всё кроме сабжа.
Хорошо бы понять, что именно нужно от бэкенда, слишком уж общее это понятие. Но поругать так поругать:
1. Миллионы npm, но для сервера там мало чего, а более менее обещепринятого фреймворка с поддержкой можно сказать и нет (хотя тут рядом советуют, можно попробовать). Да, можно все настроить под себя и делать это придется постоянно. То есть всяческие аутентификации, авторизации, хранение сессий, кеширование, роутинг, фоновые задачи, ОРМ и версионирование схем придется колхозить, подбирая либы.
2. npm dependency hell. Мало того, что при каком-то размере package.json добавление в него новой зависимости становится делом нетривиальным, так его еще и обновлять надо регулярно.
3. версии ноды быстро меняются, код который работал на 8 ноде, переставал работать на 12, а это не такой уж большой промежуток времени.
4. Тайпскрипт тоже постоянно обновляется. Не скажу, есть ли проблемы с этим, но рискну предположить, что есть.
5. Если от бэка начинает требоваться перфоманс, прикрутить к проекту что-то скомпилированное не так уж просто, гораздо проще запилить микросервис на C.
6. Всяческие преобразования данных (то, чем постоянно занимается бэк), в коде выглядят на мой взгляд заметно хуже чем на C#/F#/Ruby/Elixir. Но это моя вкусовщина, кому-то и на Go норм. Хотя конструкция/деконструкция хешей в js на высоте, надо отдать должное.
7. Найти годного бэка на js кажется сложнее чем на других языках, но это надо проверять.
Это синтетические бенчмарки, которые не имеют никакой связи с реальными сценариями использования, не учитывают расходы на IO/сеть. Я проверял в более приближенных условиях. На моих типичных сценариях, REST и Websocket API, Нода проигрывала вхлам. При этом я далеко не эксперт ни в Java, ни в Node.js, то есть начальные условия были более-менее равные.
Посмотри бенчмарки techempower, они хотя бы чуть-чуть ближе к реалиям backend разработки. Там твой любимый Nest + Fastify сейчас на 211-й строчке, но в жизни все обстоит еще хуже.
P>Ты ошибся. Next и Nuxt это не для сервер-сайд, а для фулстек разработки на ноде.
Lol, я в курсе что это. С Nuxt даже приходилось иметь дело в реальном проекте. Исправлял за человеком, который не знал что Nuxt не подходит для сервер-сайд и втулил REST API прямо в Nuxt приложение.
P>Тем не мнее, значительная часть библиотек используются и там и там. VK>>В своей практике я не видел случаев, когда можно было переиспользовать много кода между фронтом и бэком. Если можешь мне показать успешный пример такого подхода хотя бы среди open-source проектов — мне было бы интересно посмотреть. P>Я же сказал — почти все клиентские библиотеки. Что тебя не устраивает?
Я же говорю — не видел ни одного случая когда значительная часть кода переиспользуется. Речь не о библиотеках как таковых, а именно о коде приложения.
По факту серверная и клиентская экосистема TS/JS значительно различаются, почти все библиотеки заточены под что-то одно и переиспользования кода не наблюдается. Успешных примеров обратного я не видел даже в open-source, но хотелось бы увидеть раз это декларируется как преимущество TS/Node.js.
P>Убили не просто так, а потому что была хорошая альтернатива.
Не было и нет никакой хорошей альтернативы. HTML5 игры и анимация так до сих пор и не взлетели, несмотря на многочисленные попытки.
Здравствуйте, Pauel, Вы писали:
P>Node быстрее P>spectral-norm — менее 10%
В пределах погрешности...
P>regex-redux — в три раза
Ты не тот исходник показываешь. Вот оно, под капотом. Это не node быстрый, а C++. В java же честная имплементация.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pauel, Вы писали:
P>>>·>А конкретно в яве никогда за экономией строчек не гнались. Там приоритеты другие — код простой, легко читается, легко поддерживается годами-десятилетиями, легко пишется, анализируется и рефакторится в IDE. P>>>Я большей частью другое вижу — типичный джава код это сразу легаси, который только переписывать или оставить, как есть. P>·>Ну это твои эмоции. По факту с джавы мало кто уходит. Скорее наоборот. P>Наоборот. Дотнет это те, кто не захотел идти в джаву. Нода — оно же. Го — оно же. Раст — оно же.
Я тоже так умею. Дотнет это для тех, кого микрософт держал на винде, замена MFC и прочего. Нода — мечта фронтендеров, которые не хотят осваивать другие яп. Раст это C++, системный яп, на что ява никогда не претендовала. А для go это совсем другая ниша, тулзы.
P>·>А за что именно ты минуснул это
? P>А ты разберись, что это такое. Тайпскрипт не исправляет жээс,
Это демагогия. Типизация — тоже исправляет, в прямом смысле этого слова, чтобы компилятор ловил попытки выстрелить в ногу.
nullability из той же оперы, а не осилили. Не знаю везде ли так, но сколько мне не доводилось видеть крупных проектов, все отключают strictNullChecks, ибо вроде как бы есть, но сделано для галочки, сплошные дыры в системе типов.
Впрочем, я, наверное, слишком многого ожидал от typescript... но ведь сабж — просили же поругать.
P> а исключительно типизирует.
Так мой пример был исключительно про типы. Как typescript лажает на пустом месте.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, rollcoin, Вы писали:
R>И каким магическим образом у тебя данные из процесса master оказываются в процессе child через пайп БЕЗ клонирования эти данных?
Здравствуйте, vsb, Вы писали:
vsb>Недавно рефлексировал и понял, что TypeScript мне кажется самым лучшим подходом для бэкэнда. В нём есть всё, чего мне не хватает в других языках/платформах.
Ты не поверишь, но для бэка лучше использовать питон (по сравнению с JS/TS).
У меня вычисления требуют кучку всего подряд, эдакий граф объектов. Как это передать в воркер не используя structured clone не совсем понятно.
