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

На этом фото мы видим, как группа JS-программистов реализует функцию сложения двух чисел
Вы смотрите срез комментариев. Показать все
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 лайкнувших твой коммент поняли тебя
ещё комментарии
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку