На этом фото мы видим, как группа JS-программистов реализует функцию сложения двух чисел

На этом фото мы видим, как группа JS-программистов реализует функцию сложения двух чисел
Вы смотрите срез комментариев. Показать все
214
Автор поста оценил этот комментарий

Забавно как на js пытаются навесить именно этот стереотип. Ибо самое страшное кроется в упорядоченно-асинхронных вызовах неблокирующих, но синхронных велосипедов, едущих асинхронно относительно друг-друга, но синхронных относительно вызова последнего асинхронного вызова последнего синхронного велосипеда. Но от этого у helloworld'щиков уже голова лопнет, и мемы будет некому постить.

раскрыть ветку (202)
104
Автор поста оценил этот комментарий

ехал await через реку

видит await в реке await

сунул await await в await

await await await await

раскрыть ветку (5)
14
Автор поста оценил этот комментарий
Горшочек, не вари!
2
Автор поста оценил этот комментарий

Истинно  только для ES6 и выше

2
Автор поста оценил этот комментарий

Вот я вполне норм отношусь к синтаксическому сахару в JS. Очень многие вещи вполне даже юзабельны, несмотря что введены для тех, кто не смог в прототипы... Хотя let и const тоже хорошие штуки, хоть и const сделано через жопку. Но этот await реально не пришей к пизде рукав. Для тех кто не осилил простейшие промисы.

Блин,промис, это тупо функция конструктор (вспомните про new), которая хранит в себе список then кэлбэков, список catch кэлбэков и все... Нет блять надо придумать такуюконстркцию, которая просто нахер не  нужна...

раскрыть ветку (2)
2
Автор поста оценил этот комментарий

async await как раз избавляет от callback hell'a. Пока у тебя маленькие функции с несколькими then'ами, все ништяк, но когда их 20-30, код превращается в нечитабельную хрень. Тут либо писать свой конечный автомат, либо использовать сахар из await'ов. У меня лично на ноде есть участки кода, где мне нужно дохрена разных запросов дожидаться, потом еще все это заворачивать в Promise.all() и собирать аггрегат из всех этих данных. Даже не представляю как бы это выглядело с then'ами

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

В какой-то момент на одном проекте я написал свой Promise для избавления от проблем.

И да, я видел много вложенных промисов, где это выглядело нормально (просто код разбит по методам и это выглядит вполне хорошо).

async await просто априори это заставляет делать (что не мешает в нем же наговнякать).

205
Автор поста оценил этот комментарий
Предпросмотр
раскрыть ветку (30)
97
Автор поста оценил этот комментарий

И тут за стол садиться Ассемблер.

раскрыть ветку (25)
192
Автор поста оценил этот комментарий
Ассемблер не может сесть за стол. Он сам стол.
раскрыть ветку (8)
89
Автор поста оценил этот комментарий

Он стол, стул, комната, игрок, карты. Ассемблер это всё вокруг, он божество этого огромного мира. Если дать ему закодится и скомпилироваться в телесную форму, у его противников нет ни единого шанса. Он не может проиграть, он - игра.

раскрыть ветку (7)
38
Автор поста оценил этот комментарий

ну вообщето ассемблер это всеголилишь папа С который научил его всему (почти) что сам умеет, а у ассеблера есть свой папа - машинные коды. у машинных кодов тоже свой папка есть, состояние, а вот стол и всё остальное это уже аппаратное обеспечение.

раскрыть ветку (4)
21
Автор поста оценил этот комментарий

Вот это изречение, моему бы преподавателю архитектуры эвм понравилось.

раскрыть ветку (2)
19
Автор поста оценил этот комментарий
Это и есть твой преподаватель архитектуры ЭВМ
раскрыть ветку (1)
9
Автор поста оценил этот комментарий

И он тоже ассемблер

1
Автор поста оценил этот комментарий
А у состояния - папка электрон и мамка дырка, но не вместе)
5
Автор поста оценил этот комментарий

Ассемблер - это язык будущего

Иллюстрация к комментарию
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

