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

L>сейчас же не только async фиктивная так и new promise — точно также вещает гуи пока тело не закончит.
L>Причем возврат пендинг ничего не меняет — все равно гуи подвешивает.

Странно, что ты ожидал другого на однопоточной модели.

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

K>JS — это не язык, это отрыжка дьявола и порождение тупой обезьяны. Зачем каждый раз откапывать это "нечто" и трясти им как чем-то значимым?? Ну Фортран ещё достаньте, PL/1 где-то завалялся... почему у вас нехватает ума, чтобы один раз и навсегда предать анафеме этот язык-урод?? Всё, времена ЛИСПов и Брэйнфаков прошли, молодёжь! Втыкайте уже в отрасль, хватит этого хипстерства, линупсятины и прочего задротства.

Все бы ничего, только не пойму: что не так с Фортраном? На нем работают не хипстеры, а взрослые бородатые дядьки.

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


I>Ты все хочешь блокирующий асинхронный вызов. Таких в JS нет и не будет.

во-первых, оно есть и будет, например fetch

во вторых, я всего лишь хочу чтобы промис и асинк ф-ии работали в точности как доках,
т.е. чтобы поведение было как у встроенных промис-асинк например как у fetch()

ты кажется никак не можешь врубиться и осознать что для встроенных объектов JS типа промис и асинк ф-ии
функционал реализован полностью, а для тех что програмер пишет сам в JS — нет,
(через new Promise и/или asyn function x())
в частности нет доступа к состоянию промиса который однако можно увидеть через console.log
про это кстати много на стэк оверфлоу статей — народ требует и сабмити баг репорты, а их удаляют...

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

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

L>>сейчас же не только async фиктивная так и new promise — точно также вещает гуи пока тело не закончит.
L>>Причем возврат пендинг ничего не меняет — все равно гуи подвешивает.

I>Странно, что ты ожидал другого на однопоточной модели.

да, хотелось, тем более что в доках мозилы нигде нет что однопоточность это навсегда.
Наоборот в Лисе 57 (квантум) версии открыто написано что css, анимация и эффекты вынесены в многопоточность и гуи более не блокируют

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

I>>Странно, что ты ожидал другого на однопоточной модели.

L>да, хотелось, тем более что в доках мозилы нигде нет что однопоточность это навсегда.
L>Наоборот в Лисе 57 (квантум) версии открыто написано что css, анимация и эффекты вынесены в многопоточность и гуи более не блокируют

В огороде бузина, а в Киеве дядька

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

I>>Ты все хочешь блокирующий асинхронный вызов. Таких в JS нет и не будет.

L>во-первых, оно есть и будет, например fetch

ну и мешанина. Совсем недавно некто loginx утверждал следующее:
"fetch() которая возвращает проимс МГНОВЕННО в состоянии ПЕНДИН"
Вот это и есть неблокирующий вызов — для того и нужен промис. Т.е. возвращается не сам результат, а нечто, с помощью чего ты получишь его, когда нибудь.

То есть, сейчас ты похоже поменял мнение, и фетч стал блокирующим ?
Блокирующий асинхронный вызов это когда fetch удерживает поток до получения всего результата целиком, т.е. пока не вытащит по http все что надо.

Такие вызовы ты можешь наблюдать в ноде, скажем в модуле FileSystem имена функций *Sync.

L>во вторых, я всего лишь хочу чтобы промис и асинк ф-ии работали в точности как доках,

Что такое "асинк ф-ии" ? Я не понимаю твой терминологии, никто ей кроме тебя не пользуется.

L>т.е. чтобы поведение было как у встроенных промис-асинк например как у fetch()

Что такое "встроеные промис-асинк" ?

L>ты кажется никак не можешь врубиться и осознать что для встроенных объектов JS типа промис и асинк ф-ии

Я не знаю, что ты называешь словом "асинк" а пояснять ты отказываешься.

L>функционал реализован полностью, а для тех что програмер пишет сам в JS — нет,
L>(через new Promise и/или asyn function x())

Пример кода в студию.

