Это руководство предназначено для программистов, которые хотят изучить основы Node. Этот учебник даст вам достаточно понимания всех необходимых компонентов Node. Прежде чем приступить к этой обучающей программе, вы должны иметь базовое понимание JavaScript. Как мы будем разрабатывать веб-приложения с использованием Node. Для большинства из примеров , приведенных в данном руководстве, вы найдете попробовать его вариант, так что просто сделать использование этой опции , чтобы выполнить свои программы Node. Попробуйте следующий пример , используя опцию попробовать его доступны в верхнем правом углу ниже образца кода коробки на нашем сайте: CSS Учить Colors Учить Bootstrap JavaScript Учить JavaScript Учить jQuery Учить JqueryUI Учить jQuery Mobile Учить AppML Учить AngularJS Учить Angular Material Учить Ext. Интернет-маркетинг Учить SEO Учить Маркетинг в области СМИ Учить Pay Per Click Учить веб-аналитика Учить Онлайн маркетинг Учить Мобильный маркетинг Учить Рекламная рассылка Учить Содержание маркетинга Учить Twitter Маркетинг Учить Pinterest маркетинг HTML Графика Учить Canvas Учить SVG Учить Icons Учить Google Maps Учить HTML Games Telecom Учебники Учить 5G Учить CDMA Учить GPRS Учить GSM Учить i-Mode Учить LTE Учить NGN Учить SIP Учить Telecom Billing Учить UMTS Учить WAP Учить Wi-Fi Учить WiMAX Учить WML Разработка мобильных Учить Android Учить Cordova Учить iOS Учить Ionic Учить Meteor Учить PhoneGap Учить SL4A Mainframe разработка Учить CICS Учить IMS DB Учить VSAM. NET Учить Ruby Учить Perl Учить Laravel Учить Python Учить Python 3 Учить wxPython Учить UNIX Учить Swift Учить Node. JAVA технологии Учить Java Учить Java 8 Учить JSP Учить JDB Учить JDBC Учить Java XML Учить Spring Учить Struts 2 Учить Hibernate Учить Maven Учить Lucene Учить Servlets Учить SWING Учить jMeter Учить Jackson Учить JUnit Учить JavaMail API Учить EJB Учить Guava Учить iBATIS Учить jBPM5 Учить JFreeChart Учить JOGL Учить JPA Учить log4j Учить XStream Учить EasyMock Учить Eclipse Учить Design Patterns Microsoft Учить ASP. NET MVC Учить ASP. NET WP Учить Batch Script Учить Entity Framework Учить NHibernate Учить LINQ Учить MFC Учить Microsoft Azure Учить MS Project Учить MicroStrategy Учить MS SQL Server Учить MVVM Учить Silverlight Учить VB. Net Учить WCF Учить WPF Учить XAML Учить Windows 10 разработка Учить Windows 10 Учить Word Учить Excel Учить Excel Charts Учить Advanced Excel Учить Powerpoint Программное обеспечение качества Учить Concordion Учить Непрерывная интеграция Учить Cucumber Учить Jenkins Учить Тестирование базы данных Учить CMMI Учить ETL Testing Учить Mockito Учить Мобильное тестирование Учить Тестирование на проникновение Учить Сетевая безопасность Учить QC Учить QUnit Учить QTP Учить RSpec Учить SAP Testing Учить Тестирование безопасности Учить Selenium Учить Six Sigma Учить Тестирование программного обеспечения Словарь Учить Тестирование программного обеспечения Учить Безопасность беспроводной сети Учить Компьютерная безопасность Учить интернет-безопасность. CSS CSS Справка CSS Selector Справка W3. CSS Справка Bootstrap Справка. JavaScript JavaScript Справка HTML DOM Справка jQuery Справка jQuery Mobile Справка AngularJS Справка Google Maps Справка. XML XML Справка XSLT Справка XML Schema Справка SVG Справка. Charsets HTML Наборы символов HTML ASCII HTML ANSI HTML Windows HTML ISO HTML Symbols HTML UTF JavaScript JavaScript Примеры HTML DOM Примеры jQuery Примеры jQuery Mobile Примеры AngularJS Примеры AJAX Примеры. XML XML Примеры XSL Примеры XSLT Примеры XPath Примеры XML Schema Примеры SVG Примеры.
Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Если и есть что-то, что веб-разработчики любят, так это знать что-то, что лучше традиционного. Но традиционное является таковым по одной причине: Что-то давно беспокоило меня во всей этой шумихе вокруг Node. Я бы забыл его, как любое очередное нытьё какого-то осла о том, что Unix слишком сложен. Но, как полицейскому, который, жопой чуя, что что-то не так с этой семьёй в микроавтобусе, останавливает его и находит пятьдесят килограммов героина, мне показалось, что что-то не так с этой слезливой историей, и возможно, просто возможно, он понятия не имеет, что делает, и много лет программирует, никем не контролируемый. Поскольку вы читаете это, вы, возможно, уже поняли, что моя догадка подтвердилась. Принял ли ты epoll в своё сердце? Крах масштабируемости ждёт своего часа Давайте начнём с самой ужасной лжи: Теперь в вашей зубной пасте! В Node практически нет функций, напрямую выполняющих операции ввода-вывода, так что процесс никогда не блокируется. Из-за того, что ничего не блокируется, менее-чем-эксперты могут разрабатывать быстрые системы. Это утверждение заманчиво, ободряюще и полностью, блядь, неверно. Давайте начнём с определения, ведь ваша, хабровские всезнайки, специфика — педантизм. Вызов функции называется блокирующим, когда выполнение вызывающего потока будет приостановлено до завершения этой функции. Вот вам забавный факт: Эта функция, вычисляющая N-ное число Фибоначчи, заблокирует текущий поток, потому что она использует процессор: А ты разве не должен сейчас репетировать перед зеркалом то, что скажешь, когда всё-таки решишься подойти к Ней? Посмотрим, что происходит с программой для Node. Итак, мы все знаем, что JavaScript не офигенно быстрый язык, но что в этом страшного? А то, событийная модель Node и ёбнутые на всю голову фанатики заставили вас думать, что всё хорошо. Вот простенький псевдокод, показывающий, как работает event loop: Итак, учитывая вышесказанное, давайте посмотрим, как мой маленький node-сервер ведёт себя при самой скромной нагрузке — 10 запросов, 5 одновременных: Конечно, Node позволяет рожать дочерние процессы, но сейчас потоковая и событийная модель настолько сильно связаны, что вы уже получили гораздо большие проблемы, чем масштабируемость. Отрицая философию Unix, Node наказывает разработчика Давным-давно стоявшие у истоков бородатые парни решили, что собирать в цепочку маленькие программы, каждая из которых выполняет специфическую задачу — отличная идея, а универсальным интерфейсом для них должен стать текст. Если вы разрабатываете на платформе Unix, придерживаясь этого принципа, операционная система отблагодарит вас простотой и процветанием. К примеру, когда веб-приложения только появились, веб-приложение было просто программой, отдающей текст в стандартный вывод. Веб-сервер отвечал за принятие входящих запросов, выполнение этой программы и возврат результата клиенту. Мы назвали это CGI, и это был хороший способ выполнять работу, пока микро-оптимизаторы не сунули в него свои грязные пальцы. Концептуально, любая архитектура веб-приложения, не являющаяся раком мозга, работает именно так и сейчас: Это может быть отдача статического файла, вызов CGI-скрипта, проксирование соединения куда-либо ещё, что угодно. Дело в том, что HTTP-сервер не должен выполнять работу приложения. Разработчики обычно называют это разделением ответственности , и оно существует по одной причине: И всё же, кажется, Node не обращает на это внимания. У Node есть и не смейтесь, я не придумываю свой собственный HTTP-сервер, и его вы должны использовать, чтобы обслуживать входящий трафик. Да, в примере выше, где я вызвал http. Если вы используете Node, есть процентный шанс, что вы и разработчик, и сисадмин, потому что любой системный администратор первым делом отговорил бы вас от использования Node. Таким образом, вы, разработчик, будете наказаны этой оргией с HTTP-проксированием, если захотите поставить настоящий веб-сервер перед Node для штук типа отдачи статического контента, перезаписи запросов, ограничения скорости, балансировки нагрузки, SSL или любых других футуристичных вещей, которые умеют делать современные HTTP-серверы. Да, в вашей системе будет ещё один уровень, требующий мониторинга. Хотя, будем честны сами с собой, если вы Node-разработчик, вы, вероятно, запускаете приложение прямо из Node, запущенной в вашей экранной сессии под вашей учётной записью. Это блядский JavaScript Возможно, худшее, что можно сделать с серверным фреймворком, — написать его на JavaScript. Мне тоже обидно и больно за любимый язык. Однако, если отвлечься от боли, в вышеизложенном тексте можно найти смысл, аргументы и доказательства. Я бы очень хотел внятной дискуссии, ибо переводил я его только ради этого. По неизвестно кем установленной традиции, сообщу, что это мой первый перевод и всё такое. Информационная безопасность 2,4k авторов , 6,4k публикаций. Open source 1k авторов , 2,3k публикаций. Высокая производительность авторов , 1,2k публикаций. Программирование 2,9k авторов , 6,5k публикаций. Разработка систем передачи данных 62 автора , публикаций. Анализ и проектирование систем авторов , публикации. Алгоритмы 1,3k авторов , 2,3k публикаций. Big Data авторов , публикаций. Тестирование IT-систем авторов , 1,1k публикаций. Тестирование веб-сервисов авторов , публикаций. Добавить в закладки Александр Кавун takkmoil карма. Вы просто ничего не понимаете в Node. Ааа, вы не знаете про Теда. Ну тогда поперевожу ещё. Кстати, у вас контраргументы есть? Хочу еще… Не ждать терпения не хватит пойду читать что за чувак такой. Приятно что есть и люди которые не ведутся на хайп вокруг асинхронных фреймворков. А чем так плохи асинхронные фреймворки? Но синхронные, типа PHP, тут явно не в выигрышной ситуации. И кстати асинхронные фреймворки не вчера появились. Это только вокруг Ноды крику много. И что странно он частенько подогревается Microsoft-ом. Любопытно в чем тут у них интерес? Сами по себе ничем. Я например активно экспериментирую с tornado и gevent Twisted для мутантов и результатами доволен, хотя подводные камни тоже встречаются. Плоха шумиха вокруг них развернутая — волшебная палочка которая сделает всем вам хорошо и бесплатно. Собственно статья про то и написана, ну и ощущения от северного js у меня схожие с автором. Как показывает практика моя и не только — без шума не взлетит. Это лет 10 тому назад можно было написать полезную программу и стать известным за пол года. Сейчас интенсивность фонового шума в интернете такова, что напиши ты хоть серебрянную пулю, если хотя бы ты сам не приложишь все усилия чтобы поднять вокруг своего решения максимально шума — о нем никто и никогда не узнает. В этом кстати история практически всех успешных решений и новинок последних лет. Они небыли лучшими, и, часто даже небыли первыми. Они просто были самыми шумными. Жаль что так происходит, но такова жизнь…. Да бросте Вы, совершенно очевидно, чего автор не понял. Об этом говорит пример с фиббоначи, как бы вы не старались, как бы не параллелили, если у вас одно ядро — Вы можете хоть миллион тредов наплодить, но быстрее всего задача будет решена последовательным выполнением, как в ноде, треды принесут лишь оверхэд, а если ядер несколько — нужно поднимать несколько инстансов ноды. Под неблокирующей архитектурой понимается лишь неблокирование ввода вывода, про CPU никто не говорит. Это будет только в том случае, если на каждого клиента будет по потоку и операционная система будет их вытеснять. В случае асинхронной обработки клиенты с фибоначи всех забьют и все порастет. И я про тоже. Каждый запрос к node должен быть максимально быстрым, чтобы не занимать цикл надолго: Приведенная реализация фибоначи на архитектуру node ложится очень плохо. Возможно, но есть асинхронные PHP фреймворки, которые очень порадовали производительностью. Второй как раз давно хочу перевести, всё руки не доходили. А этот пост совсем за живое задел, потому и. Вся аргументация строится вокруг того, что реальный бизнес сейчас не строится на NoSQL. После просмотра блога Теда, я больше не воспринимаю его серьезно, как и его статьи. Вне зависимости от того, есть ли там рациональное зерно или нету. Но таких в вебе вообще то мало очень. В большинстве случаев мы ждем либо диск, либо ответ от базы данных, либо ответ от другого сервера… Так что фибоначи можно считать в отдельном потоке и выводить всем готовый закэшированный результат. Что намного сложнее сделать в случае CGI — там придется для каждого пользователя считать его отдельно. Или записывать на диск… или в базу… или ещё как. Про философию UNIX — херня. Нельзя жить вечно с философией прошлого тысячелетия. Это же IT Создавать HTTP сервер на ходу — очень удобно. Зато PHP — идеальный пример философии юникс? При этом никакого порядка ни в названиях, ни в порядке переменных, ни в возвращаемых результатах. Ну а про блядский Javascrpt — кто вас и автора заставляет писать так? Философию вы зря обижаете. Кирпичные дома прочнее и теплее панельных, и соседей не так слышно. А то, что технология древняя… работает же! К PHP вы тоже совершенно зря прицепились, хотя он действительно вполне себе unix way, хотя бы в части работы в качестве CGI. А названия функций… издержки быстрого роста и тяжкое наследие. Зато кирпичные строятся дольше и стоят вроде. PHP просто для примера. Философия может и хорошая, но автор почему решил что раз философия хорошая — то иначе и быть — иначе полная херня. Автор притянул за уши все аргументы какие смог. Мог подробно бы обсудить каждый и про бэкенд, фронтэнд сервера и про скорость вычисления Фибоначи в других языках и про запуск из консоли, но во первых мне сообщения можно писать раз в час, во вторых не гуру серверного javascript , а в третьих не вижу смысла. Мир IT он такой. Все очень любят доказывать что то кому то. Что технология неправильная, что нужно делать так… и т. Вот человек решил что node хрень — его право. Непонятно почему он пытается других убедить. Ноду поизвращавшись можно заставить работать как CGI — вот только зачем…. Вы правы и неправы одновременно. Как ваша ссылка доказывает ваше утверждение? Там про нишевой продукт, а не про асинхронную general purpose серебряную пулю. Да, ссылку не ту вставил, сорри. Node построен аналогично nginx, который также использует event-based модель. Путь Unix подразумевает два варианта — отработку запросов по процессам, или в одном процессе. Использование потоков не поощряется по сравнению с Windows way. Нет, если рассматривать ноуд. Внутреннеархитектурно — да, на троечку с плюсом. И вставляют в кладку систем, а системы от этого пухнут и дохнут. Просто потому, что у кирпичиков есть свойство транзитивности, а у имитаторов — нет. Как правило, прикладные нишевые продукты и являются такими имитаторами. Вроде в юниксе, вроде опенсорс, вроде открытое решение — но при этом узкое, конечное и используемое только в качестве фасада, на котором можно нарастить немного плюща бизнес-логики. С тем отличием друг от друга, что первый — строительный кирпичик-прокси с включаемой функцией имитатора вебсервера, а второй — просто имитатор вебсервера с функцией убийцы эрланга или с натяжкой руби. Я не люблю хейтерство во всех проявлениях хотя сам на публику, например, иногда этим страдаю , но в данном случае склонен думать, что как нишевое решение ноуд найдёт место под солнцем, как и армию апологетов, в глазах которых классические подходы проектирования программного обеспечения себя дискредитировали в силу столкновения недостаточно опытного человека с реалиями мира. Но признавать ноуд продуктом юникс-пути — увольте, не получается. Он же призван встроиться в цепочку от консольной программы до пользователя сети как pipe, только на уровне сети. Вы помните почему inetd перестал пользоваться спросом? Он вел себя точно так же как apache — плодил процессы и подгружал программы полными экземплярами. Этот подход оправдывал себя не долго и от него отказались в пользу постоянно висящих в памяти демонов. Разумеется вам никто не мешает поднять старичка из могилы для того, чтобы писать сетевые сервера на shell, но современным требованиям к коммерческим системам это уже не соответствует. То же происходит и с веб-серверами: Выживет он или не пройдет естественный отбор, покажет время, но эволюционный шаг unix, начавшийся с отказа от inetd в любом случае будет сделан. И пока не ясны все особенности приходящей парадигмы, сложно прогнозировать результаты этого эксперимента. А автор, в силу юношеской категоричности, ищет грань между черным и белым в сером мире, цепляясь за свое прошлое и навязывая его восприимчивому читателю. Я ещё раз напишу. Тред начался с того, что ноуд назвали продуктом юникс-пути. Я как можно проще изложил, почему я не считаю это корректным. С вами целиком согласен. Смысл эволюции в многообразии форм и все эти формы имеют право на существование. Может мы с вами по-разному понимаем одни и те же выражения, но архитектура event-driven приложений это на мой взгляд именно продукт пути, который проходит unix. С другой стороны unix-way, как понятие, означает не эволюцию, а идеологию и в этом контексте node. Я специально отбил параграфы в своём предыдущем респонзе для разделения мыслей. Да, event-driven и message-driven живут и у них есть будущее. Я отвечал на первый: С буквой всё понятно, но даже духа не признаете? Дух свободы и нигилизма? Понятие этого духа у каждого своё и оно похоже на понятие демократии. Если чесно, я вообще не понял за что вас так жестоко заминуосвали. Человек который один из немногих кто пишет статьи по программированию на хабр не достоин иметь такой низкой кармы. Вы не вполне правы. Отдельный поток тут выгоден не всегда. Более кошерно каждую следующую итерацию уводить в nextTick. Подозреваю что при этом оно будет работать еше меленнее — слишком высокие накладные расходы. Да не, нормально будет работать — даже статья на хабре про этот метод была habrahabr. Программист берет на себя задачи планировщика. Как показывает практика, 40 лет он летал, этот unix way и будет летать дальше. Быстро, эффективно и масштабируемо. Запомните — разработчики являются ресурсом, а не самоцелью. Синтаксический сахар и лень рождают чудовищ. НЛО прилетело и опубликовало эту надпись здесь. Наращиваемо как по горизонтали, так и в архитектурном плане, вверх. Воспринимайте Node как великолепный агрегатор. Как использовать ноуд в качестве конечного решения — представляю, а как можно интегрировать согласно юникс-пути — неа, в упор не представляю. Пхп — это пример не юниксовой философии, а образцово-показательного бардака. V8 долизан до такого состояния что генерит адекватный машинный код в реалтайме. Потому по скорости там всё чудесно. Другое дело что надо им научиться напрыгивать на все ядра процессора. Если у них stop-the world GC и отсутсвие нативной поддержки многопоточности, то натягивай-не натягивай, смысла не будет. Да не только для меня. Действительно, поторопились вы с публикацией такого сырого перевода. Ужасные кальки с английского. Если есть возможность — опишите, пожалуйста, в личку, что конкретно резануло. Расти есть куда, я не спорю, первый же перевод. Кальки можно использовать как приём, безусловно. А Вы знакомы с Тедом Мосби? Я, бывает, смотрю про него сериал. Забавный парень, скажу я вам, но сюжет вытягивает один Барни уже который сезон. Между тем тот же код в php: Между тем через много лет: Что я делаю не так? Перевод очень хороший, кстати. Легко читается, понимается без напряжения мозга. Мне чтобы сделать на таком уровне, нужно сначала перевести с английского на русский, а потом с русского на русский. Спасибо, наконец-то пригодилось высшее филологическое: Меня немного сбило с толку обращение к педантизму хабровчан, я даже на всякий случай несколько раз перечитал имя автора и подглядел первые комменты. Жаль, что, благодаря интерфейсу Хабрахабра, понять, что это перевод, теперь можно только дочитав до конца и увидев мааасенькую ссылочку на оригинального автора: Вот-вот, только хотел написать, что практически все переводы тут спокойно узнаю по нехарактерным оборотам:. Хабр в очередной раз показал свою стадность. За то что люди мыслят похожим образом? Или за то что плодят бесполезные комментарии? Количество всевозможных точек зрения много меньше людей. Так что мыслить одинаково обречены даже те, кто на словах стыдится этого. Я не знаком с автором перевода лично. Ага, и к концу такой облом, что перевочика не польешь говном за спорную статью. Может в оригинале и сойдет, но не в русском. Всегда поражали люди которые так говорят. Вы знакомы с Ted Dziuba лично? Поэтому называете его Ted? Или вы чувствует СВЯЗЬ между вами когда читаете его блог? Или это у вас так в Краснодаре принято? Саша, что на это скажешь? Нет, я не знаю Теда лично, но давненько почитываю его опусы, да и вообще он мне интересен как личность. Я не вижу ничего страшного в том, чтобы называть людей по имени, ведь оно затем и даётся, разве нет? И кстати, в той культуре, откуда родом Тед а также в родственных люди обычно представляются по имени причем так делает кто угодно, вплоть до нобелевских лауреатов , и предпочитают, чтобы их так называли. Автору спасибо за перевод. Расскажите мне об этом. E-mail, принимающий жалобы от персон, оскорбленных нецензурной лексикой: Время ответа — 5 секунд. Тед посчитал время запуска программы curl, её работы и завершения. Типичная ошибка разных тестировщиков скорости. Числа в V8 как и в PHP представляются в виде машинных чисел в процессоре. По-этому математика там будет быстрой. Тест с числами Фибоначчи выбран не удачно что бы показывать тормоза. Что насчёт результатов ab? Очевидно что у вас разное желехо и результаты разные. По результатам четко видно, что б о льшую часть времени курл провел в заблокированном состоянии читай: Тут и без тестов понятно что пример будет тормозить. Этот пример говорит лишь о том, что его автор не понимает как работает node. Вот перевод отличной статьи. Золотые слова из неё: Если перечислять всё можно скопипастить почти всю статью. Как по мне — обычная гипербола. Есть лозунги и есть реальность. Как только дело доходит до серьезных денег, писать будут те, кто разобрался. А что разбираться легче, так за это автору спасибо. Вас всерьез беспокоит чем увлекаются другие? Вы сокрушаетесь, что кто-то сделает не достаточно хорошо по вашим меркам только потому, что пошел на поводу у лукавой рекламы? Или вам никто не рассказал, что это плохо — негодовать по поводу чужих предпочтений, не совпадающих с вашими? Доводы автора о не правдивости рекламы node. А то, что Тэд искал в ней универсальность викторинокса — личные проблемы Тэда и других страдающих психозом перфекционизма. Не существует самого лучшего языка или архитектуры, есть лишь удачные для определенного круга задач. Боюсь вы введены в заблуждение. Приступая к использованию этих платформ начинать экспериментировать с масштабиемостью уже поздно — на момент запуска проекта на этих сервисах надо уже четко осознавать что и для чего ты делаешь, чтобы избегать блокировок уровня архитектуры кластера. А при этом возникают проблемы, в сравнении с которыми блокировка потока node. Ну запустил для вашей задачи EC2 копию вашего сервера на соседнем ip, как вы собираетесь синхронизировать копии данных? Заблокируете копии приложения обращением к одной базе данных с разных серверов? Включите зеркальную репликацию данных между серверами, создав затор обменом между копиями СУБД? Нет, тут уже не отделаешься простыми решениями, за которые так ратует автор поста. Вот так поэкспериментируешь с EC2 и дойдет в чем главные преимущества однопоточной архитектуры для масштабирования. И перестанете слушать всяких троллей. Да на любом оно будет работать, если не через одно место писать. Тысяча операций сложения — пшик. Но, если писать рекурсивную функцию, да ещё такую, которая для подсчёта числа высчитывает два предыдущих а для тех ещё два, … , то конечно, тут не поспоришь. Если загнать ОС в глубокий SWAP, то может и больше. Но в данном случае конечно большая часть процессорного времени была занята тяжелой рекурсивной функцией. Где умное-то в этом тексте? А HN, кстати, давно утвердился в качестве ведущей помойки англоязычного программерского сообщества. И ведь кому то было не лень переводить это все, с матершиной, и выкладывать на Хабр. Кому что нравится, тот и использует: Райан из ничего сделал ведущий JS рантайм, и получает за это тонны навоза на голову каждую неделю. Я читаю лично Теда, о HN узнал от вас только что. Мне было не лень переводить пост, который меня задел. Вообще, я надеялся, что придут гуру серверного JavaScript и расскажут подробно, в чём Тед ошибается. Пока аргументов было немного, а из исходника по вашей ссылке я понял, что его писал не-менее-чем-эксперт. Тед же подошёл с позиции именно такой, и успешно доказал, что кухарка сервера писать всё ещё не может. Да, слог просто чудесный. Я даже не догадывался что это перевод. А мне вот наоборот очень даже нравится node. Блокируемыми являются потоки, но не сам процесс. Читая перевод возникло ощущение того, что Тэд считает, что блокировка потока означает блокирование процесса. Не считает, и даже упоминает, к каким проблемам может привести бесконечное рожание потоков. А Ferrari SA Aperta очень не удобно ездить на дачу. Статья — совершенно однобокий взгляд на node. Обсуждать даже смысла нет. О том как именно работает event loop и что делать со сложными математическими вычислениями написана тонна статей. Если кто-то использует node. Так ведь Райан сам призывает забыть обо всём и просто писать быстрые приложения, не заботясь ни о чём. Собственно, маркетинг в этой статье, по большей части, и высмеивается, ну а про unix way Тэд просто не мог не упомянуть. Серверный JS сильно отличается от клиентского, хотя заманчиво на него похож. Многие начинают использовать node. Большая часть JS-скриптов на клиенте работает 1 раз при генерации страницы или основываясь на действиях пользователя клики, ввод данных и т. В простых клиентских скриптах не обязательно заботиться об очистке памяти, о сильно скрученных замыканиях и т. И кажется что JS очень простой. Но когда такой же стиль написания применяется в серверном JS — все недочёты быстро дадут о себе знать. И в этом месте начинающие node. Серверный JS не для домохозяек. JS про простоту разработки нужно отсчитывать от уровня самого Райана: А так, это просто краткое описание принципов работы node. В любом случае — лить говно на чей-либо труд таких объёмов, основываясь только на нескольких строчках главной страницы, приводя примеры, которые заведомо будут тормозить — это обычный троллинг. Таких примеров можно привести миллион: Райану — огромное спаисбо за работу. Горе-разоблачителям — вкусной кормёшки. А теперь вопрос зачем на этом писать? Для io-bound как пишут ниже? Для этого можно спокойно взять java. Тут только что написали, что server side javaScript отличается от client side. Что по сути выливается в разные парадигмы программирования. К примеру при использовании Chromium? Тоже самое можно спросить, а зачем писать на Java, если можно на node. Всё зависит от конкретной задачи, конкретного разработчика, его опыта и привычек. Плохую программу и хорошую программу можно написать на любом языке. Хотя бы по той причине, что не надо ломать себе мозг той самой серверной реализацией. Опять-таки, это можно сказать и про Java. Одно дело когда у вас разные языки. А другое дело когда язык один, а подходы разные. И вы на дню по несколько раз переключаетесь туда сюда. Джаваскрипт динамический и слабо типизированный. Он по определению будет медленнее джавы. Насколько — это уже зависит от паттернов использования и изощрённости движка. По моему язык здесь не причем, а виновата асинхронная модель программирования. На JavaScript можно и удобно писать код в синхронном стиле используя RingoJS или мой проект Common Node. Если интересно, то вот моя презентация с RejectJS в Берлине на прошлой неделе. Спасибо за перевод, очень экспрессивно. Сам думал перевести, но вчитался, и понял, что не буду. По уму — автор неправ. Гораздо интереснее и точнее вот это: Да, аналогично unicorn или nginx, есть и такая магия. Для ростоты есть библиотеки типа github. Какой-то бессмысленный текст — автор показал, что рассчет числа Фибоначи займет 5 секунд? А что, если он напишет его рассчет и запустит в CGI-сервере, он отработает быстрее? Есть определенная ниша, где применение событийных фреймфорков здорово помогает типичный пример — тысячи висящих соединений с иногда происходящими на них событиями. Нахваливаемый автором юникс-вейный CGI это ж надо было додуматься, на каждое входящее соединение стартовать по процессу!!! Ну вы знаете, это то же, что бывает с сервером, если после установки Апача не понизить MaxChild который там по дефолту то ли в , то ли в установлен. Так что статья ни о чем. Если вы пишете скрипты, которые работают по 5 секунд с полной загрузкой CPU, вам ничего уже не поможет. В CGI сервере, по крайней мере, этот расчёт не заблокирует accept входящих соединений, позволит загрузить все ядра CPU параллельными запросами этого расчёта, и не помешает параллельно с медленной обработкой этих запросов быстро обрабатывать другие запросы как CGIшные так и на статический контент. И да, форк это тоже не решение в современных условиях, здесь я с Вами полностью согласен. На мой взгляд суть статьи в том, что: Лучше ноды тут Erlang, Scala, Haskell, а потом уже все остальное. Erlang ещё быстрее чем Node. Вот многие нахваливают Erlang — особенно в сравнении с Node. Щас почитал немного и пока не понял — в чём его прелесть? Можно завести по одному потоку на каждое из нескольких десятков тысяч подключений и не опупеть. JS — код выглядит как код, а не как лапша: Кажется, начинаю понимать прелесть. Правда, с другой стороны смущает, что, например, в списках вроде как нельзя обратиться к, скажем, второму элементу списка, или ещё что-то вроде этого… А так же иммутабельность. Да и обращаться ко второму элементу списка даже и не вспомню, когда приходилось. И иммутабельность, и набор типов данных приводят к другим алгоритмам работы с ними. Не очень сложно переучиваться то? Что хорошего посоветуете почитать? По наблюдениям некоторых товарищей, продакшн код вполне получается писать через 2 недели изучения. Из почитать, можно начать с Learn You Some Erlang for Great Good! Лично я учил по Erlang Programming. Ну а потом уже можно и OTP in Action. Причём " Learn You Some Erlang for Great Good! Pragmatic Programmers, Erlang in Practice. Это прям как ядерной ракетой банку тушенки открывать: Про язык вам уже выше сказали, но основная фишка в другом — это предельно тщательно продуманная платформа, прошедшая проверку огнём, водой и медными трубами. Практически на любую архитектурную проблему, с которой вы столкнётесь, вы найдёте хорошее идиоматичное решение в рамках фреймворка, без прикручивания сторонних костылей — от конфигурирования и деплоймента до обновления. Сравнить это можно разве что с Java EE — больше я решений подобного уровня не видел. Но в OTP всё это делается куда как понятнее и читабельнее. Я бы за это предложение Вам руку пожал! Это чистый троллинг в стиле Теда Дзюбы. Он специально пишет так, чтобы те, кто мог оскорбиться, оскорбились и уронили планку. Статью перевёл оттого, что боль в жопе никогда не мешала мне трезво мыслить. Этот подход в корне неверен, и мы уже видели, к чему он приводит, на примере PHP, только там похожий тезис повторяли фанатики, а здесь — сам создатель инструмента. Это мы, опять же, видели на примере PHP, в который очень быстро влилось множество кухарок, а через год миллионы людей начали его хаять за то, что на нём можно писать говнокод. Пожалуйста, покажите, какие именно ответы я проигнорировал: Пойду почитаю HN, на который мне показали перед сном. За публикацию здесь этого троллинга можно было бы к вам претензий не предъявлять. Но вы в качестве собственной позиции высказываете троллистские акценты и это уже достойно порицания. Текст основан на, мягко говоря, притянутых за уши аргументах: Нет такой области компьютерной инженерии, где всё пишут специалисты. Послушайте что говорят бухгалтера про разработчиков желтой программы, про банк-клиенты. Посмотрите на множество убожеских сайтов. То же самое творится у строителей, педагогов, медиков… Один специалист на 50 ничтожеств. Таков наш мир и наивно полагать, что загнобив одного выскочку за то, что он пообещал слишком красиво, вы измените мир к лучшему. Перфекционизм — болезнь и вам с Тэдом не плохо бы от нее вылечиться перед тем, как писать для публики. Это, блядь, проблема процессора, который исполняет одну программу одним потоком. Это не ошибка проектирования, а логическая основа программирования. Наезжать а это всё равно, что критиковать ускорение свободного падения. Не умеешь обходить блокировки — пиши под cgi, пусть эта проблема переляжет на плечи админа. CGI давно доказал свою несостоятельность для серьезных проектов. Использовать Nginx в качестве http-сервера никто не мешает. И причитать по этому поводу совершенно не конструктивно. Чистый троллинг на пустом месте. Tornado умеет асинхронно отдавать данные, не блокируя других клиентов. Так что проблемы с Фибоначчи там просто нет. Думаю, что и в Node. Статья интересная, но многовато ругательств. И что же интересного в статье? Срыв покровов что фибончаи заблокируют поток? Как будто пацаны этого и так не знают. Что кому-то не нравится JavaScript? Что какой-то чувак не будет писать на Node. Хоть бы одну интересную проблему обозначили, а то выглядит так как будто автор прочитал статью на википедии перед сном и пошел срывать покровы. Даже пассаж про веб сервера странный, как будто nginx не цепляют повсеместно перед той или иной динамикой. То, что даёт определённую пищу для размышлений. Любая статья, отрицательно ориентированная к некоему продукту, какой бы однобокой и лживой ни была — всегда полезна. Другое дело, что Node не предназначен для писания CMS, а менее-чем-эксперты, которых своею политикой притянул Райан, пытаются совать его куда ни попадя, не задумываясь, ведь им же сказали, что это идеальное решение. Я не слишком большой спец во всех технологиях, но если мы пишем что-нибудь высоконагруженное на python, ruby, java нам не нужен nginx для статики? То есть перед python, ruby, java нам нужен FastCGI сервер вроде nginx, как и для Node. Вы таки не поверите, перед perl, php, python за остальные говорить не буду нужен веб-сервер! Fast он будет или просто CGI — неважно, интерпретатор не берёт на себя работу веб-сервера. Другое дело что для своих задач веб сервер node можно использовать как standalone с высокой степенью крутости ну и да, на CMS-ках смысла может и не быть. Во-вторых, кто вам сказал, что веб-сервер перед node — это плохо? Суть как раз в том, что в node веб-сервер реализуется просто в виде прослушки порта и коллбека для входящих запросов с удобным API. Это чертовски удобно для реализации веб-сервисов, но довольно геморно, когда вы хотите реализовать полноценный сайт с отдачей статики, кешированием ответов, распределением нагрузки и т. Поэтому перед node и ставят веб-сервер, который берет на себя все эти задачи вместо того, чтобы приходилось изобретать свой, довольно странный и, скорее всего, ненадежный велосипед в виде программного решения на js. И это не мешало появлению HTTP-серверов написанных на perl и python. Те же разработчики tornado хоть и пишут, что на продакшне у них стоит nginx, внедрили в свой фреймворк и настоящий http-сервер. Я не вижу в этом разнообразии ничего плохого, хотя nginx ставлю и перед apache тоже. Ну и на PHP тоже вебсерверы есть. В большинстве случаев лучше. По той же логике Nikon виноват, что большинство хозяев цифрозеркалок снимает в режиме Auto. Как посмел Nikon сказать, что фотографировать может быть проще, чем в начале века? Наверно вы за то, чтобы допускать к программированию только обладателей диплома? Когда до вас дойдет, что мир не совершенен? Нет такого профессионального инструмента, которым не пользовались бы не по назначению и так будет впредь. На PHP, хоть я его и не праздную, было написано немало хороших, профессиональных программ. И на Java-Scala-Erlang не смотря на более высокий порог вхождения написано немало фигни. Не надо сокрушаться о вселенной. Просто пишите свой код настолько качественно, насколько можете и это почти всё, что можете сделать вы. Не заплевывать технологию только за то, что туда привлекают начинающих, а реально делать качественный код и популяризировать профессиональные подходы к программированию. Тед приводит доказательства блокирования потока процессорными вычислениями не воспользуются менее-чем-эксперты тиками, нет , а не блокирования сервера отдачей данных клиенту. Я как-то не обратил внимания, думал речь идёт об отзывчивости сервера. А тут вона как, внезапные срывы покровов, 2-й курс универа! Приложение на потоки для того и разделяют, чтобы при блокировании одного, не блокировались остальные. Ожидать, что никакой из них никогда не заблокируется бессмысленно. Иначе начерта они нужны, можно всё тогда синхронно лабать. Автор не зря начинает статью с объяснения, почему эти утверждения — откровенная ложь. Автор придирается к словам ради красивого троллинга и не более. Надеюсь я не спалил идею для поста У него манера такая. Ну так это не дельная вещь, а банальность. Если бы эта идея была бы хоть как-то аргументирована, было бы интереснее. Эту банальность забыло 8 человек из Поэтому мы имеем HTML5-приложения в мобильных телефонах. Тот самый HTML5, в на любую задачу есть два параллельных и никак не взаимодействующих решения. Поэтому мы имеем джаваскрипт в качестве единственного браузерного языка вместо байткода или подхода NaCL. Поэтому мы имеем фанатиков разнообразных подходов — будь то ООП, ФП, TDD или Agile, кричащих, что они нашли серебряную пулю. Нет уж, напоминание о том, что надо думать головой никогда не лишне. Без энтузиастов, осваивающих всё новое, мы бы до сих пор без штанов за мамонтами бегали. Думать головой, конечно, надо, только вот переведённый текст этому отнюдь не способствует — он попросту глуп. Если говорить конкретно обо мне — то хабр я не сичтаю венцом прогресса, и ворчать в ньюсах мне гораздо удобнее. Что касается текста — это он ещё мало обругал человека, пытающегося в рекламе своего продукта врать, что масштабируемость — это легко, когда никакой лёгости там и близко нет. Кто хочет лёгкую масштабируемость — пусть берёт эрланг, он простой на самом деле. Только там тоже думать понадобится — хотя бы о том, чтобы лишние потоки данных не гонять между разными машинами. Чёрт, а я уже почти поверил, что хотя бы в Эрланге думать не надо будет. А вы ничего не путаете? Или мы с вами разную рекламу видели? Понятно, что горизонтально его не отмасштабировать. Нод действительно может обслужить больше параллельных запросов чем апач на том же сервере. Я только что читал его пост про NoSQL. Все его аргументы сводятся к тому, что раз реальный бизнес пользуется SQL, значит NoSQL это фигня. Вы тоже разделяете такую логику? Torando точно так же блокируется процессорным вычислением, автор просто не понимает принципа асинхронных фреймворков и их применения. Автор всё прекрасно понимает. Он делает вид, что он менее-чем-эксперт, берёт пример из документации, пишет в него свой функционал разве не так поступают начинающие? Ну а unix way — это любимая тема автора, и я с ним во многом согласен. Или фибоначчи должны были посчитаться за минус 0. Ну так в чем проблема? Автор объясняет что даже неблокирующиеся программы требуют время на выполнение? Тогда не хватает ещё объяснения что они ещё и память требуют. Он бы тогда создал массив гигов на 10 и кричал что ноджс говно, потому что на его старом ноуте с мегами оперативы всё тормозит. Он не ставит знак равно. Он говорит, что CPU-bound программы — это тоже блокирующие программы. И ещё одно — вторую претензию автора тоже не стоит забывать — а состоит она, напомню, в том, что нод — плохой комбайн. С одной стороны, в нём лишний раз реализован HTTP-сервер вместо, к примеру, на порядок более простого FastCGI-сервера , а с другой — этот сервер примитивен, что всё равно заставляет держать какой-нибудь nginx. При этом администрирование сервера и модификация программной логики поневоле будут свалены в кучу. Вам не объяснили на первом курсе почему это не новость? Автор, конечно, пишет хуергу, с которой даже спорить нет смысла, поскольку его аргументация просто несостоятельна. Впрочем выше в камментах всё уже написали. НО Вы отлично перевели текст. Переводите хорошие тексты дальше, пожалуйста: Автор — знатный наркоман. Ни про мутантов, вешающих между nginx и nodejs что-то ещё, ни про тех, для кого fibonancci без memorize в веб-сервере ЩИТО ВООБЩЕ ВЫ ТАМ ЧТО СЕБЕ В ВЕНУ КОЛЕТЕ? Я тоже так считал, лет назад… bolknote. Надо отметить, что стиль изложения просто отличный. Единственное, что я почерпнул из этой статьи: И не поспоришь ведь. Берегите здоровье — осторожнее с граблями, куда попало не суйте. Не нужно устраивать крестовые походы. Если технология стоящая — она выживет и многие недостатки ее будут устренены, если нет — она канет в лету. Ты программист PHP и не хочешь переходить на node. Лучшая технология для тебя — та, которой ТЫ владеешь, тонкости и ньюансы которой ТЫ знаешь и понимаешь НА ГЛУБОКОМ УРОВНЕ, когда ты с ними сталкивался и их прочувствовал, когда твое понимание технологии выстрадано, а не просто изучено. А что до ограничений… любая технология имеет свои плюсы, и свои минусы. Прочитав, хочется спросить — дядя Тед, ты дурак? Хотя понятно, на самом деле, что не дурак, а тролль. Любому разработчику очевидно, что аргументированно спорить с этим набросом на вентилятор нет никакого смысла. Но исключительно из уважения к труду переводчика: Ах, Нода тратит CPU — ВСЁ тратит CPU. Ежу понятно, что любой код исполняется на CPU, а не в квантовом мультиверсе. Если дядя Тед знает хоть одну технологию проограммирования, не тратящую вычислительные ресурсы — мы его внимательно выслушаем. Но несмотря на то, что всё тратит процессорное время, это время — самый дешёвый из имеющихся ресурсов. Заставить веб-сервер упереться в процессор ОЧЕНЬ сложно. Он гораздо раньше упрётся в диски, в сеть, в БД… Исключение блокировок диска, сети, БД и т. Как и PHP, Java и кто угодно ещё. Ах, Нода не юникс-вей, ой-вей. Ни в одной ещё раз: На любом более-менее посещаемом сайте вначале стоит Nginx или что-то вроде, а потом стоит бэкенд, обрабатывающий динамику. Даже если бэкенд сам по себе умеет обрабатывать внешний HTTP как апач, например , Nginx, как в том анекдоте про папу Вовочки и быка, просто сделает это лучше. Нода — одна из компонент для построения многокомпонентной системы, не более. А реальные системы НЕ БЫВАЮТ однокомпонентными. Любить или не любить JavaScript — вопрос исключительно вкусовой. Использовать или не использовать Node. У него ничего не сломается от такого. Я предлагаю альтернативу проблемам node. А я пользуюсь Tornado, а не node. Вы считаете мне тоже надо написать о его отличиях, даже если это будет офтопом? Но отличий в Tornado от Node. JS практически нет — те же грабли, вид сбоку. Спасибо за ссылку, но информация там не полна: OTP интересная штука, присмотрюсь. Видите ли, в PHP тоже ничего глобально не сломается — просто процесс будет грохнут апачем через заданный таймаут. Но это же не значит, что так и надо писать. А такое легко случается с синхронными приложениями при высокой нагрузке. Тогда как асинхронные всего-лишь могут выпасть по таймауту при переполнении запросами. То есть система останется стабильной и обслужит максимум запросов максимально используя ресурсы. Перезалейте, пжлст, статью Райана Дала куда-нибудь. У меня длинный белый лист открывается. Там тоже есть с чем поспорить, кстати. Что-то у него общего есть с кодерами из suckless. Стано что никто не удивился алгоритму подсчета чисел фибоначи, капитально вызывающий рекурсию и считающий хрен знает что…. Считает он вполне себе числа Фибоначчи, самым простым методом. И для удивляющихся есть комментарий про замкнутое решение. Это классический синтетический тест. Вот странно, у меня на нескольких языках, влкючая JS, уходит в рекурсию. Так это рекурсия и есть. Почитайте подробнее про числа Фибоначчи. Нащупал интересную вещь, эта функция работает ТОЛЬКО на v8. Вы хотели сказать, быстро работает? Отлично справился циклом for без рекурсий. ПС под рекурсией в имел ввиду программную рекурсию. Возможно ли такое что ядро V8 дало отлуп рекурсии через 5 секунд как в браузерах? Нет, он вывел в консоль верный ответ, , это 41е число Фибоначчи. Автор нашёл слабое место v9, и показал как плохо сервер работает, используя это слабое место. А то что если заставить nodejs отдавать статический контент, даже если он будет на лету генерироваться с помощью шаблонизатора, и при этом получить производительность порядка запросов в секунду, про это мы не говорим, ага. Переводчику спасибо, узнал что бывают такие истерички. Игорь Сысоев имена с большой буквы пишутся говорил о том, что node. Intel Core i5 3. С одним ядром дает около rps, но надо учитывать, чо бенчмарк тоже на этой же виртуальной машине работает. Так что выходит одно ядро грузится нодой, а остальные 3 бенчмарком. Вы померили отдачу хелловорлда, что в реальной жизни никому неинтересно. Рассказываю, как мерить правильно: Мне оказалось или вы предлагаете отдавать статику через node. И не вижу ничего плохого в раздаче статики через node. Вы широким жестом отдаете v8 заниматься работой, для которой написан nginx? Вам это не кажется неоправданным пижонством? И тут возникает дилемма: Я предложил потестировать одну из лимитирующих производительность частей — отдачу с диска фрагмента клиенту. А тестить отдачу 12 байт клиенту — весьма сомнительный бенч. Прошу прощения, что лезу в ваши личные предпочтения относительно архитектуры приложения, но в вашем гипотетическом случае я бы не стал серверу приложений давать больше работы, чем ему нужно — разобрал запрос, сделал редирект на нужный файл и дальше nginx, возможно даже на другом сервере или на связке серверов отдает эти файлы. И много ли людей используют такое решение? Статику всегда отдает фронтенд сервер, в то время как app-сервер занимается тем, чем он должен заниматься. Если так интересно, то могу провести желанные вами тесты. В статье ноду трэшат cpu-bound задачей. Так давайте возьмём io-bound, на которые так хорошо ложится event loop: Нет, я не буду писать erlyvideo на node. Хотя бы потому, что уже есть готовый production-ready продукт. Выше я привёл цифры. Как бы быстро перешли от disk-io к network-io и опять используем node. Если бы мне надо было раздавать файлы постоянно, то я бы использовал node. А если так хочется гонять числа фибоначи, то всегда можно соорудить очередь с воркерами. Довольно странное занятие вы нашли, пытаетесь убедить человека который знает, что серебряной пули не существует в том, что ее не существует…. Ну тогда это уже не статика. И тут совсем другой разговор. Ну раздавайте через node. По крону ходит скрипт и подчищает всё, что старше, например, 1 месяца. Основное правило для event loop не нарушено: Но когда вам нужна кастомная обработка запроса например, сделать seek по файлу на значение из параметра offset вы приходите к написанию модуля для nginx. Идея посмотреть как нода раздает файлы: Перечитайте еще раз, что я сказал. Я говорил о статике, а не о том, что вы называете статикой — соорудить в рантайме из пачки файлов один фаил это не статика. Да, правда кроме как для раздачи mp4 модуль уже в core есть мне эта фича не нужна, другое дело Streaming API. Этот контейнер требует предварительной обработки, прежде чем им можно будет пользоваться для стриминга. Если кол-во файлов и их расположение не известно заранее — да, это уже не будет статикой. Конвертации в Baseline Profile? Если надо работать с видео не понимаю почему бы не использовать erlyvideo. Теперь будет про mp4: The moov atom is a part of the file that holds the index information for the whole file. Many encoding software programs such as FFMPEG will insert this moov atom information at the end of the video file. The moov atom needs to be located at the beginning of the file, or else the entire file will have to be downloaded before it begins playing. Ни завтра, ни через месяц. Зато за это время у нас набежит много гигабайт данных и у нас может кончиться место на диске. В комментах поста про эту статью у Lev Walkin было предложено написать видеосервер на ноде и сравнить. Можно не брать rtmp, а взять более простой для работы mpeg-ts там максимум час времени с отладкой. Вот, вы уже ушли от тему в сторону черных способов спора. Mp4 умеет еще нести с собой hint payload для стриминга. Понимаете, бывает, что человеку надо одно, и он решает свою проблему через жопу. Потом ему говорят, что есть же вот такой инструмент который поможет. Человек пытается натянуть жопу на этот инструмент вместо того, чтобы избавиться от костылей и использовать все по назначению — пытается использовать инструмент вместе с теме костылями от которых надо избавиться. Это случайно не ваш случай? Не используй ffmpeg, там генерация mp4 уже давно сломана. Я бы разделил трансляцию и сохранение не разные приложения. Единственная потенциальная проблема — клиенты могут понять его не как mpeg-ts, а какой-нибудь mpeg-ps. Внезапно, у каждого инструмента есть своя область применения, в которой он наиболее эффективен, и есть задачи, на которых его использовать совершенно не нужно. Да ну не воспринимайте серьёзно. Автор передёргивает, гиперболизирует и издевается давнным-давно, в каждом посте. У него такой стиль, это как Лебедев, но в IT и за бугром. Просто очень плохой троллинг, я думал намного лучше будет: Это как называть ассемблер раковой опухолью лишь потому, что кто-то на нем додумался веб-сервисы делать. В данном случае не разбирается. Иначе бы не имел мотива троллить. Хмм, комедии на украинском смешные, а украинофилы — это отличная еда. Епт, ну сюда-то зачем этот бред было переводить. Но вообще вся статья не в кассу. Перевод может и хорош, но не для Хабра. Для двача может быть или где там переводчик обитает. Я не хочу разговаривать матом еще и на Хабре. Алгоритм, который автор использует для вычисления чисел Фибоначчи — это феерический ппц, потому что в нём шизофреническое количество повторных вычислений, и для числа пять подсчёты выглядят подобным образом: Для подсчёта чисел Фибоначчи нужен цикл, тогда каждый член считается один раз: Пытался вкрутить гвоздь лопатой в камень — лопата это раковая опухоль. Вы не поняли — автору как раз нужно было сделать кучу лишних вычислений, чтобы загрузить процессор. Ему не нужны сами числа, ему нужно кулером на проце погудеть: Неоптимальный рекурсивный алгоритм для этого — самое оно. Уважаемый takkmoil, Вы отлично справились с переводом. Даже не будучи программистом, но кое-что в этом понимая, с удовольствием прочитал от и до — круто. Не слушайте ханжей, смело передавайте стиль автора, даже если это требует нецензурщины. Вы однозначно дали стране угля. Я утратил веру в числа фибоначи: Иногда кажется, что айтишники забывают зачем они нужны. Сам по себе труд — никому не нужен. Важен только результат этого труда. Точно такой же код на Erlang выполняется в разы быстрее, чем на Node. Вы смотрели-то на цифры, приведенные по ссылке? И при чём тут node. JS И да, это V8. Зря вы уходите в частности. Оптимальность кода V8 это отдельный вопрос. Вот что надо обсуждать — автор дурак или все-таки он успешно сеет сомнения в головах людей, плохо знакомых с архитектурой компьютера? Автор тролль, я об этом уже написал здесь lionet. То, что автор указал как трагедию, не трагедия, а глупость. Он занял процессор на 5 секунд и начал негодовать, что все 5 секунд ему пришлось ждать результата. На своем любимом Django он получил бы точно такой же результат — 5 секунд ожидания. Это не проблема Node. Хотя в нем проблем действительно хватает. Проблема в том, что Node. А это ест мозг не только девелоперам, но и бизнесу, который говорит примерно так: Коснется вас, тогда и аргументируйте своему системному архитектору или инвестору, что вы собираетесь придерживаться другой школы. Рынок всё расставит по своим местам. Не досужая болтовня о том, что кто-то не прав, а конкретные проекты с конкретной выручкой. Повезет — разовьют эту технологию до каких-то высот, не повезет — дадут опыт набитых шишек. Всё это ценно, а неконструктивная критика — нет. Весь пост автора сводится к А дальше очень много эмоций и мата по поводу того, что разработчики Node. Ничего не имею против эрланга, но доказывать его превосходство на таком заведомо неоптимальном алгоритме — довольно странное занятие. Оптимальность алгоритма — дело десятое, когда его результаты просто выкидываются. Нужно было занять VM какими-то рекурсивными расчётами, вот и заняли. То, что алгоритм неоптимальный — только на руку: Я удивлен, сколько же людей не понимают, что в приведённом примере Node. Там используется тяжелый алгоритм ремарка не в тему , который тупо грузит CPU. А реальные проблемы Node. Что мешает повесить глобальный обработчик? Никто вас не заставляет писать на этом языке, у каждого языка плюсы и минусы, и нужно это понимать и этим пользоваться. Загвоздка в том, что в реальном мире случаются катастрофы. И с этим ничего не поделаешь, как бы хорошо ни продумывать. Как правильно ответили выше, обсуждаются фатальные недостатки инструмента в контексте решаемых задач. Настолько фатальные, что на нем вообще лучше ничего не писать в данном случае, конечно, серверного. Он рассчитывал сделать шоковую новость для начинающих и ему это удалось. Но те, кто разбираются, знают, что проблемы конечно есть, но они меньше и в другом месте. А указанное автором — глупость. В учебнике по Erlang Erlang programming By Francesco Cesarini, Simon Thompson есть сравнение скорости выполнения функций с хвостовой и без хвостовой рекурсии: Каким боком в данной статье node. Насколько я понял, ВКонтакте использует ее для системы обмена сообщениями. Из того факта, что у них очень большие нагрузки и эта штука работает следует, что не все так с ней плохо. На мой взгляд совать node. О уже и тут Интересно, долго ли тема про Node. Спасибо за перевод, понравилось. Интересно было почитать авторитетного рачка с форчана. Жалко последние 4еро суток без сна за которые я делал GPS трекинг для большой компании на Node Из за того что заказчик настоял на Node и никакие аргументы не брали. Не сомневаюсь, что будет весело. На сколько я мог убедиться, с моими задачами Node справляется неплохо, несмотря что можно решить их тривиальным путем. Да что же неприятного? Выбранная технология справляется с задачей, как вы говорите, неплохо, так что же еще нужно?! IBM проталкивает ноду в интерпайз. Назад пути уже нет: На самом деле, столько лет прошло. Нода развивалась всё это время. Успела получить форк и вернуть его в себя. В общем, тут какое дело, ребяты… С одной стороны, мне очень нравится статья, особенно про UNIX-way, меня прям заводит. И пайпы, и CGI, и вот этовсё. И вообще, веб-сервер на bash, который лазит в сеть по inetd — это самый сок. Я не уверен, что это хорошо, но это похоже так. Да, это не unix-way. Нет, ничего страшного в этом нету. Так таки да, очень интересно. Рассмотрим, для примера, вот какую тему. А вот в случае если файлы разные — то асинхронный вариант может быть медленней! Пожалуй, запилю-ка я про это отдельную статью. Метки лучше разделять запятой. Сейчас Вчера Неделя ядерный CPU, а я не могу сдвинуть курсор 16,9k Первая российская материнская плата массового сегмента 25,1k Интересные публикации Хабрахабр Geektimes. Стабильность нейтрона в атомном ядре GT. Анализ трафика GSM сетей в Wireshark. Пять главных аспектов плохой безопасности интернета вещей. От простого к более сложному. Cолнце и ветер стали самыми дешевыми источниками энергии GT. W3C всё-таки одобрил стандарт DRM для HTML5 GT. Как я боролся с комарами. Личный опыт и тесты на себе GT. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.
https://gist.github.com/d260a82011c9fdee00c765a9959a4386
https://gist.github.com/1a5fb396f279004ed1584d173340fe12
https://gist.github.com/9678e698e7e22193366b2aa60a45b1e5