бейсик - язык будущего! во втором терминаторе он был!

11
Автор поста оценил этот комментарий

12
Автор поста оценил этот комментарий
Иллюстрация к комментарию
раскрыть ветку (6)
9
Автор поста оценил этот комментарий

Вот с таким выражением лица и садиться.

раскрыть ветку (5)
14
Автор поста оценил этот комментарий

вот делаешь ник для шуток про ассемблер, а народ даже не догоняет

раскрыть ветку (4)
5
Автор поста оценил этот комментарий

Потому что сложна :-)
Мало кто из тех кто шутит, в живую видел его код. Я им хоть и пользуюсь, но крайне-крайне-крайне редко, программ с пару десятков если написал за всё время. Слишком специфический инструмент и очень злой.

раскрыть ветку (3)
2
Автор поста оценил этот комментарий

если не лезть дальше возможностей ринг3 то вообще мало отличается от си или делфи

раскрыть ветку (2)
16
Автор поста оценил этот комментарий

Если не лезть, смысла в ассемблере - нуль. Да, прога весит не 17 мегабайт, а жмень байт, да исполняется за 170 миллисекунд. Но и всё, а взамен куда больше времени на код. Причём чистого мыслительного процесса много, в какие регистры и в какой момент подавать данные, я даже на бумажке иногда по-шагам записываю и много-много комментирую.

FASM.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

ну обычно написанное на ссеблере по началу медленее выполняется, а выравнивать код руками то ещё удовольствие, фасм на редкость та ещё скотина  когда я последний раз в него заглядывал там половины комманд нужных не было.

самый шик от ассемблера когда всё удаётся распихать по регистрам

помнится гонял 264 кодек через профилировщик 17% времени занимает только ковыряние со стеком, посмотрел можно использовать доп регистры которые комплиятор не осиляет использовать, но руки так и не дошли в итоге

10
DELETED
Автор поста оценил этот комментарий

НУ ВОТ СЛОЖНО БЫЛО МЯГКИЙ ЗНАК НЕ СТАВИТЬ???!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ТАКОЙ КОММЕНТ ИСПОРТИЛ!!!!!!!!!!!!!!!!!!!ААААААААААААААААААААААА,,,,РРРРРРРРРРРРРРРРРРРР,УФФФ

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

Спасибо, я чуть с ума не сошёл: читаю себе дальше спокойно, а ощущение, будто хер 90-летней старушки где-то краем глаза увидел.

Автор поста оценил этот комментарий

Си же может ассемблер инлайном.

раскрыть ветку (2)
Автор поста оценил этот комментарий
Поясните? Вы про модификатор inline или то, что сишные компиляторы хавают асмовские вставки?
раскрыть ветку (1)
Автор поста оценил этот комментарий

вообще компилятор С не обязан уметь в ассемблер это прихоть конкретного разработчика не более.

2
Автор поста оценил этот комментарий
Ассамблер низкоуровневый
раскрыть ветку (2)
1
Автор поста оценил этот комментарий
а Си не низкоуровневый?
раскрыть ветку (1)
2
Автор поста оценил этот комментарий
я извиняюсь, вы наверно в этой теме вообще не бум бум)
10
Автор поста оценил этот комментарий
В голос заорал
Предпросмотр
раскрыть ветку (1)
Автор поста оценил этот комментарий

слышу это "ЫАЭЫЭЫАЫЭАЫЫЭАЫАЭАЫАЭЫАААА"

Автор поста оценил этот комментарий

интересно, как бы выглядел 1С?

Автор поста оценил этот комментарий
C жизенно. Очень.
108
Автор поста оценил этот комментарий
Нахуя
Иллюстрация к комментарию
раскрыть ветку (92)
41
Автор поста оценил этот комментарий

JS это еще и нода. А нода это не только express для сайтов-визиток, но и высоконагруженные TCP сервера взаимодействующие с БД через динамические транзакционные каскады.

раскрыть ветку (91)
45
Автор поста оценил этот комментарий

