Если вырасти на III, то IV будет странной и непривычной, от чего будет ощущение неправильности.
Ну не знаю, на мой взгляд, хоть элемент привычки и присутствует, дело им не ограничивается. Во первых, вы сами же пишите, что в третьих Героях замки более равные. Хотя и записываете это в недостатки, почему-то. На деле же это значит, что баланс лучше. Вот уж ни разу ещё не встречал, чтобы жаловались на то, что баланс слишком хороший. Впрочем, он в трёшке не слишком-то и хорош, на самом деле. Но в четвёртых умудрились сделать существенно хуже. Этим может и можно проникнуться, найти челлендж в игре слабым замком, например. Но на мой взгляд, это вполне объективный недостаток.
Во вторых, герой, ходящий и сражающийся сам по себе. Ну вот что хорошего в этом? В названии игры может и есть "Герои", но это всё же стратегия, а не РПГ. А то что герой может прокачаться настолько, что армия становится бесполезна, это уже совсем больной перекос. Игра перестаёт быть стратегией. Да и бредово это, когда один чувак может вынести армию. Если же сделать героя слабым, чтобы было более реалистично, то он будет слишком уязвим и в целом, бесполезен. В общем, это нереально отбалансировать, потому что другие существа стакаются в одну ячейку, а герои нет. Если взять какой-нибудь Disciples II, где никто не стакается, то там герой на поле боя выглядит логично и баланс не нарушается. В общем, делать одновременно стакающиеся и не стакающиеся боевые единицы - заведомо плохая идея. В какой-то момент одно станет бледной тенью на фоне другого, и не важно что именно. Важно, что и в развитие армии, и в развитие героя игрок вкладывает свои силы. Когда в игре есть обесценивание труда, вложенного игроком, это говорит о плохом игровом дизайне. На самом деле, это одна из худших ошибок, которую может допустить игровой дизайнер. Пожалуй, это худший недостаток четвёртых героев. И он объективен. Это не просто дело привычки.
В третьих, отдельно хотелось бы отметить, что идея объединить несколько замков в один - это какой-то бред. И хотя, это пожалуй единственный пункт, который можно отнести к вкусовщине и привычке, но реально, это было первое, что мне сильно не понравилось в четвёрке. Остальные проблемы замечаешь сильно позже. Хуже всего то, что существа первого уровня доступны от обоих замков. Ну и где логика в объединении бесов и скелетов? Бесы это демоны, а скелеты это нежить. Бесы живые, а скелеты мёртвые. Демоны олицетворяют злую сторону природы, а нежить это нарушение самих законов природы, как таковых. Это несовместимые фракции. Конечно, сеттинг можно придумать какой угодно. Но бредовый сеттинг не перестанет быть бредовым, каким бы лором он ни был обмазан.
Итого: баланс плохой, геймдизайн плохой, сеттинг испорчен. Звание одной из худших игр серии вполне заслужено. Хотя, что-то мне подсказывает, что шестые сильно похуже будут. Даже боюсь пробовать.
Много раз спорил на этот счёт с друзьями. На мой взгляд, для стратегии, пошаговость даёт больше реализма, чем, так называемый, реал-тайм. А всё потому, что реал-тайм именно что, только так называемый. Реальная война длится не 30 минут. У стратега могут быть дни на то чтобы подумать над следующим ходом. Да и на тактическом уровне, битва не происходит сильно быстро, уж несколько минут всегда есть, чтобы подумать. Именно пошаговые стратегии приближают к этому. Ни в одной RTS я такого не видел. Последние больше являются симуляцией конвейера - выигрывает тот, кто умеет быстро выполнять заранее отработанные действия, и реагировать на ситуацию, опять же, переключаясь между заранее отработанными шаблонами.
Вариант, что кто-то пытается влезть в её компьютер, пока она на обеде, не рассматривался?
Блокировка учётки происходит только когда она возвращается после обеда. Но ведь она и помимо обеда, наверняка, отлучается от компьютера. Неужто не жмёт Win+L, идя в уборную? Сомневаюсь. Однако же, момент, когда человек спонтанно отлучился, ещё попробуй поймай, особенно, когда у тебя самого работа. Да и вокруг могут быть люди, что является серьёзным препятствием, т.к. даже если там индивидуальный офис, в него ещё надо как-то незаметно зайти. Обед же, это очень удобное время для взлома: время ухода, и что ещё важнее, возвращения цели, известно заранее; в офисе пусто, ибо все на обеде; да и у злоумышленника тоже обед. Вывод: у барышни появился сталкер на работе.
Чё-то как-то странно. Почему Dart наименее популярен в web? Dart, а точнее Flutter применим на мобилках, десктопе и в web. Ну не может он быть в web менее популярен, чем в каком-нибудь embedded или ML.
И как Ruby стал не популярен в web? Что с рельсами случилось? Там вообще есть что-то кроме рельсов?
Современный C# это больше backend и игры, нежели Desktop. Фреймвёрки для Desktop, кажется, вообще заброшены майками.
А теперь представьте что у вас пятнадцать операций, пять из которых определены для каждого из подтипов, а оставшиеся десять только для некоторых, в различных комбинациях. Периодически в них что-то меняется, а ещё добавляются новые подтипы. Счастливой поддержки.
Ну и отдельный вопрос, как избежать рантайм исключений, если операция определена не для всех подтипов?
Это то самое "примерно". А вообще, похоже, что при расчёте процентов, забыли евро в доллары перевести. Поэтому, получилось чуть более "примерно", чем изначально планировалось.
За убийство в штатах дают пожизненное или вышку. Это во первых.
А во вторых, насколько я понимаю эту систему, расчёт идёт на то, что за хорошее поведение можно выйти сильно досрочно. Проще говоря, даже сев на 40 лет, кудряш имеет шансы выйти, скажем, через 10. Видимо, это такая попытка отличить исправившихся от не исправившихся.
При чём тут этичность в области ИИ? Речь об этичности бизнеса в целом. Не важно, чем конкретно занимается компания, пусть хоть гвозди выпускает. Суть в том, что OpenAI является некоммерческой организацией, чья деятельность не направлена на получение прибыли. Во всяком случае, именно это декларировалось официально. И все кто, так или иначе, вносил свою лепту и помогал OpenAI, делали это на условиях, что компания некоммерческая. А теперь, они вдруг начали запускать какие-то коммерческие продукты и работать в интересах Microsoft. Это неправильно, тут даже спорить не о чем. Да, Microsoft вложили миллиард, но они вложили этот миллиард в некоммерческую организацию, в цели которой не входит запуск коммерческих продуктов или помощь своим инвесторам в запуске таких продуктов. Организация постулировала своей целью развитие ИИ в интересах всего человечества. Вкладывая свои деньги в такую организацию, ты с этим соглашаешься. Точка. Попытка Miсrosoft подкупить такую организацию наносит ущерб всему человечеству. Звучит высокопарно, но в данном случае, иначе и не скажешь. Работала организация именно в интересах человечества, а при первых успехах, пришла корпорация Microsoft и решила собрать весь урожай.
Что ещё преступники могли делать с таким количеством смартфонов, кроме как продавать? Владельцами большинства "кирпичей" оказались бы ни в чём не повинные люди, просто купившие смартфон с рук.
Очевидно, взяли что первое под руку попалось. Например, приведённый код на Ada состоит из функции-обёртки, внутри которой ассемблерная вставка. Очень идиоматичный код, ничего не скажешь.
Вот только откуда они возьмутся, творцы эти? Обычно ведь как происходит. Скажем, интересно человеку заниматься художествами всякими. Он погружается в эту область, набивает руку, возможно, получает профильное образование. После этого, если он оказывается востребованным творцом, который не просто новые образы создавать может, но эти образы ещё и оказываются популярны у достаточного числа людей, то рождается знаменитость, звезда. Но если человек не попал в категорию звезды, то он становится "линейным" художником, который рисует всякие иллюстрации и прочий арт, обложки, логотипы там какие-нибудь, иконки к приложениям и т.п. Иными словами, он не оказывается лежащим в канаве неудачником, а имеет нишу, в которой может зарабатывать, принося посильную помощь обществу, и занимаясь приличным, возможно даже любимым делом. Уберите эту нишу, и дорога в искусство станет такой дикой лотереей, что родители начнут своим детям руки ломать, лишь бы те не шли в художники. Ну и разумеется, замените художника на музыканта или писателя - всё будет то же самое. Во всех творческих областях есть ниша для "линейных" специалистов, и не стоит смотреть пренебрежительно, ни на эту нишу, ни на тех, кто в ней занят. Это фундамент, на котором всё держится. Нельзя забраться на вершину горы, если горы нет.
Абсолютно верно. Все остальные "причины" - это просто предлог. Производительность у них, видите ли падает. Пора поднимать вопрос, чтобы время на дорогу от дома до работы и обратно считалось рабочим временем. Ведь оно тратится ради работы. Вот тогда и посмотрим что выгоднее, удалёнка или офис.
Коллапс случился не просто из-за того что электромобилей расплодилось много, а из-за морозов. В мороз электромобили хуже держат заряд, а зарядка занимает больше времени. Именно поэтому инфраструктура не справилась, и именно поэтому это случилось именно сейчас.
Вообще, вот если проводить аналогию с другими, известными мне языками, то обычно бывает 3 вида сущностей, отвечающих за параллельное выполнение: Process, Thread и Task. Терминология может отличаться, но суть та же. Task и Thread делят контекст с основным потоком, а Process это обособленная штука, которая работает в отдельном контексте (собственно, отдельно запущенный процесс). Task является более высокоуровневым по отношению к Thread. Task'и используют Thead'ы под капотом, через Thread Pool. В принципе, когда программист вручную работает с Thread'ами, он тоже должен использовать Thread Pool, если, конечно, хочет делать всё правильно. Да и вообще, по большому счёту, он должен делать всё то, что Task делает под капотом. Иными словами, если в вашем языке есть Task, то необходимость напрямую работать с Thread выглядит сомнительно. Может для каких-то случаев и нужно, тут спорить не возьмусь.
В JS я вижу порезанный Task (он же Promise), вижу Process (он же Worker), и совсем не вижу Thread. С одной стороны, как уже отмечалось выше, если есть Task, то Thread не особо-то и нужен. Проблема только в том, что Promise в JS является порезанной версией классического Task, т.к. два Promise'а не могут быть выполнены одновременно, что означает, что они и под капотом не используют никакие Thread'ы, и просто выполняются по очереди, в одном потоке. Собственно, в документации к ним так и написано. Именно это имеют в виду люди, когда говорят, что JS однопоточный. Несомненно, он может делать внешние вызовы, которые будут работать параллельно. Но сам JS код всегда работает в контексте одного главного потока. Ну, кроме Worker'ов, но они уже не потоки, а процессы.
Честно говоря, не знаю, даёт ли спецификация какие-либо указания на тот счёт, могут ли Promise'ы выполняться параллельно, но текущая реализация во всех известных средах выполнения этого не позволяет, и весь существующий код, написанный на данный момент, не рассчитан на то, что Promise'ы могли бы выполниться параллельно. Если в какой-то реализации такое сделают, то существующий код окажется несовместим с ней, т.к. в runtime посыпятся ошибки связанные с синхронизацией потоков, а точнее, с её полным отсутствием в существующем коде. Можно, конечно, добавить другой вид Promise'ов, и назвать их ParallelPromise (или Task, так будет короче). Но в этом случае, речь идёт уже о новой возможности, которая на данный момент просто отсутствует, как на уровне реализации, так и на уровне документации/спецификации. То есть, тут никак не получается притянуть за уши, что JS, дескать, многопоточный, это среды выполнения халтурят.
Что касается приведённых вами примеров XMLHttpRequest и crypto.pbkdf2, то интереснее было бы увидеть не замеры времени, а принципиальную возможность вызвать гонку за ресурсом, ну там, какое-нибудь падение при попытке одновременно добавить элемент в глобальный массив или премешанный вывод в консоль. А так, сдаётся мне, что только запрос выполняется параллельно, а обработчик события вызывается уже в главном потоке, в порядке очереди. Почему я так думаю? Да потому что я ни разу не видел ни мьютексов, ни критических секций, прочих видов блокировок в JS коде, и при этом всё работает, ничего не падает. Если бы обработчик onload у XMLHttpRequest вызывался в разных потоках, то было бы много веселья. В частности, console.log мог бы запросто перемешать несколько выводов и вывести вам один json внутри другого. Видел подобное неоднократно, только не в JS.
Из всего сказанного получается, что если давать классификацию, то JS однопоточный, асинхронный, многопроцессный язык. На мой взгляд, тому JS, что работает в браузерах, большего и не надо. С DOM, всё равно, не получится работать из нескольких потоков, и бедные фронтендеры только за зря будут страдать. Посмотрите на любой GUI фреймвёрк в любом ЯП, который поддерживает многопоточность, и вы поймёте о чём я говорю. Ни один из них не работает нормально с многопоточностью, и все они требуют обращаться к GUI из основного потока, иначе всё будет плохо. Именно поэтому, в JS и сделана асинхронность в одном потоке. А вот серверному JS параллельные Promise'ы не помешали бы. Но все серверные реализации эксплуатируют браузерные движки, и видимо там просто архитектурно не заложена такая функциональность, потому до сих пор и не добавили.
Замените "безопасный" на "цензурированный", а надёжный на "подконтрольный кому надо". Станет намного понятнее.
Ну не знаю, на мой взгляд, хоть элемент привычки и присутствует, дело им не ограничивается. Во первых, вы сами же пишите, что в третьих Героях замки более равные. Хотя и записываете это в недостатки, почему-то. На деле же это значит, что баланс лучше. Вот уж ни разу ещё не встречал, чтобы жаловались на то, что баланс слишком хороший. Впрочем, он в трёшке не слишком-то и хорош, на самом деле. Но в четвёртых умудрились сделать существенно хуже. Этим может и можно проникнуться, найти челлендж в игре слабым замком, например. Но на мой взгляд, это вполне объективный недостаток.
Во вторых, герой, ходящий и сражающийся сам по себе. Ну вот что хорошего в этом? В названии игры может и есть "Герои", но это всё же стратегия, а не РПГ. А то что герой может прокачаться настолько, что армия становится бесполезна, это уже совсем больной перекос. Игра перестаёт быть стратегией. Да и бредово это, когда один чувак может вынести армию. Если же сделать героя слабым, чтобы было более реалистично, то он будет слишком уязвим и в целом, бесполезен. В общем, это нереально отбалансировать, потому что другие существа стакаются в одну ячейку, а герои нет. Если взять какой-нибудь Disciples II, где никто не стакается, то там герой на поле боя выглядит логично и баланс не нарушается. В общем, делать одновременно стакающиеся и не стакающиеся боевые единицы - заведомо плохая идея. В какой-то момент одно станет бледной тенью на фоне другого, и не важно что именно. Важно, что и в развитие армии, и в развитие героя игрок вкладывает свои силы. Когда в игре есть обесценивание труда, вложенного игроком, это говорит о плохом игровом дизайне. На самом деле, это одна из худших ошибок, которую может допустить игровой дизайнер. Пожалуй, это худший недостаток четвёртых героев. И он объективен. Это не просто дело привычки.
В третьих, отдельно хотелось бы отметить, что идея объединить несколько замков в один - это какой-то бред. И хотя, это пожалуй единственный пункт, который можно отнести к вкусовщине и привычке, но реально, это было первое, что мне сильно не понравилось в четвёрке. Остальные проблемы замечаешь сильно позже. Хуже всего то, что существа первого уровня доступны от обоих замков. Ну и где логика в объединении бесов и скелетов? Бесы это демоны, а скелеты это нежить. Бесы живые, а скелеты мёртвые. Демоны олицетворяют злую сторону природы, а нежить это нарушение самих законов природы, как таковых. Это несовместимые фракции. Конечно, сеттинг можно придумать какой угодно. Но бредовый сеттинг не перестанет быть бредовым, каким бы лором он ни был обмазан.
Итого: баланс плохой, геймдизайн плохой, сеттинг испорчен. Звание одной из худших игр серии вполне заслужено. Хотя, что-то мне подсказывает, что шестые сильно похуже будут. Даже боюсь пробовать.
Много раз спорил на этот счёт с друзьями. На мой взгляд, для стратегии, пошаговость даёт больше реализма, чем, так называемый, реал-тайм. А всё потому, что реал-тайм именно что, только так называемый. Реальная война длится не 30 минут. У стратега могут быть дни на то чтобы подумать над следующим ходом. Да и на тактическом уровне, битва не происходит сильно быстро, уж несколько минут всегда есть, чтобы подумать. Именно пошаговые стратегии приближают к этому. Ни в одной RTS я такого не видел. Последние больше являются симуляцией конвейера - выигрывает тот, кто умеет быстро выполнять заранее отработанные действия, и реагировать на ситуацию, опять же, переключаясь между заранее отработанными шаблонами.
Вариант, что кто-то пытается влезть в её компьютер, пока она на обеде, не рассматривался?
Блокировка учётки происходит только когда она возвращается после обеда. Но ведь она и помимо обеда, наверняка, отлучается от компьютера. Неужто не жмёт Win+L, идя в уборную? Сомневаюсь. Однако же, момент, когда человек спонтанно отлучился, ещё попробуй поймай, особенно, когда у тебя самого работа. Да и вокруг могут быть люди, что является серьёзным препятствием, т.к. даже если там индивидуальный офис, в него ещё надо как-то незаметно зайти. Обед же, это очень удобное время для взлома: время ухода, и что ещё важнее, возвращения цели, известно заранее; в офисе пусто, ибо все на обеде; да и у злоумышленника тоже обед. Вывод: у барышни появился сталкер на работе.
Чё-то как-то странно. Почему Dart наименее популярен в web? Dart, а точнее Flutter применим на мобилках, десктопе и в web. Ну не может он быть в web менее популярен, чем в каком-нибудь embedded или ML.
И как Ruby стал не популярен в web? Что с рельсами случилось? Там вообще есть что-то кроме рельсов?
Современный C# это больше backend и игры, нежели Desktop. Фреймвёрки для Desktop, кажется, вообще заброшены майками.
В общем, местами странная какая-то статистика.
А поможет ли тут резервный канал? Преднамеренно можно и два канала отключить.
А теперь представьте что у вас пятнадцать операций, пять из которых определены для каждого из подтипов, а оставшиеся десять только для некоторых, в различных комбинациях. Периодически в них что-то меняется, а ещё добавляются новые подтипы. Счастливой поддержки.
Ну и отдельный вопрос, как избежать рантайм исключений, если операция определена не для всех подтипов?
Это то самое "примерно". А вообще, похоже, что при расчёте процентов, забыли евро в доллары перевести. Поэтому, получилось чуть более "примерно", чем изначально планировалось.
довольно сомнительной штукой, учитывая что внутри там Linux.
За убийство в штатах дают пожизненное или вышку. Это во первых.
А во вторых, насколько я понимаю эту систему, расчёт идёт на то, что за хорошее поведение можно выйти сильно досрочно. Проще говоря, даже сев на 40 лет, кудряш имеет шансы выйти, скажем, через 10. Видимо, это такая попытка отличить исправившихся от не исправившихся.
Собственно, и без ИИ было понятно, что грош цена этим тестам.
При чём тут этичность в области ИИ? Речь об этичности бизнеса в целом. Не важно, чем конкретно занимается компания, пусть хоть гвозди выпускает. Суть в том, что OpenAI является некоммерческой организацией, чья деятельность не направлена на получение прибыли. Во всяком случае, именно это декларировалось официально. И все кто, так или иначе, вносил свою лепту и помогал OpenAI, делали это на условиях, что компания некоммерческая. А теперь, они вдруг начали запускать какие-то коммерческие продукты и работать в интересах Microsoft. Это неправильно, тут даже спорить не о чем. Да, Microsoft вложили миллиард, но они вложили этот миллиард в некоммерческую организацию, в цели которой не входит запуск коммерческих продуктов или помощь своим инвесторам в запуске таких продуктов. Организация постулировала своей целью развитие ИИ в интересах всего человечества. Вкладывая свои деньги в такую организацию, ты с этим соглашаешься. Точка. Попытка Miсrosoft подкупить такую организацию наносит ущерб всему человечеству. Звучит высокопарно, но в данном случае, иначе и не скажешь. Работала организация именно в интересах человечества, а при первых успехах, пришла корпорация Microsoft и решила собрать весь урожай.
Что ещё преступники могли делать с таким количеством смартфонов, кроме как продавать? Владельцами большинства "кирпичей" оказались бы ни в чём не повинные люди, просто купившие смартфон с рук.
Типа master's degree in murder?
Очевидно, взяли что первое под руку попалось. Например, приведённый код на Ada состоит из функции-обёртки, внутри которой ассемблерная вставка. Очень идиоматичный код, ничего не скажешь.
Вот только откуда они возьмутся, творцы эти? Обычно ведь как происходит. Скажем, интересно человеку заниматься художествами всякими. Он погружается в эту область, набивает руку, возможно, получает профильное образование. После этого, если он оказывается востребованным творцом, который не просто новые образы создавать может, но эти образы ещё и оказываются популярны у достаточного числа людей, то рождается знаменитость, звезда. Но если человек не попал в категорию звезды, то он становится "линейным" художником, который рисует всякие иллюстрации и прочий арт, обложки, логотипы там какие-нибудь, иконки к приложениям и т.п. Иными словами, он не оказывается лежащим в канаве неудачником, а имеет нишу, в которой может зарабатывать, принося посильную помощь обществу, и занимаясь приличным, возможно даже любимым делом. Уберите эту нишу, и дорога в искусство станет такой дикой лотереей, что родители начнут своим детям руки ломать, лишь бы те не шли в художники. Ну и разумеется, замените художника на музыканта или писателя - всё будет то же самое. Во всех творческих областях есть ниша для "линейных" специалистов, и не стоит смотреть пренебрежительно, ни на эту нишу, ни на тех, кто в ней занят. Это фундамент, на котором всё держится. Нельзя забраться на вершину горы, если горы нет.
Абсолютно верно. Все остальные "причины" - это просто предлог. Производительность у них, видите ли падает. Пора поднимать вопрос, чтобы время на дорогу от дома до работы и обратно считалось рабочим временем. Ведь оно тратится ради работы. Вот тогда и посмотрим что выгоднее, удалёнка или офис.
Коллапс случился не просто из-за того что электромобилей расплодилось много, а из-за морозов. В мороз электромобили хуже держат заряд, а зарядка занимает больше времени. Именно поэтому инфраструктура не справилась, и именно поэтому это случилось именно сейчас.
Осталось научиться делать рентген в домашних условиях.
Вообще, вот если проводить аналогию с другими, известными мне языками, то обычно бывает 3 вида сущностей, отвечающих за параллельное выполнение: Process, Thread и Task. Терминология может отличаться, но суть та же. Task и Thread делят контекст с основным потоком, а Process это обособленная штука, которая работает в отдельном контексте (собственно, отдельно запущенный процесс). Task является более высокоуровневым по отношению к Thread. Task'и используют Thead'ы под капотом, через Thread Pool. В принципе, когда программист вручную работает с Thread'ами, он тоже должен использовать Thread Pool, если, конечно, хочет делать всё правильно. Да и вообще, по большому счёту, он должен делать всё то, что Task делает под капотом. Иными словами, если в вашем языке есть Task, то необходимость напрямую работать с Thread выглядит сомнительно. Может для каких-то случаев и нужно, тут спорить не возьмусь.
В JS я вижу порезанный Task (он же
Promise), вижу Process (он жеWorker), и совсем не вижу Thread. С одной стороны, как уже отмечалось выше, если есть Task, то Thread не особо-то и нужен. Проблема только в том, чтоPromiseв JS является порезанной версией классического Task, т.к. дваPromise'а не могут быть выполнены одновременно, что означает, что они и под капотом не используют никакие Thread'ы, и просто выполняются по очереди, в одном потоке. Собственно, в документации к ним так и написано. Именно это имеют в виду люди, когда говорят, что JS однопоточный. Несомненно, он может делать внешние вызовы, которые будут работать параллельно. Но сам JS код всегда работает в контексте одного главного потока. Ну, кромеWorker'ов, но они уже не потоки, а процессы.Честно говоря, не знаю, даёт ли спецификация какие-либо указания на тот счёт, могут ли Promise'ы выполняться параллельно, но текущая реализация во всех известных средах выполнения этого не позволяет, и весь существующий код, написанный на данный момент, не рассчитан на то, что Promise'ы могли бы выполниться параллельно. Если в какой-то реализации такое сделают, то существующий код окажется несовместим с ней, т.к. в runtime посыпятся ошибки связанные с синхронизацией потоков, а точнее, с её полным отсутствием в существующем коде. Можно, конечно, добавить другой вид Promise'ов, и назвать их ParallelPromise (или Task, так будет короче). Но в этом случае, речь идёт уже о новой возможности, которая на данный момент просто отсутствует, как на уровне реализации, так и на уровне документации/спецификации. То есть, тут никак не получается притянуть за уши, что JS, дескать, многопоточный, это среды выполнения халтурят.
Что касается приведённых вами примеров
XMLHttpRequestиcrypto.pbkdf2, то интереснее было бы увидеть не замеры времени, а принципиальную возможность вызвать гонку за ресурсом, ну там, какое-нибудь падение при попытке одновременно добавить элемент в глобальный массив или премешанный вывод в консоль. А так, сдаётся мне, что только запрос выполняется параллельно, а обработчик события вызывается уже в главном потоке, в порядке очереди. Почему я так думаю? Да потому что я ни разу не видел ни мьютексов, ни критических секций, прочих видов блокировок в JS коде, и при этом всё работает, ничего не падает. Если бы обработчикonloadуXMLHttpRequestвызывался в разных потоках, то было бы много веселья. В частности, console.log мог бы запросто перемешать несколько выводов и вывести вам один json внутри другого. Видел подобное неоднократно, только не в JS.Из всего сказанного получается, что если давать классификацию, то JS однопоточный, асинхронный, многопроцессный язык. На мой взгляд, тому JS, что работает в браузерах, большего и не надо. С DOM, всё равно, не получится работать из нескольких потоков, и бедные фронтендеры только за зря будут страдать. Посмотрите на любой GUI фреймвёрк в любом ЯП, который поддерживает многопоточность, и вы поймёте о чём я говорю. Ни один из них не работает нормально с многопоточностью, и все они требуют обращаться к GUI из основного потока, иначе всё будет плохо. Именно поэтому, в JS и сделана асинхронность в одном потоке. А вот серверному JS параллельные
Promise'ы не помешали бы. Но все серверные реализации эксплуатируют браузерные движки, и видимо там просто архитектурно не заложена такая функциональность, потому до сих пор и не добавили.