Забавно как на js пытаются навесить именно этот стереотип. Ибо самое страшное кроется в упорядоченно-асинхронных вызовах неблокирующих, но синхронных велосипедов, едущих асинхронно относительно друг-друга, но синхронных относительно вызова последнего асинхронного вызова последнего синхронного велосипеда. Но от этого у helloworld'щиков уже голова лопнет, и мемы будет некому постить.
ехал await через реку
видит await в реке await
сунул await await в await
await await await await
Вот я вполне норм отношусь к синтаксическому сахару в JS. Очень многие вещи вполне даже юзабельны, несмотря что введены для тех, кто не смог в прототипы... Хотя let и const тоже хорошие штуки, хоть и const сделано через жопку. Но этот await реально не пришей к пизде рукав. Для тех кто не осилил простейшие промисы.
Блин,промис, это тупо функция конструктор (вспомните про new), которая хранит в себе список then кэлбэков, список catch кэлбэков и все... Нет блять надо придумать такуюконстркцию, которая просто нахер не нужна...
async await как раз избавляет от callback hell'a. Пока у тебя маленькие функции с несколькими then'ами, все ништяк, но когда их 20-30, код превращается в нечитабельную хрень. Тут либо писать свой конечный автомат, либо использовать сахар из await'ов. У меня лично на ноде есть участки кода, где мне нужно дохрена разных запросов дожидаться, потом еще все это заворачивать в Promise.all() и собирать аггрегат из всех этих данных. Даже не представляю как бы это выглядело с then'ами
В какой-то момент на одном проекте я написал свой Promise для избавления от проблем.
И да, я видел много вложенных промисов, где это выглядело нормально (просто код разбит по методам и это выглядит вполне хорошо).
async await просто априори это заставляет делать (что не мешает в нем же наговнякать).
Он стол, стул, комната, игрок, карты. Ассемблер это всё вокруг, он божество этого огромного мира. Если дать ему закодится и скомпилироваться в телесную форму, у его противников нет ни единого шанса. Он не может проиграть, он - игра.
ну вообщето ассемблер это всеголилишь папа С который научил его всему (почти) что сам умеет, а у ассеблера есть свой папа - машинные коды. у машинных кодов тоже свой папка есть, состояние, а вот стол и всё остальное это уже аппаратное обеспечение.
Потому что сложна :-)
Мало кто из тех кто шутит, в живую видел его код. Я им хоть и пользуюсь, но крайне-крайне-крайне редко, программ с пару десятков если написал за всё время. Слишком специфический инструмент и очень злой.
Если не лезть, смысла в ассемблере - нуль. Да, прога весит не 17 мегабайт, а жмень байт, да исполняется за 170 миллисекунд. Но и всё, а взамен куда больше времени на код. Причём чистого мыслительного процесса много, в какие регистры и в какой момент подавать данные, я даже на бумажке иногда по-шагам записываю и много-много комментирую.
FASM.
ну обычно написанное на ссеблере по началу медленее выполняется, а выравнивать код руками то ещё удовольствие, фасм на редкость та ещё скотина когда я последний раз в него заглядывал там половины комманд нужных не было.
самый шик от ассемблера когда всё удаётся распихать по регистрам
помнится гонял 264 кодек через профилировщик 17% времени занимает только ковыряние со стеком, посмотрел можно использовать доп регистры которые комплиятор не осиляет использовать, но руки так и не дошли в итоге
НУ ВОТ СЛОЖНО БЫЛО МЯГКИЙ ЗНАК НЕ СТАВИТЬ???!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ТАКОЙ КОММЕНТ ИСПОРТИЛ!!!!!!!!!!!!!!!!!!!ААААААААААААААААААААААА,,,,РРРРРРРРРРРРРРРРРРРР,УФФФ
Спасибо, я чуть с ума не сошёл: читаю себе дальше спокойно, а ощущение, будто хер 90-летней старушки где-то краем глаза увидел.
вообще компилятор С не обязан уметь в ассемблер это прихоть конкретного разработчика не более.
JS это еще и нода. А нода это не только express для сайтов-визиток, но и высоконагруженные TCP сервера взаимодействующие с БД через динамические транзакционные каскады.
JS, внезапно, компилируемый.
И чем JS не язык для хайлоада, и какой инструмент ты используешь для своих хайлоад сервисов?
Он был есть и будет интерпретируемым. Именно поэтому он "медленный" в определенном смысле.
Любой интерпретатор "компилирует" оператор в натив перед исполнением.
JIT - это круто, однако есть разница: компилировать низкоуровневый оптимизированный байткод (как в JVM или CLR), или текст (с полным циклом разбора, построения AST, оптимизации).
JIT - это компиляция в байт код.
Первым JavaScript JIT-компилятором стал TraceMonkey от Mozilla. Это был так называемый трассирующий JIT, так как он отслеживает наиболее повторяемые циклы. Эти “горячие циклы” компилируются в машинный код. Только благодаря одной этой оптимизации Mozilla получили улучшение производительности от 20% до 40% по сравнению с их предыдущим движком.
Вскоре после запуска TraceMonkey Google выпустил Chrome вместе с новым движком V8. V8 был разработан специально для оптимизации скорости. Основным архитектурным решением был отказ от генерации байткода, вместо чего транслятор генерирует напрямую нативный код. В течение года после запуска, команда также применила распределение регистров, улучшила инлайн кэширование, и полностью переписала движок регулярных выражений, сделав его в 10 раз быстрее. Это в совокупности увеличило скорость выполнения JavaScript на 150%.
JIT - это компиляция в байт код.
Только ситхи все возводят в абсолют. У вас противоречие с текстом ниже:
Основным архитектурным решением был отказ от генерации байткода, вместо чего транслятор генерирует напрямую нативный код.
Собственно, я в теме JS говорил, что он компилирует в байт-код, а потом в натив, или сразу в натив
Язык не бывает компилируемым или интерпретируемым, потому что для любого языка можно написать как компилятор, так и интерпретатор.
Например, движок v8, который в хроме и node.js, вот он компилирует JS перед запуском.
не компилирует, а транслирует. иначе ноду можно было бы собрать как бинарь и исполнять без v8. вот тогда бы jsснички воспрянули бы духом, это ж какой простор для говнокода. у меня лично уже браузер загибается на некоторых сайтах.
Нет, компилирует.
Компиляция исходного кода JavaScript непосредственно в собственный машинный код, минуя стадию промежуточного байт-кода.
Ну может потому, что у него нет ни одного инструмента для написания и управления нативными приложениями?
Теоретически, вы можете его скомпилировать в EXE, который через document.write будет писать что-то в stdout. Однако, вам прийдется как-то подменить document на что-то свое. Это маразм какой-то.
Хочется писать натив на JS, вы можете взять любой из движков под это заточенных. Но по сути они делают обрезанный браузер с домашней страничкой в виде вашей страницы.
Это распостраненная ошибка считать JS медленным языком из-за проблем с инициализацией DOM дерева, где JS не принимает никакого участия.
Учитывайте еще и то что даже при таких скоростях движок JS это однопоточная платформа. Основанная на EventLoop в отличии от большинства остальных языков.
Там на самом деле много зависимостей. Железо, платформа, количество процессов уже жрущих вычислительную мощь.
Но +- отставание от С++ у Ноды в среднем 10-30 раз.
Опять же зависит еще и от вычислений, верного анализа по выполнению по времени.
Давай те не забывать еще что можно писать модули .node на С++ для ускорения некоторых частей вычисления.
1. Он быстрый, очень быстрый.
2. Если вы умеете пользоваться async/await promise.all, то это бешеный хайлоад.
3. Если используйте pm2 для кластера и nginx для прокси - охуенная масштабируемость.
Все ваши преимущества, будь то async, nonblock или триллион callback-ов легко реализуется в С, а потом также легко утилизируется.
Воу-воу, кто человеку минус поставил?
Если у кого-то там течет 1.5 гига в сутки - это прям хз что нужно сделать, чтобы так получилось. И Нода тут не при чем, как и JS в целом.
И это на одном инстансе. Поставить настроенный за 5 минут nginx для балансировки нагрузки и простеньким скриптом подгружать дополнительные инстансы если количество соединений растет, схлопывая если падает. Такой гиперхайлоад на коленке только на ноде возможен))
Блин, ты так хорошо и умно стелишь по ноде!))) Не подскажешь парочку хороших статей толковых?
Не умеете в ноду? Это прекрасно. Не портите руку, пишите бэкенд на backend-specific языках. Python, Ruby. Хотя вон там выше пишут про "высоконагруженные ТСР.." так для этого еще более нормальный язык есть, в котором 20 лет назад было все то, что сейчас к JS прикручивают лютыми костылями (асинхронность) и нет того, что в принципе не нужно (мутабельность данных, то есть фигушки, а не X = X + 1). Erlang. И добью киллер-фичей - горячая перезагрузка кода, то есть можно обновить исполняющийся модуль без остановки инстанса сервера, "на ходу". И точно так же на ходу укатиться назад, если что-то пошло не так.
Ух, за эрланг отдельный плюсик. Что бы эта тварь упала, нужно что бы землетрясение с наводнением одновременно. Эта хрень создает отдельные виртиуальные машины для исполнения кода, а в случае отказа какой то части кода, сама себя поднимает. А еще рекурсии... мммм. Что бы понять рекурсии надо понять рекурсии, рекурсии как основной инструмент это что-то.
О да, а еще такие вещи как дерево супервизоров/воркеров, функции высшего порядка и gen_server-ы с их обменом сообщениями. Вообще весь OTP. Переменные не нужны! Циклы тоже не нужны! Зато у нас есть пече.. (зачеркнуто) паттерн-матчинг :)
И это я еще про remsh промолчал.
Я вот как раз по времени подошел к бэк-энду и до сих пор сомневаюсь. Жалею, что изначально не брал python django для фронтенда, а купился на простоту js,
В общем, будем учить python)
Да, питон в этом плане очень хорош. Мощный, простой, мультипарадигмальный - хочешь в ФП-стиле пиши, хочешь в ООП упарывайся по хардкору. Возможностей - ВО! (кот из мультика про Кешу). И нет этого ада с anything.js.
p.s. а когда питона станет мало, можно начинать смотреть на go :)
Вот, спасибо тебе за развернутый ответ. Конечно забрасывать ReactJS, а с недавних пор и ReactNative, думаю не нужно. Но если говорить о серьезном проф. развитии, то без постоянного обучения не обойтись.
А что ты скажешь про Java? Пол года на полке пылится книга от Хортсмана и Корнелла, ждем вдохновения!
Python не бэкенд специфик, как и Erlang. Java - да, Go - да, но не питон. Питон довольно узко специализированный, как и Erlang, как и Scala например. Ruby же уже на стадии умирания, как и PHP. Как раз рубисты и переходят на ноду.
Эрланг тоже очень узкоспециализированный. Если нужно что-то распределенное, отказоустойчивое, высоконагруженноe, как например WhatsApp, который как раз использует эрланг, то да, можно и эрланг. Но у эрланга никакущее комьюнити, мало библиотек и он тупо медленный. Этих минусов достаточно чтобы не считать Erlang мэйнстримовым бэкенд языком
Насчет лютых костылей это вы по осторожней. Иначе я вспомню те же плюсы и количество вариаций на Вашем "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 строк. Но все же по нагрузке нода выиграет у Рельсов
Ну и про выстрелы в ногу на Эрланге, которые сутками (!!!) дебажить надо, расскажите, пожалуйста. Только про два gen_server во взаимном ожидании не надо, это детство совсем.
p.s. HTTP-сервер на Питоне поднимается ОДНОЙ командой.
p.s. HTTP-сервер на Питоне поднимается ОДНОЙ командой.Я говорю не о командах. А о количестве настроек в коде которые надо произвести чтобы поднялся бэкенд с большим показателем подключений.
Случайно удалил предыдущее сообщение, повторю:
Мы про что сейчас говорим? конкретно про ServerSideRender с пост запросами? Или про ClientSideRender c чистым бэкендом запиленным под WS POST/UPDATE/DELETE.
Ну а вообще грамотная архитектура бэкенда с правильной архитектурой шардинга базы данных, с кластеризацией само по себе повышает производительность в разы.
Про Erlang ничего конкретного не скажу так как в каждом языке хватает своих нюансов которые охватить все сложно. И Банально человеческий фактор.
Выпил бы я с вами чаю с печеньками за таким диалогом при встрече.
Человек не может загуглить "node js для чайников" и тыкнуть по первой ссылке? Может тогда не надо ноды а?) Да и человек освоивший js такие вопросы не задавал бы.
Млять, ну ты и зануда. Мне понравился тот прием, который ты описал. Я работаю фронт-енд разработчиком используя ReactJS, EmberJS и естественно ноду, как правило, в связке с express. А помощь мне твоя и даром не надо, хотелось поддержать беседу.
> нода
> высоконагруженные TCP сервера
если бы это прочитал Джо Армстронг, его бы разорвало от хохота на части.
Привет из 2009. Есть Promise который решает данную проблему. И есть async/await который решает её красиво. А тот момент что js асинхронный язык мешает тебе зарукожопить свой UI какой нибудь синхронной функцией.
А это и не проблема в масштабах web-мира. Представь, ты открываешь сайт, а там белый экран потому что случайная строчка js кода заблокировала контент. Стоит сказать что Promise и async/await тоже не позволят случайно парализовать работу сайта они лишь делают код чище.
В других языках тоже многопоточность есть, но достигается более логичным образом - то есть, если написано:
do_something();
do_something_else();
То эти функции выполнятся последовательно.
А если:
do_something();
Thread myThready = new Thread(new Runnable()
{
public void run()
{
do_something_else();
}
});
myThready.start();
тогда параллельно
Вы сейчас спутали всё в одном флаконе своими изречения.
И то что вы сейчас написали, в начале отработает первая функция, после чего будет запущен поток со второй функцией и не более, и будет подобие последовательного выполнения.
асинхронный язык
с каких это пор?
Promise, async/await по сути тот же setTimeout(..., 0), делают тоже самое
я знаю, спасибо.
async function() { }
это я имел ввиду под асинхронными функциями, очевидно же
проблема в том, что асинхронность - это выполнение кода без блокировки основного потока, а такого в JS нету, так как поток единственный
Они по сути все синхронные с иллюзией асинхронности. Вот если вы запустите ограниченный WebWorker, то получите настоящую асинхронность.
Асинхронность в JS - это не иллюзия, а фича языка. А то, о чем вы хотите сказать - это многопоточность и многопроцессность.
Человек придумал определение, описывающее свое заблуждение. В параллельном тредике я уже писал почему это так.
Вы ОС с браузером не сравнивайте.
И движок с исполняемым окружением тоже. 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 это умеет делать, но это плохо и неоптимизируемо.
Асинхронность - это возможность одной задачи не блокироваться выполнением другой. Задача - это не один оператор.
А пример кода бестолковый, событий там нет, он заблокируется на любом другом языке, даже поддерживающем потоки.
Не на любом. Создание потоков, рутин и подобного не заблокирует выполнение. Более того, сам V8 создает рутины внутри, но выдает WebAPI только в рамках одного потока результат.
Оператор - это тоже задача.
Создание потоков, рутин и подобного не заблокирует выполнение.
Я не вижу здесь никаких действий в сторону управления выполнением, лишь вывод в консоль.
Оператор - это тоже задача.
Задача - это логически законченное действие. В данном случае задача №1 - бесконечно выводить в консоль единицу, задача №2 - вывести двойку.
Браузер многопоточный, может добавлять события конкурентно, а, скажем, при асинхронном I/O в операционных системах вообще прерываниями все управляется (ну, или имитируется потоками на уровне libUV (справедливо для V8 в NodeJS)).
Не буду говорить за все, но JS - однопоточный, с возможностью асинхронности. C# - многопоточный, Golang - многопоточный.
ES6 - это EcmaScript 6, т.е. описание. И EcmaScript 6 нигде не заикается об асинхронности.
Вы правы - JS однопоточный. Асинхронность достигнута с помощью очереди выполнения.
Не сильно врубаюсь почему меня минусят, но как пример скажу, что setTimeout(()=>{alert(1)},0) не выполнится сиюсекундно, а только после того, как до него доберется очередь (таким образом можно ставить методы в конец очереди исполнения, например, после завершения рендера)
во время выполнения задачи как раз таки блокируется основной поток, так как один один
никогда не видел фризов на сайтах?
да при чем тут говнокод, если все выполняется в одном потоке
и если не успеет операция выполниться до перерисовки браузером - будут фризы, для 60 фпс задача не должна выполняться дольше 16 мс, что далеко не всегда получается
промисы и колбеки просто откладывают выполнение задачи
вот к примеру какая-то фильтрация, маппинг большого массива будет блокировать отрисовку браузера
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
Web Workers is a simple means for web content to run scripts in background threads
Чем они больше похожи на процессы?
В worker-е нельзя использовать DOM, вместо window глобальный объект называется self. Нельзя получить доступ к localStorage и рисовать на canvas.
Из worker-ов нельзя вернуть объект. В javascript нет lock-ов и других возможностей потокобезопасности, поэтому из worker-ов нельзя передавать объекты по ссылке, всё отправленное в worker или из него будет скопировано.
Пока что worker-ы не поддерживают CORS, создать worker можно только загрузив его со своего домена.
Для worker-ов выделяется меньший размер стека.
Так что это ну ни как не тянет на нормальные треды
Воркеры - это больше костыль, чем треды, да. Но на процессы они так же не тянут.
P.S. Менять UI из левых тредов не нужно ни в каком языке программирования.
Ну я исходил из мысли, что так как нет общей памяти, то это больше на процессы похоже, чем треды.