ебать-колотить

33
Автор поста оценил этот комментарий
Слово "высоконагруженный" стоит очень далеко от node.js и некоторых других некомпилируемых языков
раскрыть ветку (87)
18
Автор поста оценил этот комментарий

JS, внезапно, компилируемый.

И чем JS не язык для хайлоада, и какой инструмент ты используешь для своих хайлоад сервисов?

раскрыть ветку (37)
14
Автор поста оценил этот комментарий

Он был есть и будет интерпретируемым. Именно поэтому он "медленный" в определенном смысле.

Иллюстрация к комментарию
раскрыть ветку (36)
6
DELETED
Автор поста оценил этот комментарий
Node.js делаем пред компиляцию. Это не php.
раскрыть ветку (2)
11
Автор поста оценил этот комментарий
Костылепед какой-то
раскрыть ветку (1)
2
Автор поста оценил этот комментарий

ты хочешь быстро или красиво?)

Быстро - нода, красиво - рельсы, например.

Автор поста оценил этот комментарий

Таки перед исполнением тот же V8 компилирует код в native

раскрыть ветку (7)
3
Автор поста оценил этот комментарий

Любой интерпретатор "компилирует" оператор в натив перед исполнением.


JIT - это круто, однако есть разница: компилировать низкоуровневый оптимизированный байткод (как в JVM или CLR), или текст (с полным циклом разбора, построения AST, оптимизации).

раскрыть ветку (6)
1
Автор поста оценил этот комментарий

JIT - это компиляция в байт код.


Первым JavaScript JIT-компилятором стал TraceMonkey от Mozilla. Это был так называемый трассирующий JIT, так как он отслеживает наиболее повторяемые циклы. Эти “горячие циклы” компилируются в машинный код. Только благодаря одной этой оптимизации Mozilla получили улучшение производительности от 20% до 40% по сравнению с их предыдущим движком.


Вскоре после запуска TraceMonkey Google выпустил Chrome вместе с новым движком V8. V8 был разработан специально для оптимизации скорости. Основным архитектурным решением был отказ от генерации байткода, вместо чего транслятор генерирует напрямую нативный код. В течение года после запуска, команда также применила распределение регистров, улучшила инлайн кэширование, и полностью переписала движок регулярных выражений, сделав его в 10 раз быстрее. Это в совокупности увеличило скорость выполнения JavaScript на 150%.

раскрыть ветку (5)
1
Автор поста оценил этот комментарий
JIT не обязательно компилирует байт-код
Автор поста оценил этот комментарий

JIT - это компиляция в байт код.

Только ситхи все возводят в абсолют. У вас противоречие с текстом ниже:


Основным архитектурным решением был отказ от генерации байткода, вместо чего транслятор генерирует напрямую нативный код.

раскрыть ветку (3)
Автор поста оценил этот комментарий

Собственно, я в теме JS говорил, что он компилирует в байт-код, а потом в натив, или сразу в натив

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

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


Например, движок v8, который в хроме и node.js, вот он компилирует JS перед запуском.

раскрыть ветку (19)
Автор поста оценил этот комментарий

не компилирует, а транслирует. иначе ноду можно было бы собрать как бинарь и исполнять без v8. вот тогда бы jsснички воспрянули бы духом, это ж какой простор для говнокода. у меня лично уже браузер загибается на некоторых сайтах.

раскрыть ветку (18)
Автор поста оценил этот комментарий

Нет, компилирует.


Компиляция исходного кода JavaScript непосредственно в собственный машинный код, минуя стадию промежуточного байт-кода.

раскрыть ветку (17)
Автор поста оценил этот комментарий

тогда почему на невротебенном js не пишут нативные приложения для всех платформ?

раскрыть ветку (16)
Автор поста оценил этот комментарий

Как это связано?

Автор поста оценил этот комментарий

Ну может потому, что у него нет ни одного инструмента для написания и управления нативными приложениями?


Теоретически, вы можете его скомпилировать в EXE, который через document.write будет писать что-то в stdout. Однако, вам прийдется как-то подменить document на что-то свое. Это маразм какой-то.


