Состоялся релиз Node.js 15.0, платформы для выполнения сетевых приложений на языке JavaScript. Node.js 15.0 относится к ветке с обычным сроком поддержки, обновления для которой будут выпускаться до июня 2021 года. В ближайшие дни будет завершена стабилизация ветки Node.js 14, которая получит статус LTS и будет поддерживаться до апреля 2023 года. Сопровождение прошлой LTS-ветки Node.js 12.0 продлится до апреля 2022 года, а позапрошлой LTS-ветки 10.0 до апреля 2021 года...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53950
А почему про Deno так не клепаются новости на каждый новый релиз?
Потому что никому оно не нужно
местных грамотеев как послушать, так вообще интернеты эти ваши непонятно зачем существуют.
Немного расширю комментарий прошлого оратора. Пока в Deno не будет совместимости с существующими библиотеками для ноды (вроде бы это пилится https://deno.land/std@0.67.0/node/README.md) - он никому не нужен. Если всё равно кардинально менять платформу - то проще на голанг сбежать, например.
Вот не нужно это тут сравнивать, GO нормальный - императивный язык а не это фу... поделие.
Go похож на внебрачную дочь C и непонятно чего по синтаксису. Вот например, зачем там нужны указатели? В Java нет, в JS их нет. Я тогда лучше на голой сяшке попишу, её хотя бы на любой утюг с компилятором вкрячить можно.
А как без указателей делать указатель на указатель на, например, структуру, мм? Указатели топ, если херней не страдать.
потому что в Go копирование по значению:) в не к ночи помянутой Java объекты создаются оператором new.
Согласен убрать указатели и заменить на ссылки, а nul реализовать через Optional<>
указателей нет, но ссылочные типы ведут себя практически так же. постоянно надо проверять на null
Из преимуществ там только статическая типизация и компиляция в один бинарник. Других преимуществ придумать сложно.
Ну, например, Rest API и прочие JSON в стандартной библиотеке.
Ну это не один такой язык у котором в STD есть работа с json. Да и установить такую библиотеку в другом языке не представляется сложным, даже если её нет в STD.
статическая типизация помогает не писать тест на каждый чих. хотя можно использовать TS вместо JS.
+ в Go есть такая шикарная особенность как goroutines
Потому что ты их не пишешь. Подсказка пиши их туда https://www.opennet.ru/announce_news.shtml
> Обработчик unhandledRejection переключен на использование по умолчанию исключений "throw" ... В режиме "throw" при отсутствии явно определённого обработчика unhandledRejection генерирует неперехватываемое исключение, но если обработчик задан поведение не изменится.Что за «фича» такая?
Ловит все необработанные исключения. Что не понятно?
> Что не понятно?Возможно, я не так понял, но получается, что это ВСЕГДА неперехватываемое исключение? Оно ловится каким-то особым catch? Я просто не знаю Node.js, да и JavaScript, вот и уточняю. Может, эта фича действительно интересная. А может и нет.
Если мы делаем fsp.writeFile('qwe.txt', 'aaaaaa').then(...)
И не написали .catch(...) то мы не узнаем если в файл записать не удалось.
Раньше это просто молча глаталось, теперь будет выкидывать ошибку.
А надо не ловить через try, а писать где надо .catch(...).
В случае с async функциями и await fsp.writeFile, оно и так сгенерит эксепшен.
>> Раньше это просто молча глаталось, теперь будет выкидывать ошибку.PIZS$%$AD, И как это жило 14 версий-то? О-о-о
Этот обработчик ловит необработанные исключения - например сделал throw вне блока try-catch. В предыдущих версиях если ты не ставил свой обработчик например так:
process.on('unhandledRejection', (reason, promise) => {
console.log('Unhandled Rejection at:', promise, 'reason:', reason);
// Application specific logging, throwing an error, or other logic here
});
то обработчик по-умолчанию будет просто логировать в консоль типа "ай так нельзя, в будущем будет процесс завершаться". А в новой версии вот как раз включили падение при таком событии.
> AbortControllerКак это до сих пор не переименовали?
В BlackController?
А зачем переименовывать? pro-choiceров в США не травят.
Уже забыл, как Столмана за abortion joke травили?
>код трансформируется в "db.query("select..", function (result) {обработка результата});", при котором управление мгновенно перейдёт к дальнейшему кодуЭто же кошмар!
к асинхронному исполнению еще привыкнуть можно, но у ноды есть такие вот риски
1) в яваскрипте вы можете очень легко сделать замыкание, тогда на каждый вызов обработчика для каждой записи она будет резервировать неожиданно много памяти,
2) у V8 очень ленивый сборщик мусора, поэтому разгребать он начнет через какое-то время после того как весь запрос обработаетсяВ результате может очень легко случиться что запрос на порядка 100к записей может запросто сожрать все ваши гигабайты оперативки, при том что на тестах вы ничего такого не замечали, обьемы-то меньше были
хз, по моим наблюдениям память хорошо подбирает, по крайней мере по сравнению с явой. яве допустим дали 10 гб - она такая оооо гуляем!!! а нода отдаёт быстро обратно.
да, память кушать любит. но не сильно больше, чем руби какой-нибудь
> в яваскрипте вы можете очень легко сделать замыканиеВот это непонятно. В каких случаях замыкание получается легче ожидаемого?
если в асинхронном обработчике использовать переменную из контекста вызывающей функции, например ненароком забыть обьявить через var, а тем более когда специально нужно использовать данные от caller, если по другому их туда не передать. Просто, многие яваскрипт используют а про замыкания не знают, и если в браузерном JS не часто требуется создавать > 100k объектов сразу, то в ноде при работе с sql реально можно нарваться. При том что до какого-то предела в тестах все будет работать, потому что эта память нужна кратковременно и GC ее потом освободит быстро, а в продакшене потом вдруг начинает процесс дохнуть.
пардон, из контекста создающей функции конечно, вызываться-то будет конечно в другом месте
Кошмар? Сразу видно человека, который слабо разбирается и не видит многих классных фич.
А как надо, чтобы не страшно было? Блокировать поток, в ожидании выполнения запроса?Или ты о слишком многословном синтаксисе для лямбд? В смысле надо писать так, чтоб не страшно было:
db.query("select..", |result| {обработка результата});
?
>А как надо, чтобы не страшно было?IMHO, cоздать явно поток, инициализировать мютекс,семафор..., запустить и идти делать свои дела дальше, переодически проверяя мютекс...
Оно как то укладывается лучше в башку, по сравнению с ЖС концепцией:
function(function(function(function{pook})))Хотя, програмист он как шофер, если умеет ездить, то будет водить любую тачку,
другое дело, что крутить руль у КРАЗа посложней чем у бэхи
> IMHO, cоздать явно поток, инициализировать мютекс,семафор..., запустить и идти делать свои дела дальше, переодически проверяя мютекс...Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя 10k таких мьютексов будет, что ты будешь делать?
> Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя
> 10k таких мьютексов будет, что ты будешь делать?Я про концептуальность, прозрачность кода и удобство поддержки.
это разве читаемый код: https://crontab.guru/index.js даже после деобфускации???
Аналогичный вопрос по поводу 10к можно адресовать и ЖС кстати (хотя, каюсь, я даже пофантазировать не могу, что же это такое, на 10к потоков...)
В конце дня любой язык закончится с jnz, jmp, а все эти абстракции придуманны только для удобства коллективного програмирования, с одной лишь целью - предотвратить пересечения имен и повысить скорость выдачи кода людьми которые понятия не имеют, как оно там под капотом все работает. И чем больше абстракций, тем больше понтов и хайпа, а в итоге старый i386 с 4мб памяти работающий под досом, считает шестеренки в разы быстрей чем современный монстр
>> Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя
>> 10k таких мьютексов будет, что ты будешь делать?
> Я про концептуальность, прозрачность кода и удобство поддержки.
> это разве читаемый код: https://crontab.guru/index.js даже после деобфускации???Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации. Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно странно. Ты пробовал читать машинные коды? А после декомпиляции?
> Аналогичный вопрос по поводу 10к можно адресовать и ЖС кстати (хотя, каюсь,
> я даже пофантазировать не могу, что же это такое, на 10к
> потоков...)Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть механизмы ноды из коробки позволяют легко сделать то, что на C ты будешь кодить месяцами.
Проблема 100k асинхронных соединений в том, что довольно сложно сделать это эффективно, когда каждый поток требует не так уж и много действий, но эти действия невозможно сделать "одним куском" без прерываний на ожидание доставки/отправки очередной порции данных. Я так навскидку затрудняюсь порекомендовать образовательных ресурсов на тему, но я вникал когда-то в тему через man select (был какой-то man, который был типа туториала на тему того, как надо), и затем ковыряния в потрохах libpth. Плюс возможно другие какие-то ресурсы о которых я не упомню. Но если ты загуглишь что-нибудь в стиле 100k connections, я думаю ты найдёшь ресурсов на тему.
> В конце дня любой язык закончится с jnz, jmp, а все эти
> абстракции придуманны только для удобства коллективного програмирования, с одной лишь
> целью - предотвратить пересечения имен и повысить скорость выдачи кода людьми
> которые понятия не имеют, как оно там под капотом все работает.Да, пожалуй. Если требовать от каждого, чтобы он понимал бы в деталях все уровни абстракции, начиная с того, на котором он пишет код, и вплоть до исполнительного устройства (будь то CPU или GPU или ещё что), то эти каждые будут выходить на пенсию, не успев закончить учёбу. Это даже если не учитывать того, что период полураспада знаний -- лет десять, наверное. В смысле, через десять лет половина знаний оказывается устаревшей, ибо найдены новые лучшие способы.
> И чем больше абстракций, тем больше понтов и хайпа, а в
> итоге старый i386 с 4мб памяти работающий под досом, считает шестеренки
> в разы быстрей чем современный монстрНет, тут ты вваливаешься в необоснованные обобщения. Или, если тебе хочется описание точнее, то ты берёшь корреляцию между потребляемыми программами ресурсами и количеством абстракций, и делаешь из этой корреляции причинно-следственную связь.
Абстракции абстракциям рознь.
Скажем подход async/await реально даёт возможность красиво скрыть под капотом main-loop с select/epoll, обойтись без разбивания кода работы с соединением на отдельные коллбеки (иметь вместо этого последовательный код, выглядящий не сильно сложнее, чем аналогичный блокирующийся код), и по сравнению с подходом libpth (posix threads в юзерспейсе), обойтись без ручного менеджмента потоками (вместо этого ты программируешь в терминах отдельных задач, не парясь раскладывать эти задачи в кучки, которые потом склеивать "псевдоблокирующим" кодом в потоки, оно само так происходит _устраняя_ ненужную абстракцию юзерспейс потока).
Я очень рекомендую тебе взять C и на нём написать что-то подобное. Скажем http-сервачок, который сможет 100k соединений держать. Ты можешь при этом попробовать разные подходы -- epoll и main-loop руками, libpth, ... эмм... ну async/await не то, чтоб нельзя на C, но их бессмысленно реализовывать на C, с целью понять, хрен поймёшь из-за ущербств синтаксиса. Но на C++, я думаю, можно попробовать. Фишка в том, что если ты это сделаешь, ты поймёшь что все эти три подхода работают одинаково, разница просматривается лишь на уровне высокоуровневого кода. И да, на всё это дело тебе может и потребуется пара мьютексов для организации глобальных структур, да и то только в том случае, если ты попытаешься утилизировать больше одного ядра.
> Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации.
> Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно
> странно. Ты пробовал читать машинные коды? А после декомпиляции?Я не про обфускацию, прогоните через любой деобфускатор и увидите модный стиль
> Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть
> механизмы ноды из коробки позволяют легко сделать то, что на C
> ты будешь кодить месяцами.А где я говорил что то плохое про ноду??? Я про концептуальный стиль програмирования если вы не поняли, который допускает создавать мешанину исходного кода по типу польской конвекции, как в Б3-34 калькуляторе.
> Проблема 100k асинхронных соединений в том, что довольно сложно сделать это эффективно,
Настоящих ассинхронных соединений на 100к не может быть в принципе! Даже на 128 коровом проце.
По одной простой причине, что невозможно физически обеспечить ассинхронность на устройстве у которого не достаточно ресурсов на тру ассинхронность, а значит будет опять виртуальность, которя реализуется програмно
> Я так навскидку затрудняюсь порекомендовать образовательных
> ресурсов на тему,Да я вроде как и не просил... и вообще не собирался впадать в подкапотную демагогию, тем более на этом обезличином ресурсе
> Но если ты загуглишь
> что-нибудь в стиле 100k connections, я думаю ты найдёшь ресурсов на
> тему.Я почему то и не сомневался, что все закончиться к отправке в гугл, хотя даже это и не надо было :)
> Если требовать от каждого, чтобы он понимал бы в деталях
> все уровни абстракции, начиная с того, на котором он пишет код,
> и вплоть до исполнительного устройства (будь то CPU или GPU или
> ещё что), то эти каждые будут выходить на пенсию, не успев
> закончить учёбу. Это даже если не учитывать того, что период полураспада
> знаний -- лет десять, наверное. В смысле, через десять лет половина
> знаний оказывается устаревшей, ибо найдены новые лучшие способы.И что в этом плохого - постоянно учиться? Мы ж с вами не померли ? Даже наоборот - интересно.
Проблема только по моему в том, что электрик должен знать как банально влияет сечение провода на пропускаемый ток, а сантехник знать для чего делается воздушка... так же и програмеры, должны знать как оно там работает на самом деле, вы посмотрите на молодеж, они не програмируют, а просто линкуют готовые фрэймворки не задумываясь об эфективности вообще и не вникая в сущность. Вы посмотрите на сумашествие зависимостей в ноде, в пыхе...
> Скажем подход async/await реально даёт возможность красиво скрыть под капотом main-loop
> с select/epoll, обойтись без разбивания кода работы с соединением на отдельные
> коллбеки (иметь вместо этого последовательный код, выглядящий не сильно сложнее, чем
> аналогичный блокирующийся код), и по сравнению с подходом libpth (posix threads
> в юзерспейсе), обойтись без ручного менеджмента потоками (вместо этого ты программируешь
> в терминах отдельных задач, не парясь раскладывать эти задачи в кучки,
> которые потом склеивать "псевдоблокирующим" кодом в потоки, оно само так происходит
> _устраняя_ ненужную абстракцию юзерспейс потока).Да где я был против асинков??? Наоборот, я считаю это было лучшим что случилось в ЖС.
Весь смысл сказанного мной был в том, что люди очень сильно обьюзают технологию событийного програмирования и как результат, не читаемый, тяжело сопровождаемый код, отсюда масса ЖС фрэймворков, которые рождаются как грибы и также быстро погибают, не смотря на хорошие задумки.
> Я очень рекомендую тебе взять C и на нём написать что-то подобное.А я рекомендую - не рекомедавать, когда вас об этом не спрашивали :)
> Скажем http-сервачок, который сможет 100k соединений держать. Ты можешь при этом
> попробовать разные подходы -- epoll и main-loop руками, libpth, ... эмм...
> ну async/await не то, чтоб нельзя на C, но их бессмысленно
> реализовывать на C, с целью понять, хрен поймёшь из-за ущербств синтаксиса.Бедный nginx... Теперь его перепишут на ноде...
> Но на C++, я думаю, можно попробовать. Фишка в том, что
Вы о чем???
> если ты это сделаешь, ты поймёшь что все эти три подхода
> работают одинаково, разница просматривается лишь на уровне высокоуровневого кода. И да,
> на всё это дело тебе может и потребуется пара мьютексов для
> организации глобальных структур, да и то только в том случае, если
> ты попытаешься утилизировать больше одного ядра.Вы о чем??? Я не собираюсь вам ничего доказывать и писать для этого веб сервак на 100к соединений. Для это есть прекрасный nginx.
Я использую инструменты по назначению, там где нужна высокая производительность, то вы не побьете продуктивность продуктов написанных людими на соответсвующем языке и понимающих хардварь. Если нужно "we moving fast, we breaking things...", то и нода и пых и т.д. и т.п. самый подходящий инструмент.
Вы скорее всего приняли меня за фаната С/С++ коих здесь много, и ошиблись. Для меня языки, операционные системы, технологии - это просто инструменты, которые я применяю по назначению, а не по фанатизму
>> Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации.
>> Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно
>> странно. Ты пробовал читать машинные коды? А после декомпиляции?
> Я не про обфускацию, прогоните через любой деобфускатор и увидите модный стильА я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из чего он был сгенерирован, гадать не решаюсь.
>> Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть
>> механизмы ноды из коробки позволяют легко сделать то, что на C
>> ты будешь кодить месяцами.
> А где я говорил что то плохое про ноду??? Я про концептуальный
> стиль програмирования если вы не поняли, который допускает создавать мешанину исходного
> кода по типу польской конвекции, как в Б3-34 калькуляторе."конвенции". Впрочем, сорри, за грамматические придирки.
Стиль программирования -- это дело привычки. Это я тебе из опыта говорю -- мне приходилось одолевать ассемблер после C, и это было непросто. Потом мне было lisp сложно одолеть. Потом я об хаскелл ломал голову. И несколько лет назад о rust. Если ты не умеешь мыслить о программировании в какой-то специфической концепции -- это не значит, что концепция плохая.
>> Проблема 100k асинхронных соединений в том, что довольно сложно сделать это эффективно,
> Настоящих ассинхронных соединений на 100к не может быть в принципе! Даже на
> 128 коровом проце.
> По одной простой причине, что невозможно физически обеспечить ассинхронность на устройстве
> у которого не достаточно ресурсов на тру ассинхронность, а значит будет
> опять виртуальность, которя реализуется програмноЯ не понимаю, о чём ты здесь. Почему невозможно? Мне кажется, что ты несёшь какую-то чушь, и меня на эту мысль наводит словосочетание "тру ассинхронность" (грамматика сохранена): нет никакой "тру асинхронности": бывает просто асинхронность. Можно, наверное, асинхронность поделить на типы, по выбранному критерию оптимизации -- среднее время обработки запроса, максимальное время обработки запроса, количество обработанных запросов в секунду... Но какой из этих критериев оптимизации наиболее "тру"?
>> Я так навскидку затрудняюсь порекомендовать образовательных
>> ресурсов на тему,
> Да я вроде как и не просил... и вообще не собирался впадать
> в подкапотную демагогию, тем более на этом обезличином ресурсеКак раз, чтобы это не было демагогией, чтобы разговор был бы конструктивным и развивающим, я предлагаю тебе посетить образовательные ресурсы.
>> Но если ты загуглишь
>> что-нибудь в стиле 100k connections, я думаю ты найдёшь ресурсов на
>> тему.
> Я почему то и не сомневался, что все закончиться к отправке в
> гугл, хотя даже это и не надо было :)Ты прямой ссылки ждёшь? Чтобы я выбрал для тебя ресурс, который лучше всего заточен по твой индивидуальный стиль обучения?
Ну глянь например сюда: https://en.wikipedia.org/wiki/C10k_problem
Тут образовательного ничего нет, но зато интересные факты есть: java на linux с 12 ядрами может обрабатывать 10-12 миллионов одновременных соединений. И если твоя "тру асинхронность" так не может, то кому она нафиг нужна?
>> Если требовать от каждого, чтобы он понимал бы в деталях
>> все уровни абстракции, начиная с того, на котором он пишет код,
>> и вплоть до исполнительного устройства (будь то CPU или GPU или
>> ещё что), то эти каждые будут выходить на пенсию, не успев
>> закончить учёбу. Это даже если не учитывать того, что период полураспада
>> знаний -- лет десять, наверное. В смысле, через десять лет половина
>> знаний оказывается устаревшей, ибо найдены новые лучшие способы.
> И что в этом плохого - постоянно учиться? Мы ж с вами
> не померли ? Даже наоборот - интересно.А я не говорил, что это плохо.
> Проблема только по моему в том, что электрик должен знать как банально
> влияет сечение провода на пропускаемый ток, а сантехник знать для чего
> делается воздушка... так же и програмеры, должны знать как оно там
> работает на самом деле, вы посмотрите на молодеж, они не програмируют,
> а просто линкуют готовые фрэймворки не задумываясь об эфективности вообще и
> не вникая в сущность. Вы посмотрите на сумашествие зависимостей в ноде,
> в пыхе...Я тебе вот что скажу: ныть о неразумных молодых поколениях -- это признак конца специалиста, который начал процесс метаморфоза в старпёра. Пора задуматься о пенсии.
> Да где я был против асинков??? Наоборот, я считаю это было лучшим
> что случилось в ЖС.
> Весь смысл сказанного мной был в том, что люди очень сильно обьюзают
> технологию событийного програмирования и как результат, не читаемый, тяжело сопровождаемый
> код, отсюда масса ЖС фрэймворков, которые рождаются как грибы и также
> быстро погибают, не смотря на хорошие задумки.Я не следил за темой достаточно внимательно в процессе её развития, но по моим наблюдениям, именно эти абьюзы эвентуального программирования были одним из основных мотивов для изобретения промисов/асинков. Ну, или если точнее выражаться, то не изобретения, а скорее доведения до уровня массового потребления -- идея-то не новая, в общем.
>> Я очень рекомендую тебе взять C и на нём написать что-то подобное.
> А я рекомендую - не рекомедавать, когда вас об этом не спрашивали
> :)Порекомендуй что-нибудь ещё, я люблю когда мне рекомендуют.
> Вы о чем??? Я не собираюсь вам ничего доказывать и писать для
> этого веб сервак на 100к соединений. Для это есть прекрасный nginx.Ну и зря. Мне ты в любом случае ничего не докажешь, потому что тебе просто нечего доказывать, а отказываясь от столь увлекательного проекта, ты лишаешь себя возможности понять что-либо. И чуть выше ты говоришь о ценности непрерывной учёбы. Да-да. Красивые слова, за которыми пустота. Я всё ж ещё раз порекомендую тебе сделать микро-nginx, причём в нескольких разных вариантах. По-крайней мере это избавит тебя от соблазна говорить про неведомую "тру асинхронность".
> Я использую инструменты по назначению, там где нужна высокая производительность, [...]
Бла-бла-бла. Инструменты под образовательный/развивающий проект выбираются исходя из других критериев. Я рекомендую C, потому как тот позволяет видеть, что происходит на уровне процессора, выделения памяти, общения с ядром и тп. Я бы порекомендовал rust, он лучше подходит, и более того он позволяет реализовать свой собственный рантайм под async/await -- то есть иметь и красивый синтаксис, и в то же время собственноручную реализацию, но rust вызывает аллергию на опеннете, так что я всё же рекомендую C.
> А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из
> чего он был сгенерирован, гадать не решаюсь.Гхм... Вы правда знаете машины которые способны сгенировать довольно сложный логический код приведенный выше??? Код был просто прогнан через минимизатор(он же обфускатор). копи-пастните его хотя бы в jsnice.org и вы поймете что ошибаетесь насчет умности машин, способных генернуть подобный код.
> Стиль программирования -- это дело привычки. Это я тебе из опыта говорю
> -- мне приходилось одолевать ассемблер после C, и это было непросто.
> Потом мне было lisp сложно одолеть. Потом я об хаскелл ломал
> голову. И несколько лет назад о rust.Мне теперь тоже достать баклажан и помериться у кого больше ?
Ну так я начинал с более худшего, с опкодов (т.к друго еще просто не было), сидишь так и ищешь по строкам и столбцам нужный опкод из таблиц... Все еще живой, не помер... :)> Если ты не умеешь
> мыслить о программировании в какой-то специфической концепции -- это не значит,
> что концепция плохая."На вкус и цвет товарища нет" :) Да нормальная концепция, просто сильно обьюзается в коде. На С-ях тоже можно не кисло так обфусцировать код, но этим страдают только дети, а в ЖС это просто какой-то популярный стиль, - написать так, чтоб потом хрен кто что понял...
> Я не понимаю, о чём ты здесь. Почему невозможно? Мне кажется, что
> ты несёшь какую-то чушь, и меня на эту мысль наводит словосочетание
> "тру ассинхронность" (грамматика сохранена): нет никакой "тру асинхронности": бывает
> просто асинхронность. Можно, наверное, асинхронность поделить на типы, по выбранному критерию
> оптимизации -- среднее время обработки запроса, максимальное время обработки запроса,
> количество обработанных запросов в секунду... Но какой из этих критериев оптимизации
> наиболее "тру"?Уфф, Ок, у вас есть 3 мальчика на побегушках и вам надо чтобы они разнесли 3 письма. Это "тру" ассинхронность, если они все вместе паралельно побежали. Теперь вам надо, чтобы пацаны разнесли одновременно 8 писем - Гуд бай "тру" ассинхроность. Нода, как врочем любой другой язык, предоставит вам фэйковую ассинхроность, спрятав под капотом планировщика ядра очень быструю беготню тех 3-х пацанов. И как вы понимаете, даже если пацанята спринтеры, то с увеличением количества писем та самая 100к ассинхронность замедлится независимо от ноды, рaста или ассемблера, т.к. если только три пацана.
> Как раз, чтобы это не было демагогией, чтобы разговор был бы конструктивным
> и развивающим, я предлагаю тебе посетить образовательные ресурсы.Понятно, вы я так понимаю всезнающий отец наставник, чтоб так вот запросто определить уровень собеседника... и послать его... (ну да, правильно, теперь это назавыется на "образовательные ресурсы")
> Ну глянь например сюда: https://en.wikipedia.org/wiki/C10k_problem
> Тут образовательного ничего нет, но зато интересные факты есть: java на linux
> с 12 ядрами может обрабатывать 10-12 миллионов одновременных соединений. И если
> твоя "тру асинхронность" так не может, то кому она нафиг нужна?Смотреть выше
> Я тебе вот что скажу: ныть о неразумных молодых поколениях -- это
> признак конца специалиста, который начал процесс метаморфоза в старпёра. Пора задуматься
> о пенсии.А, ну да, страна советов... помним, помним :)
> Я не следил за темой достаточно внимательно в процессе её развития, но
> по моим наблюдениям, именно эти абьюзы эвентуального программирования были одним из
> основных мотивов для изобретения промисов/асинков. Ну, или если точнее выражаться, то
> не изобретения, а скорее доведения до уровня массового потребления -- идея-то
> не новая, в общем.Угу, долго что то только к этому шли
> Порекомендуй что-нибудь ещё, я люблю когда мне рекомендуют.Ок, - lets work :)
Вы вообще не понимаете то, о чём пишете.И даже не отличаете, и не понимаете чем отличается, асинхронность от параллелизма.
Мальчики бегут параллельно - это параллелизм.
Многопоточность в Linux, например, это и есть аналог асинхронности. И польза в нём огромная, даже без параллелизма (когда есть только один одноядерный процессор), потому что в большинстве случаев процессы чего-то ждут (и не выполняют полезную работу)
>> А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из
>> чего он был сгенерирован, гадать не решаюсь.
> Гхм... Вы правда знаете машины которые способны сгенировать довольно сложный логический
> код приведенный выше??? Код был просто прогнан через минимизатор(он же обфускатор).
> копи-пастните его хотя бы в jsnice.org и вы поймете что ошибаетесь
> насчет умности машин, способных генернуть подобный код.Я не знаю как ты пришёл к выводу о том, как был сгенерирован код, поэтому я продолжу придерживаться своего мнения: код был получен в результате компиляции. Минимизация -- это тоже разновидность компиляции, но я не уверен в том, что ею всё и ограничилось.
>> Стиль программирования -- это дело привычки. Это я тебе из опыта говорю
>> -- мне приходилось одолевать ассемблер после C, и это было непросто.
>> Потом мне было lisp сложно одолеть. Потом я об хаскелл ломал
>> голову. И несколько лет назад о rust.
> Мне теперь тоже достать баклажан и помериться у кого больше ?
> Ну так я начинал с более худшего, с опкодов (т.к друго еще
> просто не было), сидишь так и ищешь по строкам и столбцам
> нужный опкод из таблиц... Все еще живой, не помер... :)То есть я объясняю тебе то, что ты и без меня знаешь? Что ж ты тогда ноешь о стиле программирования, если и так знаешь?
>> Если ты не умеешь
>> мыслить о программировании в какой-то специфической концепции -- это не значит,
>> что концепция плохая.
> "На вкус и цвет товарища нет" :)Это дилетантские глупости. В реальности ты используешь тот стиль, который лучше ложится на задачу, а вопрос твоих личных предпочтений никого не волнует.
> Уфф, Ок, у вас есть 3 мальчика на побегушках и вам надо
> чтобы они разнесли 3 письма. Это "тру" ассинхронность, если они все
> вместе паралельно побежали. Теперь вам надо, чтобы пацаны разнесли одновременно 8
> писем - Гуд бай "тру" ассинхроность. Нода, как врочем любой другой
> язык, предоставит вам фэйковую ассинхроность, спрятав под капотом планировщика ядра очень
> быструю беготню тех 3-х пацанов.Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах. Мы тут с тобой говорим "асинхронность", сокращая термины и как бы подразумевая что все понимают о чём речь, но раз ты не понимаешь, я поясню. Речь идёт об асинхронных коммуникациях. Асинхронность -- это не свойство программы, это свойство тех внешних интерфейсов, с которыми она работает. Когда у тебя даже два сокета, то каждый из них ведёт себя вне всякой связи с другим, и это называется асинхронностью, точнее сокеты называют асинхронными: они не синхронизированы между собой. Когда у тебя есть мышь и клавиатура, которые могут любым образом перетасовывать свои ивенты, типа KeyDown, MouseMove, Button1Down, KeyUp, Button2Down... то это тоже асинхронность, клавиатура и мышь не синхронизированы между собой. Вот KeyDown и KeyUp ивенты синхронизированы, второй всегда следует за первым, а KeyDown и MouseMove не синхронизированы, они асинхронны. Слово "асинхронность" применяют и к описанию программы, чтобы отразить свойство программы справляться с асинхронным вводом/выводом и не синхронизировать принудительно работу разных каналов ввода/вывода из-за своих внутренних ограничений архитектуры. Например, если ты напишешь цикл типа
while let conn = accept(socket) {
let request = conn.read_request();
let response = request.eval();
conn.write_response(response);
conn.close();
}То тогда это синхронный код: ты будешь обрабатывать соединения в порядке поступления, и если одно из соединений зависнет почему-то, то остальные послушно будут ждать. Таким образом этот код будет синхронизировать соединения.
> И как вы понимаете, даже если
> пацанята спринтеры, то с увеличением количества писем та самая 100к ассинхронность
> замедлится независимо от ноды, рaста или ассемблера, т.к. если только три
> пацана.Там вопрос в том, когда сервер прекратит справляться с нагрузкой, то есть когда количество соединений начнёт расти, потому что у сервера не хватает ресурсов на обработку их. По мере роста количества входящих соединений в секунду происходит некоторое замедление (которое может быть несущественным: основное время на обработку может определятеся сетевыми задержками), но в какой-то момент сервер включает отказ в обслуживании. Твоя "тру-асинхронность" сможет работать с десятками, может с сотнями соединений. Если у тебя ядра будут исчисляться сотнями, то может тысячи или десятки тысяч соединений сможет обслуживать -- с уродскими задержками, но сможет. Эти ядра будут простаивать 90% времени (или 99%), в ожидании ввода/вывода, но больше твоя тру-асинхронность выжать не сможет. Если ты включишь преемптивную многозадачность в ядре, и подберёшь scheduler в ядре попроще, который за O(1) сможет переключать задачи, то на сотне ядер может ты до сотни тысяч соединений дотянешься.
Твоя тру-асинхронность нафиг никому не сдалась, даже если ты доплачивать будешь за её использование, потому что она не в состоянии утилизировать наличные возможности возможности, она приводит к тому, что существенную часть времени ядра крутят пустой цикл в ожидании ввода/вывода, или на то, чтобы пересчитывать приоритеты, переключать контексты и выполнять переходы между ring0/ring3. Вместо того, чтобы работать с данными, программа тратит процессорные такты на какую-то хрень.
>> Как раз, чтобы это не было демагогией, чтобы разговор был бы конструктивным
>> и развивающим, я предлагаю тебе посетить образовательные ресурсы.
> Понятно, вы я так понимаю всезнающий отец наставник, чтоб так вот запросто
> определить уровень собеседника...Да у тебя на лбу написано. Если ты этого не понимаешь, то это ещё одна приписка на лбу, которая говорит что предыдущее я понял неверно и завысил твой уровень.
>> Я не следил за темой достаточно внимательно в процессе её развития, но
>> по моим наблюдениям, именно эти абьюзы эвентуального программирования были одним из
>> основных мотивов для изобретения промисов/асинков. Ну, или если точнее выражаться, то
>> не изобретения, а скорее доведения до уровня массового потребления -- идея-то
>> не новая, в общем.
> Угу, долго что то только к этому шлиА ты думаешь такую вещь так просто изобрести? Типа сел, подумал вечерок, придумал, и через недельку выкатил синтаксис async/await и рантайм к нему, позволяющий тянуть миллион соединений?
На это надо много проб и ошибок. Мне неоднократно приходилось читать статьи вида "я тут на досуге взял lighttpd, и попробовал его перепилить вот так, и вот смотрите какие результаты..." Алан Кокс, помнится, чуть ли не в ядро запиливал какую-то фишку, чтобы потом на lighttpd показать, как она отразится на характеристиках работы. Но тут ведь речь ещё о свойствах языка, то есть мало придумать как это сделать на уровне машинных кодов, надо ещё придумать как это записывать в языке, запилить в какой-нибудь язык подходящий синтаксис, в этом синтаксисе запилить http-сервер и померять результаты. И если получилось неочень, то выкинуть всё придумать что-нибудь ещё и повторить эпопею.
Но мало ведь того, хотелось бы иметь подход, который будет работать и с написанием гуёв -- где источников асинхронности не так много, но зато гораздо разнообразнее надо реагировать на это из-за чего код становится сложнее на пару порядков, чем любой http-сервер. Такие вещи крайне сложно запилить, если бы их было просто запилить, то их запилили бы ещё в середине XX века, до изобретения всех этих ваших C.
Если я сейчас легко могу объяснить что такое async/await, как это работает, чем там занят рантайм, как на это хорошо ложатся задачи асинхронного ввода/вывода, то это не потому что async/await придумать просто, а потому что его уже придумали за меня, и я дал себе труд посмотреть на него, и заглянуть под капот. И то, я отмечу, что если взять всё то время, которое я потратил на изучение работы с асинхронным вводом/выводом, то там получится не неделя и даже не две, там выйдет больше.
>> Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах.ждем пример асинхронности для однопоточной программы. И рассказ в чем его преимущества.
>>> Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах.
> ждем пример асинхронности для однопоточной программы.man 7 epoll
> И рассказ в чем его преимущества.
В том, что обрабатывая соединения синхронно, ты будешь обрабатывать их синхронно. Например, если одно из соединений окажется особо тормозным и ты два часа будешь почти ничего не делать, дожидаясь сначала пока клиент зашлёт тебе запрос, а потом дожидаясь когда он примет твой ответ, то все остальные клиенты будут вынуждены смирно ждать, пока ты закончишь с этим клиентом.
Н-да, жалко потеряного времени.
Нарцицизм и демагогия самоучки из подвала, пытающегося оправдать свою нужность на подобных ресурсах как этот. Ты говорил любишь советы, - мой совет слезай как можно скорее с интернет иглы и иди к реальным людям, там все совсем по другому, не как в этом уютном для лентяев местечке.
> Ты говорил любишь советы, - мой совет слезай
> как можно скорее с интернет иглы и иди к реальным людям,
> там все совсем по другому, не как в этом уютном для
> лентяев местечке.Реальные люди, с которыми я общаюсь, в отличие от тебя не имеют никаких проблем понять слово "асинхронность". И все идеи о том, что какой-то практически неудачные решения проблемы могут быть более правильными, чем практически удачные, я им тоже отшиб, поэтому столь дебильных обсуждений не возникает.
Вы умрёте создавать 4 потока с мьютексами и следить за всеми из вашего же примера.
В js просто создадут async функцию и будут программировать в императивном стиле если надо несколько асинхронных операций выполнить
Или объединят промисы
Ну тогда я с вами с того света говорю... если от 4х потоков должен был померетьЯ не против ноды, просто акцентирую, что программеров все больше отдаляют от хардварной реальности накидывая абстрактные вещи. Как не крути, но под капотом в конце дня - это просто обыкновенный цикл с условиями
> function(function(function(function{pook})))Можно писать каллбеки без каллбечного ада и есть промизы.
Например
function asyncFunc(callback) {
https.get("url", (result) => {
result.on("data", (data) => {
callback(data);
}
}.on("error", (error) => {
console.error(error);
});
}
function anotherFunc() {
// blabla
let consoleLog = 1;
asyncFunc((result) => {
if (consoleLog) {
console.log(result);
}
});
}
Да можно конечно, но я про массовый хайп, а не про так надо бы
let result = await db.query("select..");
обработка результата...
> Это же кошмар!Потому что никто так не пишет.
Все пишут уже с использованием асинхронного синтакиса:const result = await db.Query('...');
Правда остались какие-то непонятне любители callback-ов приплюснутые.
эвейты крайне неудобны в сравнении с Rx из мира любителей колбэков
Это не кошмар, это новый макакерский манямирок.
>дополнительно Microsoft развивает вариант Node.js с движком Chakra-Core).Уже не развивает, гугл всех победил
и слава госпаду богу. не нужен микрасофт с их get the facts и eee
Слава гуголу, что всех нагнул.
Вообще-то это неделю назад было.
> 2020-10-20
А слабо вам написать целый браузер на Bash? А я написалТак что вам ЖС не нужен
ссылку, сестра
echo "Целый браузер"
> код трансформируется в "db.query("select..", function (result) {обработка результата});", при котором управление мгновенно перейдёт к дальнейшему коду, а результат запроса будет обработан по мере поступления данныхПытаюсь вспомнить что-нибудь хорошее про ноду, но пока не вспомнил, просто напишу какой-нибудь комментарий.
> Добавлена экспериментальная реализация класса AbortControllerА впрочем, нуевонафиг, коммент уже написан, можно уже ничего не вспоминать.
отличный фреймворк. а уж с параллельными вычислениями там просто сказка о колобке.
Скажите, зачем оно вообще нужно? Для поднятия ЧСВ бывших фронтэндеров, которых раньше не пускали в бекэнд? Как на JavaScript можно писать что-то более менее серьёзное?
Сам не пойму... Чел
..
Когда кто то ответит ударьте.
а что вы можете сказать про php ruby python? Ведь не явой единной, или ?
пхп стоит сравнивать с пёрл, яву с дотнетом, и только с жс никто не конкурирует
ну почему же, нода реально теснит php и python на бэкэнде, ruby там вроде как ни пытался но изза своих косяков не смог сильно распространиться, perl так вообще с 2005-го ушел из веба и не конкурент. Так что по сфере применения js сейчас вполне со старожилами бэкенда конкурирует.
Так php с python это такие обёртки для си по факту (и всё интерпетируемое будет тормозить), а жс нет. При этом у жс были проблемы с однопоточностью, у питона же однопоточность отключается при переходе в сишный код. Какая уж тут конкуренция?
Теснит, угу...
Аж реально.https://w3techs.com/technologies/details/pl-php
https://w3techs.com/technologies/details/ws-nodejsДаже если она кого-то и теснит, то это явно не PHP, потому что он никуда не подвинулся.
Кто в этот бред поверит?
PHP используется для лошья и legacy. Его только WordPress и Drupal вытягивает.Какие бл...сайты? Сайты давным давно хостятся отдельно от бэкэнда.
Этот "бред" знает любой, кто хотя бы мало-мальски плавает в отрасли.
Хипстеры в своих маня-мирках, естественно, мимо.
Уже не теснит. Хайп по ноде уже прошел. И новых проектов на ней стартует все меньше. Как в свое время было с руби.
Как человек, папу лет писавший на backend на Java, а потом на Scala пару лет.Если бы я, как архитектор, выбирал между Java / Scala / Python / PHP и JavaScript Node.js - я бы выбрал последнее.
Во-первых, JavaScript очень хороший и хорошо спроектированный язык, по сравнению с Java. Если взять TypeScript - он вообще 90% проблем JavaScript решает. Это лучший язык на котором я писал.
На JavaScript код пишется в разы быстрее, чем на Java. И он значительно понятнее.
Все Cloud провайдеры AWS / Google Cloud / Azure имеют поддержку Node.js и предоставляют к ней библиотеки для работы со своим облаком.
Если кто-то предоставляет библиотеки поверх API - 95% что в первую очередь он поддерживает Node.js.
Огромное количество кода и библиотек. Большое количество знаний можно применить в смежных областях.
Java очень многословна и монструозна.
Например, я использую TypeORM для SQLITE на мобильных телефонах (React Native).
И эту же TypeORM можно легко использовать в Node.js. Не надо ничего учить. А я потратил большое количество времени на изучение, это большая ORM с кучей возможностей.
IMHO если выбирать javascript для реально больших проектов то всетаки рискуете нарожать множество костылей и велосипедов решая довольно тривиальные задачи. Другое дело что не всякий бэкэнд должен быть большим и толстым; иногда нужны простые вещи которые потом простыми и останутся.
Например, какие?Просто сейчас backend уже совсем не тот, что был раньше.
Сейчас это тонкий клиент к AWS /Google Cloud / Azure. Обвязка.
Он stateless и чисто сетевой. Для этого Node.js подходит идеально.
Масштабирование тоже давно происходит за счёт контейнеров, а не "многопоточности". https://cloud.google.com/appengine/docs/flexible.
Node.js идеален для современного backend, который service oriented. Пришёл JSON -> ушёл JSON.
Ну о том и речь, если тонкий клиент к aws то идеально, а если самим свое облако делать то уже не обязательно.
Да, безусловно. Свой cloud provider на JavaScript писать не стоит. Наверное там нужна максимальная производительность.Но это очень узкая ниша. Я, кстати, писал такой в Parallels. У них был свой софт для развертывания кастомного cloud provider на базе их virtuozzo контейнеров.
Сам cloud provider был написан на Java. Я бы сейчас уже Rust бы взял.
> Пришёл JSON -> ушёл JSON.такая чушь. где в этой схеме полезная нагрузка которая не сводится к одним запросам к БД?
Client-side render.
Поучи наконец современный web. Ты застрял в 90х
Лет 10 назад было модно делать браузерные ммо, так фронт с бэком пилили на жс. Очень топили за это, мол, унификация, проще работать, и вообще серебряная пуля. Понятно, что у ммо бэк это в общем случае обёртка над базой данных, но всё же, есть и такое, и в результате мы все оказались в сегодняшнем болоте. Лично я бы не выбрал жс ни за какие коврижки, и даже на клиенте он нужен только ради юзерскриптов.
Только 10 лет прошло. 10 лет назад это был совсем другой язык.Не было ни модулей, ни пакетов, ни npm, ни библиотек, ни Node.js, ни async / await, ни Promise, ни ... ничего не было. Никаких продвинутых оптимизаций в V8.
Node.js появился May 27, 2009; 11 years ago. Те им ещё никто не пользовался.
10 лет для языка - это бездна, пропасть.
Ну, си за 40 лет не очень поменялся. Особенно не очень за последние 20. Всё так же хорош. D:
Ахахах, я всё понял. "Всё также хорош" ахахах.Тут бесполезно серьезно что-то обсуждать, очень специфичная публика.
Вероятно приходит чисто погундеть про "про..рали все полимеры" и потроллить.
Ты не допёр, что это был сарказм, даже при наличии смайлика для особо одарённых. Так что я тоже всё понял.10 лет не такой уж и срок на самом деле. Я не припомню ни одного промышленного языка со значительными изменениями за 10 лет, едва ли тут есть значительные отличия.
Ну 10 лет назад был переход между Python 2 и Python 3. Я не могу назвать это "незначительным".Java SE 7 и Java SE 15 достаточно сильно отличаются. В Java SE 8 / 9 завесли много новых синтаксических конструкций.
C++11 и C++20 сильно отличаются. Там завезли какие-то type constraints и много чего другого.
Конечно для таких языков никто не ломает совместимость.
Однако новый код сильно отличается от старого.
Если взять питон, то ничего заметного там не случилось в 3. Разве что добавили асинхронную модель исполнения, но он как был однопоточным, так и остался. Что-то перетянули из 3rd-party решений. И ещё немного иного сахара, но ничего из того, что можно назвать прямо изменениями. Это что касается языка, в интерпретаторе cpython провели ряд оптимизаций и изменений с заделом на будущее. Но в основном это новый сахар, и только. Жава допустим, но там в 9 просто отломали совместимость с предыдущими. Насчёт плюсов не знаю -- я до сих пор привыкаю к 11 после 03. Вроде там модули обещали? И сахар, конечно. Но чтобы прямо так уж отличался…
> Если взять питон, то ничего заметного там не случилось в 3.Абсолютно.
> Разве чтовесь старый код внезапно работать перестал, и далеко не всегда починить легко и тривиально.
Поправил, не благодари.
В целом все верно - если пихоновский код надо чинить, а не выбросить, значит, ты выбрал не тот инструмент.
Прохладная история, один и тот же код прекрасно работал в 2 и 3 одновременно. Потом six добавили и поддерживать совместимость вообще просто стало.
> Ну, си за 40 лет не очень поменялся.ну конечно, не очень.
Возьми, скажем, исходники apache1.3, последнего, ему ни разу не сорок лет - и попробуй собрать.
Потом приходи сюда, поржем - сумеешь ты вообще понять, что это значить, или как.Ну, или, вот:
static struct vfs_fn_pointers vfs_xattr_tdb_fns = {
.getxattr_fn = xattr_tdb_getxattr,
.fgetxattr_fn = xattr_tdb_fgetxattr,
.setxattr_fn = xattr_tdb_setxattr,
.fsetxattr_fn = xattr_tdb_fsetxattr,
.listxattr_fn = xattr_tdb_listxattr,
.flistxattr_fn = xattr_tdb_flistxattr,
.removexattr_fn = xattr_tdb_removexattr,
.fremovexattr_fn = xattr_tdb_fremovexattr,
.open_fn = xattr_tdb_open,
.mkdir_fn = xattr_tdb_mkdir,
.unlink_fn = xattr_tdb_unlink,
.rmdir_fn = xattr_tdb_rmdir,
.connect_fn = xattr_tdb_connect,
};в данном случае, конечно, "всепонятна", но это - C99, добравшийся до gcc не так чтоб безумно давно - и, главное - имеет совершенно неочевидный побочный эффект. Если ты учил его по книжке сорокалетней давности - ниразу не угадаешь, какой.
Про static_assert двух перпендикулярных синтаксисов уже молчу, поскольку в общем-то dd, и всех дел.
Лайтовый сугубо опциональный сахар. Что сказать то хотел?
> Как человек, папу лет писавший на backend на Java, а потом на Scala пару лет.
> Во-первых, JavaScript очень хороший и хорошо спроектированный язык,Извиняюсь, но ваши слова звучат не убедительно.
Ну, а мой путь таков C# -> PHP -> Perl -> Node.JS И реально своременный JS самый приятный из них (хотя поначалу тоже от него плевался). Но и сишарп тоже неплохо так эволюционировал за эти годы.
Здесь только про плохое говорить принято, а то заминусят. Обратил внимание, что количество минусов ставят больше в это время, сначала перевес был в положительную сторону, днём. Можно предположить, что в данный момент сидят глубоко несчастные одинокие люди, и им больше ннчем заняться, как гадить на других. (Я не считаюсь, т.к. в командировке)
Да, очень странный сайт. Хотя новости самые интересные и подробные.Здесь надо кричать три вещи "про веб макак", про "не нужно", "нет чтобы написать на нормальном языке C++"
вот поэтому я и ушел с джабы и больше не вернусь
"Если бы я, как архитектор, выбирал между Java / Scala / Python / PHP и JavaScript Node.js - я бы выбрал последнее." - вы точно писали бэкенд?
"Во-первых, JavaScript очень хороший и хорошо спроектированный язык, по сравнению с Java" - всем отделом смеялись. Ага, хорошо спроектированный на коленке за 2 недели. (погуглите wtfjs)
"На JavaScript код пишется в разы быстрее, чем на Java. И он значительно понятнее." - ложь. Оно не понятнее.
"Огромное количество кода и библиотек. Большое количество знаний можно применить в смежных областях" - а в других языках нет библиотек?
"Java очень многословна и монструозна." - и?
А если серьезно. Я писал бэк на JS, TS, C#, и хочу сказать, что писать на JS будет только идиот. На TS еще куда ни шло, но джаваскриптовая экосистема сводит все плюсы TS на нет (если речь идет о крупных проектах). Писать небольшие сервисы на TS можно.
Я писал backend на Java и Scala для мировых компаний, таких как Parallels Inc. и Glidewell Technologies, с высокими требованиями к производительности.Да, современный JavaScript хорошо спроектированный язык. И в первую очередь благодаря архитектуре смог эволюционировать без превращения в неподдерживаемую мешанину, как C++.
Java хуже во всём. Создать npm package - это создать один json файл с названием пакета и версией и готово. В Java надо разбираться с монструозным XML maven или учится мёртвый Groovy для Gradle. Даже такая тривиальная вещь требует нетривиальных усилий и приличного количества времени. Это хорошо видно в Android. Мерзкие скрипты на сотни строк кода в которых сами Java программисты нихрена не разбираются. Коммиты в GitHub это показывают отлично.
Конечно, конечно. Java насколько хороша что до сих пор приходится пробираться через src/main/java/org/company/project/наконец-то.java. Просто передовой язык 2020 года! Удобно. "Код отревьюил"? - Нет, пока только смог открыть / найти код в папках. Ревью уже на завтра отложу ;))) И через всё это приходится пробираться в GitHub и всё протыкивать в мобильном приложении.
В нём есть async / await. Которого нет ни в Java, ни Scala до сих пор. Есть Promises. Есть функции как first-class citizen и higher-order functions. То, чего никогда не было в Java и появилось только в Java 8 в 2014 году с появлением lambda.
Он гораздо ближе к функциональным языкам и стилю программирования, чем Java. И функциональное программирование уже современный стандарт. Даже C++ и Java приходится как-то адаптироваться и костылись новые фичи в языке. Выходит так себе.Java монструозный язык, на нём нужно писать кучу ненужного кода только потому что он создавался как упрощённый C++ (считай, для тупых). И да, удачи с NullPointerException.
Была Scala, но 90% Java программистов не в состоянии её осилить из-за продвинутой системы типов и функционального программирования. Дело заглохло. Они только фабрики фабрик инстансов умеют городить. Элитарность в говнокоде.wtfjs и что там? Дай угадаю, страшилки для тех кто не осилил TypeScript и ===?
В JavaScript 99% процентов ошибок - неявное преобразование типов и неожиданным образом. Всё что тебе нужно сделать - использовать === и всё. TypeScript убирает 99% болячек JavaScript используя суперпродвинутые типы и конструкции и статическому анализу кода. Тебе такого и не снилось, ты наверное вообще не знаешь что такое disjoint types и intersection types. Понимаю, такое в твой замшелый манямирок никогда не придёт. Как и null как отдельный тип.
Увы и ах, но в TypeScript одна из самых передовых систем типов со статическим анализом кода.
Ой,а там где я создаю JSON или объект в несколько символов тебе приходится писать сотни строчек примитивного кода? Даже не сочувствую.
Ложь. JavaScript значительно понятнее. Потому что не надо пробираться через многословность Java, которая сильно отвлекает от понимания кода.
В других языках программирования значительно меньше библиотек, в разы. Может быть даже на порядок. Потому что и программистов высококлассных (как и вообще программистов) значительно меньше. И JavaScript инфраструктура заточена под open source.
> Я писал бэк на JS, TS
То, что ты просто говнокодил на JS/TS это понятно. Но даже это их плюс. Создал файлик index.js и погнали.
Я написал несколько сотен тысяч строчек кода на JavaScript (TypeScript) и ни разу не сталкивался с ошибками преобразований типов (пустая строка в 0 и т.п.)
> Я написал несколько сотен тысяч строчек кода на JavaScript (TypeScript) и ни
> разу не сталкивался с ошибками преобразований типов (пустая строка в 0
> и т.п.)А вы код свой запускали?
Мне нравятся ваши потуги доказать, что js - нормальный язык. Вы очень стараетесь и сами верите в свои слова.
>[оверквотинг удален]
> Ой,а там где я создаю JSON или объект в несколько символов тебе
> приходится писать сотни строчек примитивного кода? Даже не сочувствую.
> Ложь. JavaScript значительно понятнее. Потому что не надо пробираться через многословность
> Java, которая сильно отвлекает от понимания кода.
> В других языках программирования значительно меньше библиотек, в разы. Может быть даже
> на порядок. Потому что и программистов высококлассных (как и вообще программистов)
> значительно меньше. И JavaScript инфраструктура заточена под open source.
>> Я писал бэк на JS, TS
> То, что ты просто говнокодил на JS/TS это понятно. Но даже это
> их плюс. Создал файлик index.js и погнали.Ты либо тролль, либо лжец.
Не обижайся, просто 99 % людей не воспринимают человека всерьез после слов "javascript - хорошо спроектированный язык"
Не стоит забывать что JavaScript невероятно быстрый язык для интерпретируемого.Он всего в 5-7 раз медленнее самого оптимизированного C / C++ / Rust. В некоторых случаях (Regexp) даже быстрее.
Ни в какой другой язык столько бабла / инвестиций / талантливых инженеров не вбухивали.
V8 имеет передовой State of the Art Generational Garbage Collector.
Огромное количество оптимизаций по памяти и выполнению.
Что-то похожее есть только в Java. Остальные языки тихо...в сторонке стоят.
Про tools вообще можно ничего не говорить. Здесь вообще даже близко нет конкурентов.
Не стоит забывать, что это заслуга очень жручих и не всегда оптимальных jit с aot.
Да. Но есть и не жрущие альтернативы.В React Native JavaScript компилится в байт-код, как Java. И выполняется оптимизированной Hermes VM https://hermesengine.dev.
Которая заточена под мобилки, в отличие от V8. Где мало памяти и слабые процессоры.
Есть и движки, заточенные под embedded вообще и internet of things.
https://github.com/jerryscript-project/jerryscriptЕсть и для Web похожий проект https://blog.cloudflare.com/binary-ast
Есть WebAssembly на крайний случай.
> Что-то похожее есть только в Java. Остальные языки тихо...в сторонке стоят.такая чушь. сами же про C, C++, Rust упомянули:) Google также много вложил в Go на котором написаны к слову Kubernetes и Docker.
А C++ имеет Garbage Collection?
У Go примитивный GC, не идёт ни в какое сравнение с тем что есть у JavaScript.Есть статья с хорошим анализом GC у Go. Там примитивный 40летний Mark-And-Sweep.
>> У Go примитивный GC, не идёт ни в какое сравнение с тем что есть у JavaScript.
>> Есть статья с хорошим анализом GC у Go. Там примитивный 40летний Mark-And-Sweep.Эта, та статья за 2012 год? А поновее не нашлось?
> Огромное количество оптимизаций по памяти и выполнению.
> Что-то похожее есть только в Java. Остальные языки тихо...в сторонке стоят.
> V8 имеет передовой State of the Art Generational Garbage Collector.Вы как будто с кастрюлей на голове. Ваш девиз - JS быстрый, всё остальное медленное!
Я не уверен, что вы вообще как-то разбирались в вопросе и сравнивали те же самые сборщики у разных технологий, учитывая как вы бросаетесь словами.
Ну вот и все аргументы типичного анонима с opennet.Сравнивают те, кто исследуют и пишут эти самые сборщики мусора. Я лишь анализирую информацию.
https://stackoverflow.com/questions/7823725/what-kind-of-gar...
> Сравнивают те, кто исследуют и пишут эти самые сборщики мусора. Я лишь анализирую информацию.Здравствуй, программист со стаковерфлоу.
What kind of Garbage Collection does Go use? ... mark-and-sweep ... Asked 9 years ago
> Как на JavaScript можно писать что-то более менее серьёзное?более менее серьёзное: EtherCalc, Etherpad, OnlyOffice, Diagram Maker... google-maps :)
> Как на JavaScript можно писать что-то более менее серьёзное?Вполне неплохо. Другое дело, что, процентов 95% «бэкендов» в принципе не так, чтобы очень серьёзные..
1) "db.query("select..", function (result) {обработка результата});"
легко превращается в
2) "var result = await db.query("select..");"
при условии если db.query умеет в промисы а не коллбеки как в примере 1)
Я знаю точно, асинхронное синхронно...
Это ж надо до такой степени доизголяться.
До чего доизголяться?
promisify
Так и протащили обрезанный AbortController вместо нормальных CancellationToken
Так так так, что тут у нас, релиз тормозного говна.
У нас говнокомментарий! По коням!
Не, питон и рубин пока не релизятся
> Для мультиплексирования соединений используется библиотека libuv, которая является надстройкой над libev в системах Unix и над IOCP в Windows.На самом деле libuv является надстройкой (wrapper) над системными вызовами epoll, kqueue, /dev/poll и select, IOCP, а не libev.
Возможно, имелось ввиду, что библиотека libuv выполняет те же задачи, что и libev + имеет поддержку IOCP в Windows.
Прочитал заголовок, как "Выпуск: скверной JavaScript-платформы Node.js 15.0 ", и не нащёл ошибок.