Начиная с 30-ой минуты в видео вы рассказываете, как плохо отлаживать ПО в эрланге, что отладчика там нет… И слава богу :)
В ноде я как-то пытался отлаживать через node-inspector, поставил брекпоинт, нода остановилась, и, пока я смотрел на переменные в вотчлисте, истекла пара таймаутов. После того, как я нажал run, процесс выдал ошибки и пошел совсем по другому пути. С тех пор я просто вставляю принты и перезапускаю ноду.
В ноде вообще-то таймаутов почти нет, и всё равно они у меня сработали. В эрланге же их рекомендуют ставить на каждый receive. Поэтому проблем с паузой там будет на порядок больше. Особенно, если ставить на паузу всю эрланг-машину. И, конечно, такой метод не годится для отладки продакшн системы на лету.
Это, как я понимаю, общая проблема для актор-систем, если они написаны аккуратно, т.е. с таймаутами.
Поэтому, принты, принты и только принты. И вот с этим в эрланге всё очень хорошо: можно подключиться к ноде на лету (даже продакшн), на лету включить трейс на вызов любых функций, на лету получить и время, и переданные аргументы, и результат, и также на лету пропатчить. Такого мне очень сильно не хватает в других языках, включая ноду с её node-inspector.
Я понял, что вы твёрдо против всей этой системы, хорошо в ней разбираетесь и готовы говорить много и красочно. И, конечно, тот абзац, где вы вернулись к теме:
Представьте, что все на диком западе начали охотиться за неуловимым джо. А за это время вымер скот, спился с горя единственный бармен, а когда все пришли предъявлять счет шерифу — он застрелился. И остались в поселке только охотники за головами. Ни баб, ни жратвы, ни связи с большой землей, зато куча дробовиков у каждого в шкафу.
показывает, насколько неожиданно глубоко вы разбираетесь в рыночных механизмах. Безусловно, вы правы, нельзя давать деньги за информацию о преступниках, иначе того и гляди все начнут гоняться за бандитами и подохнут с голоду. Я бы и такси, кстати, не рекомендовал бы оплачивать, а то все начнут друг-друга возить и тоже подохнут с голоду.
Стоп! А если я буду платить за еду, то все начнут мне готовить и подохнут с голоду, а потом и я. Похоже, голод неминуем. Тогда может разрешить охоту за головами, раз финал один и тот же?
Если я сейчас оставлю программирование и вольюсь в общество кардеров, а потом их всех сдам. Банки, думаю, заплатят. Это тоже «порочная и больная система»?
А давайте вспомним Дикий Запад и эти объявления «Wanted» на убийц и насильников, и целый класс охотников за головами, которые только этим и жили. Тоже «порочная и больная система»?
А когда по телеку предлагают деньги за информацию о каком-нибудь преступнике (жаль, только в кино предлагают, в жизни бесплатно), это тоже больная система?
Есть спрос на информацию о вредных личностях, почему бы и не дать предложение. Всем же лучше.
Минуточку. Что вообще может быть плохого в том, что прижали пиратов, которые незаконно распространяют чужой контент ради денег?
Чем они отличаются от всеми нелюбимых издателей? И те и другие строят свой бизнес на чужом контенте. По-моему, они даже хуже: издатели хоть чуть-чуть делятся с авторами, а такие пираты вообще всё в карман.
> В общем, если есть возможность написать все приложение целиком на одном языке — это большое счастье для проекта!
Это не поможет. Знание языка — это очень маленькая часть, от знаний, которые нужны специалисту в той или иной части проекта.
Даже если и там и там JS, фронтендщики не полезут в бекенд, а бекендщики не должны лезть в фронтенд. Они по разному пишут, по разному работают с колбеками (deffered vs async), разные ньюансы (DOM и браузеры vs node и concurrency), разные инструменты отладки, да вообще почти всё разное. Даже разные точки зрения на задачу: фичи и динамика vs стабильность и нагрузка. Бекендщику в фронтенде от знания js примерно столько же пользы, сколько гастроэнтерологу в стоматологии от знаний русского языка и латыни.
Так что время на изучение другого языка (после 10 языков на 11-ый уйдёт час-два + stackoverflow) незначительно на фоне времени, которое нужно, чтобы вникнуть в матчасть, и покрывается с лихвой, если другой язык — это язык заточенный под конкретную задачу, а то и DSL.
> это уже не клиент, ему доверять можно, поэтому достаточно продублировать валидацию на сервер-UI, чтобы не нагружать этим бизнес-логику вообще
На практике, если бекендщик не будет отбрасывать ошибочные запросы с объяснением что не так, то фронтендщики завалят багтрекер тикетами на «глючащий» бекенд, хотя ошибки на их стороне. Поэтому валидация на бекенде нужна, и не из-за паранои, а просто чтобы упростить всем жизнь, как автоматический судья, который решает, у кого бага.
> Авторизация — это щепотка бизнес-задачи (узнать, кто обратился)
Это аутентификация. Я имел в виду авторизацию, т.е. проверку имеет ли этот юзер права на чтение/изменение этих данных. Эта проверка нужна и фронтенду, чтобы попрятать кнопочки и ссылочки, и само-собой бекенду. Вот и дублирование кода.
Про модель, это отсылка к Meteor, где и клиент и сервер расшаривают одно и тоже описание модели. Нет больше этого плюса, если бекенд не на ноде.
Автор очень странный. Первый раз вижу сторонника ноды, который сам говорит, что нода не должна быть бекендом, а всего лишь прослойкой между бекендом и браузером.
Более того, нодовцы должны даже сильнее критиковать эту идею, чем бекендщики. Возьмём валидацию, где её надо делать? Ни один бекендщик не оставит валидацию клиентам, а с его точки зрения ui-backend на ноде — это уже клиент. Значит будет дублирование кода валидации на js и на языке бекенда. Тоже самое с моделью и с авторизацией. Опять дублируем кучу кода. Ассинхронность ноды тоже теперь не достоинство, она никак не поможет бекенду.
И вот единственный плюс от такой прослойки — это то, что бекендщики теперь не думают про REST и веб. Это важно, если у бекенда несколько клиентов, но в остальных случаях эту прослойку скорее всего просто вырежут бритвой Оккама.
Они ставили перед собой цель обеспечить «язык для склеивания» составляющих частей веб-ресурса: изображений, плагинов, Java-апплетов, который был бы удобен для веб-дизайнеров и программистов, не обладающих высокой квалификацией
> а уж переносить ее на backend — это чистой воды мазохизм
Вся горькая суть этого тезиса становится понятна, когда бекенд разработчик обнаруживает, что его либы, которые ещё фронтендщики используют, должны работать в FF, Chrome, IE7-9, а то и в IE6. В этот момент у него обычно появляется когнитивный диссонанс и вопросы к Всевышнему «Как это произошло? Почему я всю жизнь не лез в эти браузеры, и всё равно в конце-концов должен проверять код в осле???»
Из моего субъективного опыта (уже два кода проект на ноде), никто из чистых бекендщиков не рад ноде и js на сервере. Ему рады фронтендщики, которые теперь могут писать серверный код не изучая других языков.
> Наверное не совсем корректно сравнивать какие-то куски кода, вырванные из контекста.
Это не пожет :) Предлагаю просто закрыть вопрос про синтаксис. Перспективы не радужные: само существование CofeeScript и его популярность говорит о том, что людей, которые недовольны js, как языком, очень даже много, и мнения авторитетов вроде Дугласа Крокфорда им не помогают.
> Любое решение кроме Node.js имеет серьезные минусы.
Какие? Пока только одно было: разные языки на клиенте и сервере. А также какие серъёзные минусы есть у решения на ноде по сравнению с другими решениями?
> Но это всё равно не лишает Node.js уникальности — один код на клиенте и сервере.
Тут не буду спорить, не смотря на пример clojure + clojurescript ниже. Надо было так с самого начала, а не пытаться представить ассинхронность как что-то уникальное и инновационное, когда лет 20 назад мы все вешали колбеки на int 21h, а про потоки и локи даже не слышали.
P.S.: Ваш пример не тоже самое, что async.waterfall насколько я помню. В async, если step1() вернёт ошибку, то step2() уже не будет вызван. У вас даже err первым аргументом написан, но обработки нет.
Не у меня. Это вы так сформулировали первый миф: «Node.js — это то, что он не стабилен и запросы иногда теряются».
> На каком языке предлагаете писать? Во сколько раз он быстрее Си?
Что же вы так реагируете :) Я не наезжаю на ноду, просто критикую ваш стиль разрушителя мифов. Вам не кажется забавным, что во всём абзаце, который должен доказать, что нода быстра, сказано только то, что нода медленнее Си в 3-5 раз, и что там можно поднять миллион соединений (а это вообще не про скорость, а про память).
> Примеры ассинхронных конкурентов node.js в студию!
Вашим «уникальным» преимуществом, а именно: «обработка одного запроса не ждёт, пока обработается другой», обладает любой concurrent код, в том числе и многопоточные решения. Было бы странно, если бы не обладали, ведь это и есть смысл concurrent programming :)
> В данном случае «умелые руки» — это руки среднего программиста, имеющего некоторый опыт с node.js (месяц — два).
О да, конечно. Если использовать async.* и другие хитрости, для борьбы с колбеками, возможно такой код станет более или менее прост и красив, по сравнению с другом node-кодом, который эти фокусы не использует. Но стоит только выйти за рамки ноды, посмотреть, как это можно было бы сделать у конкурентов, и всё встанет на свои места. Например два ассинхронных куска кода.
C#
> Главный миф по поводу Node.js — это то, что он не стабилен и запросы иногда теряются. С появлением cluster и domain это больше не актуально.
Претензии к движку решаются с помощью двух модулей?
> Другой миф — Node.js медленный. Тут можно было бы сказать что v8 всего в 3-5 раз медленее Си
Оспариваете медленность утверждая, что он в 3-5 раз медленнее? :)
> Третий миф — это неминуемый Callback Hell. Ассинхронность Node.js — это его идеология и даёт ему уникальное преимущество: новому запросу не нужно ждать пока обработаются все запросы до него. Писать код в ассинхронной среде не совсем тоже самое, что в синхронной, это требует привычки. В умелых руках Node.js код — красив и прозрачен.
Кроме ассинхронных колбеков есть ещё пачка способов, как написать concurrent систему, когда одному коду не нужно ждать другой чтобы выполниться. Очень интересный выбор «уникального преимущества» :)
Ну а про умелые руки вообще хорошо. «Умелые руки» — это такие фантастические руки в которых и dll-ки не конфликтуют, и убунту на 6 версий обновляется сама и с первого раза, и КДЕ собирается под винду без ошибок. Только где бы их найти и сколько они стоят?
> Четвертый миф — это то, что JavaScript является не очень хорошим языком. Дуглас Крокфорд позволил себе не согласиться с этим утверждением.
Так себе опровержение. Если поискать, думаю можно устроить полноценный футбольный матч между именитыми сторонниками и противниками JS.
Вариант 1. Просто посчитали. Например, узнали сколько платит тот же Facebook и уменьшили награду в той же пропорции, в какой популярность Яху меньше популярности Фейсбука ;)
Варант 2. Это стратегическое решение. Специально выбрали смешную цену, чтобы не привлекать ещё больше хакеров к своему сервису. Чинить, наверное, всё равно не собираются, значит чем меньше людей ищут, тем лучше.
Всегда интересно было, почему минусуют за то, что кто-то чего-то не знает. Минус троллю или хаму понятен. Но за ошибку, сказанную нормально, без оскорблений и наездов? Вы сами никогда не ошибаетесь? Вы знаете всё?
В ноде я как-то пытался отлаживать через node-inspector, поставил брекпоинт, нода остановилась, и, пока я смотрел на переменные в вотчлисте, истекла пара таймаутов. После того, как я нажал run, процесс выдал ошибки и пошел совсем по другому пути. С тех пор я просто вставляю принты и перезапускаю ноду.
В ноде вообще-то таймаутов почти нет, и всё равно они у меня сработали. В эрланге же их рекомендуют ставить на каждый receive. Поэтому проблем с паузой там будет на порядок больше. Особенно, если ставить на паузу всю эрланг-машину. И, конечно, такой метод не годится для отладки продакшн системы на лету.
Это, как я понимаю, общая проблема для актор-систем, если они написаны аккуратно, т.е. с таймаутами.
Поэтому, принты, принты и только принты. И вот с этим в эрланге всё очень хорошо: можно подключиться к ноде на лету (даже продакшн), на лету включить трейс на вызов любых функций, на лету получить и время, и переданные аргументы, и результат, и также на лету пропатчить. Такого мне очень сильно не хватает в других языках, включая ноду с её node-inspector.
показывает, насколько неожиданно глубоко вы разбираетесь в рыночных механизмах. Безусловно, вы правы, нельзя давать деньги за информацию о преступниках, иначе того и гляди все начнут гоняться за бандитами и подохнут с голоду. Я бы и такси, кстати, не рекомендовал бы оплачивать, а то все начнут друг-друга возить и тоже подохнут с голоду.
Стоп! А если я буду платить за еду, то все начнут мне готовить и подохнут с голоду, а потом и я. Похоже, голод неминуем. Тогда может разрешить охоту за головами, раз финал один и тот же?
Если я сейчас оставлю программирование и вольюсь в общество кардеров, а потом их всех сдам. Банки, думаю, заплатят. Это тоже «порочная и больная система»?
А давайте вспомним Дикий Запад и эти объявления «Wanted» на убийц и насильников, и целый класс охотников за головами, которые только этим и жили. Тоже «порочная и больная система»?
А когда по телеку предлагают деньги за информацию о каком-нибудь преступнике (жаль, только в кино предлагают, в жизни бесплатно), это тоже больная система?
Есть спрос на информацию о вредных личностях, почему бы и не дать предложение. Всем же лучше.
Чем они отличаются от всеми нелюбимых издателей? И те и другие строят свой бизнес на чужом контенте. По-моему, они даже хуже: издатели хоть чуть-чуть делятся с авторами, а такие пираты вообще всё в карман.
Это не поможет. Знание языка — это очень маленькая часть, от знаний, которые нужны специалисту в той или иной части проекта.
Даже если и там и там JS, фронтендщики не полезут в бекенд, а бекендщики не должны лезть в фронтенд. Они по разному пишут, по разному работают с колбеками (deffered vs async), разные ньюансы (DOM и браузеры vs node и concurrency), разные инструменты отладки, да вообще почти всё разное. Даже разные точки зрения на задачу: фичи и динамика vs стабильность и нагрузка. Бекендщику в фронтенде от знания js примерно столько же пользы, сколько гастроэнтерологу в стоматологии от знаний русского языка и латыни.
Так что время на изучение другого языка (после 10 языков на 11-ый уйдёт час-два + stackoverflow) незначительно на фоне времени, которое нужно, чтобы вникнуть в матчасть, и покрывается с лихвой, если другой язык — это язык заточенный под конкретную задачу, а то и DSL.
На практике, если бекендщик не будет отбрасывать ошибочные запросы с объяснением что не так, то фронтендщики завалят багтрекер тикетами на «глючащий» бекенд, хотя ошибки на их стороне. Поэтому валидация на бекенде нужна, и не из-за паранои, а просто чтобы упростить всем жизнь, как автоматический судья, который решает, у кого бага.
> Авторизация — это щепотка бизнес-задачи (узнать, кто обратился)
Это аутентификация. Я имел в виду авторизацию, т.е. проверку имеет ли этот юзер права на чтение/изменение этих данных. Эта проверка нужна и фронтенду, чтобы попрятать кнопочки и ссылочки, и само-собой бекенду. Вот и дублирование кода.
Про модель, это отсылка к Meteor, где и клиент и сервер расшаривают одно и тоже описание модели. Нет больше этого плюса, если бекенд не на ноде.
Более того, нодовцы должны даже сильнее критиковать эту идею, чем бекендщики. Возьмём валидацию, где её надо делать? Ни один бекендщик не оставит валидацию клиентам, а с его точки зрения ui-backend на ноде — это уже клиент. Значит будет дублирование кода валидации на js и на языке бекенда. Тоже самое с моделью и с авторизацией. Опять дублируем кучу кода. Ассинхронность ноды тоже теперь не достоинство, она никак не поможет бекенду.
И вот единственный плюс от такой прослойки — это то, что бекендщики теперь не думают про REST и веб. Это важно, если у бекенда несколько клиентов, но в остальных случаях эту прослойку скорее всего просто вырежут бритвой Оккама.
Ну надо же! Вот, оказывается, почему Интернет стал таким популярным.
Вся горькая суть этого тезиса становится понятна, когда бекенд разработчик обнаруживает, что его либы, которые ещё фронтендщики используют, должны работать в FF, Chrome, IE7-9, а то и в IE6. В этот момент у него обычно появляется когнитивный диссонанс и вопросы к Всевышнему «Как это произошло? Почему я всю жизнь не лез в эти браузеры, и всё равно в конце-концов должен проверять код в осле???»
Из моего субъективного опыта (уже два кода проект на ноде), никто из чистых бекендщиков не рад ноде и js на сервере. Ему рады фронтендщики, которые теперь могут писать серверный код не изучая других языков.
Это получается, у нас тут серебрянная пуля, технология без недостатков? А как же у каждой медали есть две стороны?
Это не пожет :) Предлагаю просто закрыть вопрос про синтаксис. Перспективы не радужные: само существование CofeeScript и его популярность говорит о том, что людей, которые недовольны js, как языком, очень даже много, и мнения авторитетов вроде Дугласа Крокфорда им не помогают.
Какие? Пока только одно было: разные языки на клиенте и сервере. А также какие серъёзные минусы есть у решения на ноде по сравнению с другими решениями?
Тут не буду спорить, не смотря на пример clojure + clojurescript ниже. Надо было так с самого начала, а не пытаться представить ассинхронность как что-то уникальное и инновационное, когда лет 20 назад мы все вешали колбеки на int 21h, а про потоки и локи даже не слышали.
P.S.: Ваш пример не тоже самое, что async.waterfall насколько я помню. В async, если step1() вернёт ошибку, то step2() уже не будет вызван. У вас даже err первым аргументом написан, но обработки нет.
Не у меня. Это вы так сформулировали первый миф: «Node.js — это то, что он не стабилен и запросы иногда теряются».
> На каком языке предлагаете писать? Во сколько раз он быстрее Си?
Что же вы так реагируете :) Я не наезжаю на ноду, просто критикую ваш стиль разрушителя мифов. Вам не кажется забавным, что во всём абзаце, который должен доказать, что нода быстра, сказано только то, что нода медленнее Си в 3-5 раз, и что там можно поднять миллион соединений (а это вообще не про скорость, а про память).
> Примеры ассинхронных конкурентов node.js в студию!
Вашим «уникальным» преимуществом, а именно: «обработка одного запроса не ждёт, пока обработается другой», обладает любой concurrent код, в том числе и многопоточные решения. Было бы странно, если бы не обладали, ведь это и есть смысл concurrent programming :)
> В данном случае «умелые руки» — это руки среднего программиста, имеющего некоторый опыт с node.js (месяц — два).
О да, конечно. Если использовать async.* и другие хитрости, для борьбы с колбеками, возможно такой код станет более или менее прост и красив, по сравнению с другом node-кодом, который эти фокусы не использует. Но стоит только выйти за рамки ноды, посмотреть, как это можно было бы сделать у конкурентов, и всё встанет на свои места. Например два ассинхронных куска кода.
C#
и node:
async.waterfall([ function step1(done) { func1(some_const, done); }, function step2(var1, done) { func2(some_const + var1, done); } ], final_callback);> Главный миф по поводу Node.js — это то, что он не стабилен и запросы иногда теряются. С появлением cluster и domain это больше не актуально.
Претензии к движку решаются с помощью двух модулей?
> Другой миф — Node.js медленный. Тут можно было бы сказать что v8 всего в 3-5 раз медленее Си
Оспариваете медленность утверждая, что он в 3-5 раз медленнее? :)
> Третий миф — это неминуемый Callback Hell. Ассинхронность Node.js — это его идеология и даёт ему уникальное преимущество: новому запросу не нужно ждать пока обработаются все запросы до него. Писать код в ассинхронной среде не совсем тоже самое, что в синхронной, это требует привычки. В умелых руках Node.js код — красив и прозрачен.
Кроме ассинхронных колбеков есть ещё пачка способов, как написать concurrent систему, когда одному коду не нужно ждать другой чтобы выполниться. Очень интересный выбор «уникального преимущества» :)
Ну а про умелые руки вообще хорошо. «Умелые руки» — это такие фантастические руки в которых и dll-ки не конфликтуют, и убунту на 6 версий обновляется сама и с первого раза, и КДЕ собирается под винду без ошибок. Только где бы их найти и сколько они стоят?
> Четвертый миф — это то, что JavaScript является не очень хорошим языком. Дуглас Крокфорд позволил себе не согласиться с этим утверждением.
Так себе опровержение. Если поискать, думаю можно устроить полноценный футбольный матч между именитыми сторонниками и противниками JS.
Варант 2. Это стратегическое решение. Специально выбрали смешную цену, чтобы не привлекать ещё больше хакеров к своему сервису. Чинить, наверное, всё равно не собираются, значит чем меньше людей ищут, тем лучше.