Хочется писать натив на JS, вы можете взять любой из движков под это заточенных. Но по сути они делают обрезанный браузер с домашней страничкой в виде вашей страницы.

раскрыть ветку (14)
Автор поста оценил этот комментарий
Едрит вы сударь... даёте... JS движок давным давно использует JIT компилятор. И скорости JS по показателям сравнивают с C++.

Это распостраненная ошибка считать JS медленным языком из-за проблем с инициализацией DOM дерева, где JS не принимает никакого участия.

Учитывайте еще и то что даже при таких скоростях движок JS это однопоточная платформа. Основанная на EventLoop в отличии от большинства остальных языков.
раскрыть ветку (4)
Автор поста оценил этот комментарий

И скорости JS по показателям сравнивают с C++.

И какие порядки там получаются?)

раскрыть ветку (3)
Автор поста оценил этот комментарий

Вы про порядок вычисления? Или я вас не понимайт.

раскрыть ветку (2)
Автор поста оценил этот комментарий
Про порядки, на которые JS отстает на тяжелых вычислениях от C++ при сравнении.
раскрыть ветку (1)
Автор поста оценил этот комментарий

Там на самом деле много зависимостей. Железо, платформа, количество процессов уже жрущих вычислительную мощь.

Но +- отставание от С++ у Ноды в среднем 10-30 раз.
Опять же зависит еще и от вычислений, верного анализа по выполнению по времени.

Давай те не забывать еще что можно писать модули .node на С++ для ускорения некоторых частей вычисления.

1
Автор поста оценил этот комментарий
Как программист на node хайлоад проектов я могу обоссать вам лицо.
1. Он быстрый, очень быстрый.
2. Если вы умеете пользоваться async/await promise.all, то это бешеный хайлоад.
3. Если используйте pm2 для кластера и nginx для прокси - охуенная масштабируемость.
раскрыть ветку (3)
2
Автор поста оценил этот комментарий
Как человек, переписавший все bottleneck-и на чистый C, скажу вам, что в node хороша только простота написания неблокирующего кода. Аллокатор, сборщик мусора и ссущая памятью как старое помойное ведро машина (полтора гига в сутки!!!) - худшее, с чем пришлось столкнуться.
Все ваши преимущества, будь то async, nonblock или триллион callback-ов легко реализуется в С, а потом также легко утилизируется.
раскрыть ветку (2)
2
Автор поста оценил этот комментарий
Если вы пишете веб приложения, всякого рода апишки скорость появления mvp на с значительно ниже. 2 - 1.5 гига оперативы в сутки - это ваши кривые руки, ну или кривые либы. Uptime моих приложений уже уже пол года и память не куда не течёт. Такие вещи появляются если вы не засовывайте в try/catch промисы и не отлавливаете ошибки. Такие проблемы у нас тоже были пока я не навешал пиздюлей всему отделу за говнокод. Миллион колбеков это ES5, используйте ES6 стиль с let и будет вам счастье
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Воу-воу, кто человеку минус поставил?


Если у кого-то там течет 1.5 гига в сутки - это прям хз что нужно сделать, чтобы так получилось. И Нода тут не при чем, как и JS в целом.

1
Автор поста оценил этот комментарий

"до миллиона обращений единовременно" разве мало?

раскрыть ветку (44)
5
Автор поста оценил этот комментарий

И это на одном инстансе. Поставить настроенный за 5 минут nginx для балансировки нагрузки и простеньким скриптом подгружать дополнительные инстансы если количество соединений растет, схлопывая если падает. Такой гиперхайлоад на коленке только на ноде возможен))

раскрыть ветку (43)
4
Автор поста оценил этот комментарий

Блин, ты так хорошо и умно стелишь по ноде!))) Не подскажешь парочку хороших статей толковых?

раскрыть ветку (41)
2
Автор поста оценил этот комментарий