L>в частности нет доступа к состоянию промиса который однако можно увидеть через console.log
L>про это кстати много на стэк оверфлоу статей — народ требует и сабмити баг репорты, а их удаляют...

Ужос, заговор против нубов !!!!111расрасодинодин

Что тебе даст этот доступ к состоянию промиса ? Все уже сто лет как научились пользоваться промисами. ты что, из прошлого века пишешь или как ?

DM>PS. В данном случае код-то писался на другом языке, более приличном, а в JS потом транслировался компилятором, так что ужасы JS-как-языка тут нерелевантны.

Пардон за буквоедство, но вроде ж существует распространенный термин для трансляции ЯВУ в ЯВУ — transpiler (транспилятор).

Ты пошто LISP сюда приплел, изверг?

В подобного типа задачах важен не только оптимизированный исполняемый код на выходе, но и правильные структуры данных с cache-friendly раскладкой по памяти, и хитрый lock–free (в случае параллелизма с разделяемой памятью).

Параллелизм с разделяемой памятью, я так понимаю, в текущем js принципиально невозможен?
Остается кастомизируемость отображения структур данных на память и дружественность к кешу. Как с этим обстоят дела в javascript?

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

SE>Пардон за буквоедство, но вроде ж существует распространенный термин для трансляции ЯВУ в ЯВУ — transpiler (транспилятор).

Haxe умеет как компилировать в байткод нескольких платформ (например Flash и Neko), так и транслировать в исходники на нескольких языках.
https://haxe.org/documentation/introduction/compiler-targets.html
И каким словом его называть?

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

SE>В подобного типа задачах важен не только оптимизированный исполняемый код на выходе, но и правильные структуры данных с cache-friendly раскладкой по памяти, и хитрый lock–free (в случае параллелизма с разделяемой памятью).

Все так. И именно тут средний JS будет сильно сливать С++, ибо банально индирекций больше и с кэшированием похуже. Это одна из основных причин различия в скорости в этом примере. Еще одна — проверка индексов массивов, а с массивами тут очень много работы.

SE>Параллелизм с разделяемой памятью, я так понимаю, в текущем js принципиально невозможен?

Насколько мне известно, именно так.

SE>Остается кастомизируемость отображения структур данных на память и дружественность к кешу. Как с этим обстоят дела в javascript?

Там есть плоские типизированные массивы чисел, и если очень постараться, можно все данные разместить в одном таком массиве и получить "как в Си", только с постоянными bounds checks. Так как раз делалось в ASM.js, так же (?) вроде обстоят дела в WebAssembly. Разумеется, писать код в таком режиме тяжело, и накладных расходов на извлечение и конверсию данных может быть немало.
Помимо этих массивов дела могут обстоять довольно по-разному в разных реализациях JS (читай — в разных браузерах). Основная структура данных — объект, и как там ложатся данные зависит от того, как он создается и используется. Например, v8 (Хром и родственники) выделит заранее место под все поля, что упоминаются в функции-конструкторе, а если потом будут поля добавляться, они уже идут в хэш-таблицу дополнительную. Банальные целые числа тоже могут храниться по-разному в зависимости от того, что за число и что с ним делают. Маленькие целые лежат одним образом, большие — другим, вещественные — третьим. Большие целые и float'ы часто могут бокситься. И опять все зависит от конкретного интерпретатора, сам язык особых гарантий не дает. Явным образом не покастомизируешь, только подгадывать под поведение популярных JS движков. В итоге боксинга и индирекций получается заметно больше, чем в С/С++, что сказывается на скорости.

DM>по-разному в разных реализациях JS (читай — в разных браузерах).
DM>v8 (Хром и родственники) ...
DM>И опять все зависит от конкретного интерпретатора, сам язык особых гарантий не дает.

Oтсутствие спецификаций и отданные на откуп вендорам детали реализации — это как раз то, что очень сильно раздражает в JS. Уж лучше Java с тоннами JSR на каждый чих.

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

SE>Уж лучше Java с тоннами JSR на каждый чих.

Увы, в браузерах джава себя не оправдала и теперь по сути забанена.