Не умеете в ноду? Это прекрасно. Не портите руку, пишите бэкенд на backend-specific языках. Python, Ruby. Хотя вон там выше пишут про "высоконагруженные ТСР.." так для этого еще более нормальный язык есть, в котором 20 лет назад было все то, что сейчас к JS прикручивают лютыми костылями (асинхронность) и нет того, что в принципе не нужно (мутабельность данных, то есть фигушки, а не X = X + 1). Erlang. И добью киллер-фичей - горячая перезагрузка кода, то есть можно обновить исполняющийся модуль без остановки инстанса сервера, "на ходу". И точно так же на ходу укатиться назад, если что-то пошло не так.

раскрыть ветку (32)
1
Автор поста оценил этот комментарий

Ух, за эрланг отдельный плюсик. Что бы эта тварь упала, нужно что бы землетрясение с наводнением одновременно. Эта хрень создает отдельные виртиуальные машины для исполнения кода, а в случае отказа какой то части кода, сама себя поднимает. А еще рекурсии... мммм. Что бы понять рекурсии надо понять рекурсии, рекурсии как основной инструмент это что-то.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

О да, а еще такие вещи как дерево супервизоров/воркеров, функции высшего порядка и gen_server-ы с их обменом сообщениями. Вообще весь OTP. Переменные не нужны! Циклы тоже не нужны! Зато у нас есть пече.. (зачеркнуто) паттерн-матчинг :)

И это я еще про remsh промолчал.

Автор поста оценил этот комментарий

Я вот как раз по времени подошел  к бэк-энду и до сих пор сомневаюсь. Жалею, что изначально не брал python django для фронтенда, а купился на простоту js,
В общем, будем учить python)

раскрыть ветку (8)
Автор поста оценил этот комментарий

Да, питон в этом плане очень хорош. Мощный, простой, мультипарадигмальный - хочешь в ФП-стиле пиши, хочешь в ООП упарывайся по хардкору. Возможностей - ВО! (кот из мультика про Кешу). И нет этого ада с anything.js.


p.s. а когда питона станет мало, можно начинать смотреть на go :)

раскрыть ветку (7)
1
Автор поста оценил этот комментарий

Вот, спасибо тебе за развернутый ответ. Конечно забрасывать ReactJS, а с недавних пор и ReactNative, думаю не нужно. Но если говорить о серьезном проф. развитии, то без постоянного обучения не обойтись.
А что ты скажешь про Java? Пол года на полке пылится книга от Хортсмана и Корнелла, ждем вдохновения!

раскрыть ветку (6)
Автор поста оценил этот комментарий

Python не бэкенд специфик, как и Erlang. Java - да, Go - да, но не питон. Питон довольно узко специализированный, как и Erlang, как и Scala например. Ruby же уже на стадии умирания, как и PHP. Как раз рубисты и переходят на ноду.

раскрыть ветку (6)
Автор поста оценил этот комментарий
Ну питон ладно, но эрланг не бэкендовый? Вы что, смеетесь?
раскрыть ветку (5)
Автор поста оценил этот комментарий

Эрланг тоже очень узкоспециализированный. Если нужно что-то распределенное, отказоустойчивое, высоконагруженноe, как например WhatsApp, который как раз использует эрланг, то да, можно и эрланг. Но у эрланга никакущее комьюнити, мало библиотек и он тупо медленный. Этих минусов достаточно чтобы не считать Erlang мэйнстримовым бэкенд языком

раскрыть ветку (4)
Автор поста оценил этот комментарий

Насчет лютых костылей это вы по осторожней. Иначе я вспомню те же плюсы и количество вариаций на Вашем "Erlang" где также можно выстрелить себе в колено и дебажить это сутками. Python не спорю хороший язык, хороший фреймворк Django.
Ruby c сенатрой тоже неплохо, но он потихоньку иссякает.
Но в отличии от них на ноде даже самый незнающий человек подымет простенькую страничку с любым железом с большим количество подключений в пять вот таких строк.

const http = require('http');
http.createServer(function(req, res){
res.writeHead(200, { 'Content-Type': 'text/plain' });

res.end('<h1>Hello World</h1>');

});

А теперь вспомним сколько всего требуется сделать для запуска того же Django.

*Про руби молчу так как там тоже примерно все в 5-10 строк. Но все же по нагрузке нода выиграет у Рельсов

раскрыть ветку (13)
Автор поста оценил этот комментарий
И на что годна сия простенькая страничка? Ни на что. Но да, с таким простым контентом вы уйму соединений обработаете. Сервер не только отдавать контент должен, как минимум - сходить в бэкенд, что-то там запросить, получить, обработать, динамически сформировать ответ и вот только потом отдать его по HTTP, а это уже совсем другие тесты.
Ну и про выстрелы в ногу на Эрланге, которые сутками (!!!) дебажить надо, расскажите, пожалуйста. Только про два gen_server во взаимном ожидании не надо, это детство совсем.

p.s. HTTP-сервер на Питоне поднимается ОДНОЙ командой.
раскрыть ветку (12)
Автор поста оценил этот комментарий
p.s. HTTP-сервер на Питоне поднимается ОДНОЙ командой.
Я говорю не о командах. А о количестве настроек в коде которые надо произвести чтобы поднялся бэкенд с большим показателем подключений.

Случайно удалил предыдущее сообщение, повторю:

Мы про что сейчас говорим? конкретно про ServerSideRender с пост запросами? Или про ClientSideRender c чистым бэкендом запиленным под WS POST/UPDATE/DELETE.
Ну а вообще грамотная архитектура бэкенда с правильной архитектурой шардинга базы данных, с кластеризацией само по себе повышает производительность в разы.

Про Erlang ничего конкретного не скажу так как в каждом языке хватает своих нюансов которые охватить все сложно. И Банально человеческий фактор.

Выпил бы я с вами чаю с печеньками за таким диалогом при встрече.
раскрыть ветку (11)
Автор поста оценил этот комментарий

с 0 чтоль?

раскрыть ветку (7)
Автор поста оценил этот комментарий

Я не подкалую. Если можешь, посоветую хорошую статью по ноде не англ.

раскрыть ветку (6)
Автор поста оценил этот комментарий

@el.mandarin, и меня позовите плз, я почитаю = )

раскрыть ветку (1)
Автор поста оценил этот комментарий

А ты умеешь поддержать!)))

1
Автор поста оценил этот комментарий

Человек не может загуглить "node js для чайников" и тыкнуть по первой ссылке? Может тогда не надо ноды а?) Да и человек освоивший js такие вопросы не задавал бы.

раскрыть ветку (3)
Автор поста оценил этот комментарий

Млять, ну ты и зануда. Мне понравился тот прием, который ты описал. Я работаю фронт-енд разработчиком используя ReactJS, EmberJS и естественно ноду, как правило, в связке с express. А помощь мне твоя и даром не надо, хотелось поддержать беседу.

раскрыть ветку (2)
Автор поста оценил этот комментарий

Только такой "гиперхайлоад" в ноде возможен*

2
Автор поста оценил этот комментарий

> нода

> высоконагруженные TCP сервера


если бы это прочитал Джо Армстронг, его бы разорвало от хохота на части.

Автор поста оценил этот комментарий

а вот порекомендуйте качественные образцы на Ваш вкус.

17
Автор поста оценил этот комментарий
заебешься гуглить что ты сказал
20
Автор поста оценил этот комментарий

Привет из 2009. Есть Promise который решает данную проблему. И есть async/await который решает её красиво. А тот момент что js асинхронный язык мешает тебе зарукожопить свой UI какой нибудь синхронной функцией.

раскрыть ветку (47)
7
Автор поста оценил этот комментарий

Но зачем изначально было эту проблему создавать, а потом героически решать?

раскрыть ветку (11)
8
Автор поста оценил этот комментарий

А это и не проблема в масштабах web-мира. Представь, ты открываешь сайт, а там белый экран потому что случайная строчка js кода заблокировала контент. Стоит сказать что Promise и async/await тоже не позволят случайно парализовать работу сайта они лишь делают код чище.

раскрыть ветку (10)
Автор поста оценил этот комментарий

В других языках тоже многопоточность есть, но достигается более логичным образом - то есть, если написано:

do_something();

do_something_else();

То эти функции выполнятся последовательно.

А если:

do_something();

Thread myThready = new Thread(new Runnable()

{

  public void run()

    {

      do_something_else();

    }

});

myThready.start();

тогда параллельно

раскрыть ветку (9)
5
Автор поста оценил этот комментарий

Вы сейчас спутали всё в одном флаконе своими изречения.


И то что вы сейчас написали, в начале отработает первая функция, после чего будет запущен поток со второй функцией и не более, и будет подобие последовательного выполнения.

7
Автор поста оценил этот комментарий

В других языках тоже многопоточность есть

В JS нет многопоточности

раскрыть ветку (2)
Автор поста оценил этот комментарий

Есть - WebWorker. Создает отдельный поток. Хоть и урезанный по самые яйца.

раскрыть ветку (1)
Автор поста оценил этот комментарий
Вроде бы он создает даже целый процесс, со всеми вытекающими.
Автор поста оценил этот комментарий

Внезапно, в java тоже есть промисы =/

раскрыть ветку (1)
Автор поста оценил этот комментарий

Промисы даже в ПХП есть без всяких pthreads

1
Автор поста оценил этот комментарий
Жависты сосут хуи
Автор поста оценил этот комментарий
Line 3 компайл ерор. Закрывающая скобка экспектед
раскрыть ветку (1)
Автор поста оценил этот комментарий

Она закрывается на предпоследней строке.

1
Автор поста оценил этот комментарий
асинхронный язык

с каких это пор?


Promise, async/await по сути тот же setTimeout(..., 0), делают тоже самое

1
Автор поста оценил этот комментарий

Согласен. Проблема только для новичков.

А сейчас с асинхронными функциями вообще все изи.

раскрыть ветку (8)
1
Автор поста оценил этот комментарий

в JS нет асинхронности

раскрыть ветку (7)
Автор поста оценил этот комментарий

я знаю, спасибо.

async function() { }

это я имел ввиду под асинхронными функциями, очевидно же

раскрыть ветку (4)
Автор поста оценил этот комментарий

ну это такой же сахар, как и классы

раскрыть ветку (3)
Автор поста оценил этот комментарий

да, так и есть, в чем проблема то?

раскрыть ветку (2)
Автор поста оценил этот комментарий

проблема в том, что асинхронность - это выполнение кода без блокировки основного потока, а такого в JS нету, так как поток единственный

раскрыть ветку (1)
Автор поста оценил этот комментарий

а проблема то где?

Автор поста оценил этот комментарий

Как бы асинхронность есть. Просто выполнение в одном потоке.

раскрыть ветку (1)
Автор поста оценил этот комментарий

по факту просто очередь выполнения задач

Автор поста оценил этот комментарий

Схуяль JS асинхронный стал? ES6 да, асинхронный.

раскрыть ветку (24)
1
Автор поста оценил этот комментарий

Они по сути все синхронные с иллюзией асинхронности. Вот если вы запустите ограниченный WebWorker, то получите настоящую асинхронность.

раскрыть ветку (23)
Автор поста оценил этот комментарий

Асинхронность в JS - это не иллюзия, а фича языка. А то, о чем вы хотите сказать - это многопоточность и многопроцессность.

раскрыть ветку (16)
Автор поста оценил этот комментарий

#comment_103729560

хорошо и полностью ответил человек

раскрыть ветку (11)
Автор поста оценил этот комментарий

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

раскрыть ветку (10)
Автор поста оценил этот комментарий

Вы ОС с браузером не сравнивайте.

И движок с исполняемым окружением тоже. IO у него хоть и асинхронное (кстати, это тоже еще можно развалить, например, на 32 битной системе, где та самая очередность идет с помощью стека, что создает иллюзию асинхронности, а по факту яляется неблокирующей очередью) по факту - это очередь вызовов, которые могут меняться в ней. Асинхронность - это когда события вызываются одновременно, не завися друг от друга, аля очередь не будет ждать пока не закончится предыдущий вызов.

пример этому

while(true){ console.log(1); }

console.log(2);

В асинхронном движке второй метод вызовется сразу же после вызова первого, в системе очередности (как в JS), второй метод не будет вызван никогда, потому что первый еще не закончил работу.


На самом деле, средствами управления V8 (не Web API, который реализует всеми любимый console.log, например) http://www.ecma-international.org/ecma-262/6.0/index.html#se... можно орудовать очередностью при желании, да и сам Web API это умеет делать, но это плохо и неоптимизируемо.

раскрыть ветку (9)
Автор поста оценил этот комментарий
> Асинхронность - это когда события вызываются одновременно


Асинхронность - это возможность одной задачи не блокироваться выполнением другой. Задача - это не один оператор.


А пример кода бестолковый, событий там нет, он заблокируется на любом другом языке, даже поддерживающем потоки.

раскрыть ветку (8)
Автор поста оценил этот комментарий

Не на любом. Создание потоков, рутин и подобного не заблокирует выполнение. Более того, сам V8 создает рутины внутри, но выдает WebAPI только в рамках одного потока результат.

Оператор - это тоже задача.

раскрыть ветку (7)
Автор поста оценил этот комментарий

Создание потоков, рутин и подобного не заблокирует выполнение.

Я не вижу здесь никаких действий в сторону управления выполнением, лишь вывод в консоль.

Оператор - это тоже задача.

Задача - это логически законченное действие. В данном случае задача №1 - бесконечно выводить в консоль единицу, задача №2 - вывести двойку.

раскрыть ветку (6)
Автор поста оценил этот комментарий

в JS всего-то очередь выполнения задач

раскрыть ветку (3)
Автор поста оценил этот комментарий
JS управляется событиями извне. Поэтому порядок задач в очереди не детерминирован.
раскрыть ветку (2)
Автор поста оценил этот комментарий

в каком порядке задачи добавлены, в таком и выполняются

раскрыть ветку (1)
Автор поста оценил этот комментарий

Браузер многопоточный, может добавлять события конкурентно, а, скажем, при асинхронном I/O в операционных системах вообще прерываниями все управляется (ну, или имитируется потоками на уровне libUV (справедливо для V8 в NodeJS)).

Автор поста оценил этот комментарий

Не буду говорить за все, но JS - однопоточный, с возможностью асинхронности. C# - многопоточный, Golang - многопоточный.

раскрыть ветку (5)
1
Автор поста оценил этот комментарий

ES6 - это EcmaScript 6, т.е. описание. И EcmaScript 6 нигде не заикается об асинхронности.

Вы правы - JS однопоточный. Асинхронность достигнута с помощью очереди выполнения.

Не сильно врубаюсь почему меня минусят, но как пример скажу, что setTimeout(()=>{alert(1)},0) не выполнится сиюсекундно, а только после того, как до него доберется очередь (таким образом можно ставить методы в конец очереди исполнения, например, после завершения рендера)

раскрыть ветку (4)
Автор поста оценил этот комментарий

Тут в терминологии путаница, ибо асинхронность и многопоточность значат немного разное.

раскрыть ветку (1)
Автор поста оценил этот комментарий

#comment_103729560

тут хороший ответ

Автор поста оценил этот комментарий

да, вся илюзия асинхронности построена с помощью очереди задач/микрозадач

Автор поста оценил этот комментарий

ECMA-262 если быть точным.

4
Автор поста оценил этот комментарий
о да это изи, промисы хуемисы, ничего сложного
DELETED
Автор поста оценил этот комментарий
Комментарий удален. Причина: данный аккаунт был удалён
Автор поста оценил этот комментарий
Вот не поверю что все 92 лайкнувших твой коммент поняли тебя
ещё комментарии
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку