Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 70
Знаете, многие программисты боятся/избегают таких вещей как асинхронное программирование или многопоточное программирование. Это чисто психологическое явление, но это факт (на слайдах недавнего выступления Роба Пайка была фраза «Threads scare people.»).
Лично меня асинхронное программирование не пугает — я пишу асинхронный код уже более 10-ти лет (в основном на Perl, но это не важно), делал свой event loop (не от хорошей жизни, просто в 2004-ом не было готовых библиотек для perl на epoll), написал кучку модулей (для асинхронного I/O, асинхронной работы с MySQL, etc.) на CPAN, недавно статью про альтернативу Promises/Deferred.
При этом многопоточное программирование в традиционном (не CSP) стиле меня тоже пугает и я его вполне успешно избегал всю жизнь.
Так вот, я могу ответственно заявить, что писать многопоточный код в стиле CSP (например на Go или Limbo) действительно на порядок проще, чем асинхронный! И callback-и действительно полный отстой по сравнению с CSP. Так что ничего удивительного в решении TJ Holowaychuk нет.
Лично меня асинхронное программирование не пугает — я пишу асинхронный код уже более 10-ти лет (в основном на Perl, но это не важно), делал свой event loop (не от хорошей жизни, просто в 2004-ом не было готовых библиотек для perl на epoll), написал кучку модулей (для асинхронного I/O, асинхронной работы с MySQL, etc.) на CPAN, недавно статью про альтернативу Promises/Deferred.
При этом многопоточное программирование в традиционном (не CSP) стиле меня тоже пугает и я его вполне успешно избегал всю жизнь.
Так вот, я могу ответственно заявить, что писать многопоточный код в стиле CSP (например на Go или Limbo) действительно на порядок проще, чем асинхронный! И callback-и действительно полный отстой по сравнению с CSP. Так что ничего удивительного в решении TJ Holowaychuk нет.
Дело не в том, хороши коллбэки в ноде или нет. Я согласен, что в ноде подход к обработке ошибок сделан неплохо, да и стандарт для Promises появился во многом благодаря активному использованию коллбэков в ноде. Но суть в том, что как бы ни были хороши коллбэки в ноде, писать обычный синхронный код без коллбэков намного проще.
Проблема была в том, что такой код раньше был (по сравнению с асинхронным) либо очень медленным, либо очень сложным (на традиционных нитях). Но стиль CSP это изменил, и теперь можно писать (например, на Go) синхронный, и при этом очень быстрый и простой код.
Проблема была в том, что такой код раньше был (по сравнению с асинхронным) либо очень медленным, либо очень сложным (на традиционных нитях). Но стиль CSP это изменил, и теперь можно писать (например, на Go) синхронный, и при этом очень быстрый и простой код.
Коллбэки не composable. точка.
А где сейчас используется Go?
Чтобы писать без колбэков вовсе не обязательно отказываться от ноды :-)
Бег Головайчука в ноде на одну проблему станет меньше. Позор предателям! Слава джаваскрипту!
Бендер, ты же должен был говорить «Смерть человекам!». Что с тобой стало? Опять ты с tessel баловался.
Колбекам слава!
Это видимо тренд, то основной разработчик скала говорит что скала гавно, то разработчик nodejs. А люди в тоже время продолжают использовать эти технологии и вполне себе довольны.
«Люди довольны» — с одной стороны не сильно аргумент, т.к. до сих пор живут люди, довольные Delphi и Borland C Builder :)
Все языки/платформы/фреймворки — это инструменты, имеющие свою область применения, а не самоцель. There's no silver bullet. А разработчики все же люди, у них изменяются решаемые задачи, изменяются самые технологии, и в какой-то момент они упираются в те самые рамки области применения для своего инструмента, и многие — кто с огорчением, кто с радостью — берут в руки другой инструмент. Это нормально, так работает прогресс :)
Все языки/платформы/фреймворки — это инструменты, имеющие свою область применения, а не самоцель. There's no silver bullet. А разработчики все же люди, у них изменяются решаемые задачи, изменяются самые технологии, и в какой-то момент они упираются в те самые рамки области применения для своего инструмента, и многие — кто с огорчением, кто с радостью — берут в руки другой инструмент. Это нормально, так работает прогресс :)
Людям интересны разные этапы. Одним — творить всё новое, менять старое, и менять даже своё вчерашнее, потому что он ушел уже дальше. Когда язык становится популярным и используемым, то он само собой начинает костенеть, возникают традиции, правила. В такие моменты создатели и чувствуют желание уйти, и ищут для этого причины.Сам язык тут не при чем.
1) Ну как основной. Коммитил больше всех на гитхаб в течение одного года, но это не значит, что был лидером, самым ценным и т.п. Он был одним из единичных «внешних» разрабов скалы.
2) Основные его претензии были не столько к языку, а к коллекциям. Грозился сделать свое. Проблемы реальные, но критичность их натянутая.
Пока от него было много крику, про зачатки новых коллекций не слышал еще.
2) Основные его претензии были не столько к языку, а к коллекциям. Грозился сделать свое. Проблемы реальные, но критичность их натянутая.
Пока от него было много крику, про зачатки новых коллекций не слышал еще.
Не год, а пять лет.
Не к коллекциям, а к компилятору, который настолько излишне усложнен, что нужно быть Эйнштейном от программирования, чтобы что-то там править. Хотя у него и были претензии к коллекциям, а именно что мутабельные и иммутабельные классы наследуются от одних родителей, все же основной посыл состоял в том, что все написано в угоду временной производительности и совместимости, нежели понятности и изменяемости, а виноват во всем компилятор.
Не к коллекциям, а к компилятору, который настолько излишне усложнен, что нужно быть Эйнштейном от программирования, чтобы что-то там править. Хотя у него и были претензии к коллекциям, а именно что мутабельные и иммутабельные классы наследуются от одних родителей, все же основной посыл состоял в том, что все написано в угоду временной производительности и совместимости, нежели понятности и изменяемости, а виноват во всем компилятор.
Мне кажется, Node.JS в конечном счете зайдет в тупик, потому что это единственная платформа, которая поддерживает Javascript на сервере. Я бы с удовольствием посмотрел бы на реализации Node.JS от Mozilla с их движками или даже от Microsoft (при условии, если они будут Open Source'ить их).
Не так давно я читал статью Domenic Tarr о том, чего можно достичь с Open Source. Да, человек идеалист, хочет мира во всем мире и текст наивен, однако в статье есть замечательные слова:
Не так давно я читал статью Domenic Tarr о том, чего можно достичь с Open Source. Да, человек идеалист, хочет мира во всем мире и текст наивен, однако в статье есть замечательные слова:
Fortunately, it’s possible for these monkeys to work in teams. In fact, it’s really quite simple, because they actually work better if they are just let to themselves and given only the most gentle direction. If you try and dictate what they do they’ll only resent you. All that is needed is the right sort of guide to encourage them to communicate in the most effective way, and make it more rewarding for them to work together than to work on their own.Я считаю, что благодаря TJ, Node.js, npm это действительно стало так. Эти вещи взорвали Open Source и подстегнули его развитие, на мой взгляд не меньше, чем Линус. И это самая замечательная вещь, которая получилась у Node.JS. Объединять людей со всего земного шара для того, чтобы делать крутые штуки.
This is essentially what git, github and npm accomplish.
ASP.NET Owin «Helios» как раз неплохое развитие идеи Node.JS, только с преимуществами типизированного языка.
Если не смотреть на монстроузный комбайн под названием ASP.NET Identity 2 — то очень лаконичный и простой в изучении фреймворк получился.
Если не смотреть на монстроузный комбайн под названием ASP.NET Identity 2 — то очень лаконичный и простой в изучении фреймворк получился.
так не единственная же — как минимум есть vet.x
Кстати говоря, статья с критикой Go, упомянутая в конце перевода, очень интересная.
Статья неплохая, но общее впечатление от неё «ну почему же Go не Haskell?!». В недавнем выступлении Роб Пайк по сути объяснил «почему Go не Haskell» — они осознанно создавали не экспериментальный язык, а максимально обычный и привычный для программистов C++ и Python язык, старались отобрать в язык лучшие концепции из широко известных и популярных языков а не экспериментировать с новыми концепциями. Всё это для того, чтобы добавить к получившемуся простому и привычному языку всего одну концепцию: параллелизм на CSP.
Дело в том, что они раньше уже выпускали действительно революционные и экспериментальные вещи (Plan9, Inferno, Limbo) но они «не взлетели». Так что Go — это попытка двигаться в том же (Plan9/Inferno) направлении, но на этот раз ма-а-аленькими шажками, приучая людей к хорошему постепенно.
Конкретнее по пунктам той статьи:
Дело в том, что они раньше уже выпускали действительно революционные и экспериментальные вещи (Plan9, Inferno, Limbo) но они «не взлетели». Так что Go — это попытка двигаться в том же (Plan9/Inferno) направлении, но на этот раз ма-а-аленькими шажками, приучая людей к хорошему постепенно.
Конкретнее по пунктам той статьи:
- я где-то недавно читал, что Generic-и в Go могут добавить, просто пока не определились как это лучше сделать;
- перегрузка операторов — нет, спасибо, видя + я хочу знать что это сложение без беготни по исходникам всех операндов этой операции чтобы выяснить, что на самом деле будет происходить при выполнении этой операции;
- по поводу отсутствия в Go продвинутой системы типов Haskell уже сказал выше;
- что касается Immutability, то это дело хорошее, но при использовании CSP проблема «bug caused by mutating a data structure in one place while using it in another» решается иначе: структура данных принадлежит одной конкретной нити/горутине, и все остальные нити работают с этими данными через каналы — таким образом весь код, который using и который mutating эти данные находится in one place;
- Pattern Matching тоже штука хорошая, но аргументация та же, что и для продвинутых типов Haskell;
- Embedded Programming — Go для этого не подходит, его разрабатывали для других задач, ничего плохого в том, что у языка есть своя область применения и он не годится для других областей нет (впрочем, автор этой статьи тоже так считает).
switch case конструкция бесит своей ограниченностью начиная с С, думаю, что Pattern Matching — должен пойти в народ легко, жаль, что не сделали
* Насчет перегрузки операторов — что изменится, если я напишу (Python)
вместо
Оба варианта выглядят как сложение, хотя внутри умножение.
* Насчёт системы типов — всё-таки приятнее, когда типизация продуманная и РАБОТАЕТ, а не добавлена «для галочки» и страдает дырявостью.
* Pattern matching — я лично не понимаю что вообще можно иметь против него — штука то крайне удобная (что в Erlang, что в Rust). Сложным бы я его тоже не назвал.
def add(self, other):
return self.val * other.val
o1.add(o2)
вместо
def __add__(self, other):
return self.val * other.val
o1 + o2
Оба варианта выглядят как сложение, хотя внутри умножение.
* Насчёт системы типов — всё-таки приятнее, когда типизация продуманная и РАБОТАЕТ, а не добавлена «для галочки» и страдает дырявостью.
* Pattern matching — я лично не понимаю что вообще можно иметь против него — штука то крайне удобная (что в Erlang, что в Rust). Сложным бы я его тоже не назвал.
Предлагаю немного другой взгляд на вопрос
Головайчук много сделал для nodejs, это факт, express стал де-факто стандартом, все что ни делаеться так или иначе совместимо, расширяет, дополняет или копирует функционал express-а. Который в свою очередь копирует Синатру. Hо это Бог с ним, кто-то же должен был портировать хороший рестфул фреймворк на js, ой, как это express не restfull? тоесть хорошего рестфул фреймворка под js всеравно нет?! давайте хотябы споем хвалебную песню тому как написан express — он поддерживает прослойки (middleware) от connect (который написан тем же автором); он модульный, то есть состоит из кучи маленьких модулей, некоторые из которых состоят из 1 (одной) функции github.com/component/escape-html github.com/visionmedia/node-methods. Это конечно же сразу дает представление о том откуда у него 550 npm пакетов в репозитарии
PS всем спасибо за внимание и понимание — наболело
Головайчук много сделал для nodejs, это факт, express стал де-факто стандартом, все что ни делаеться так или иначе совместимо, расширяет, дополняет или копирует функционал express-а. Который в свою очередь копирует Синатру. Hо это Бог с ним, кто-то же должен был портировать хороший рестфул фреймворк на js, ой, как это express не restfull? тоесть хорошего рестфул фреймворка под js всеравно нет?! давайте хотябы споем хвалебную песню тому как написан express — он поддерживает прослойки (middleware) от connect (который написан тем же автором); он модульный, то есть состоит из кучи маленьких модулей, некоторые из которых состоят из 1 (одной) функции github.com/component/escape-html github.com/visionmedia/node-methods. Это конечно же сразу дает представление о том откуда у него 550 npm пакетов в репозитарии
PS всем спасибо за внимание и понимание — наболело
Sails.js вполне себе RESTfull фрэймворк.
loopback тоже :)
habrahabr.ru/post/222259/
habrahabr.ru/post/222259/
TJ Holowaychuk называет ультра-модульность (то есть ситуацию, когда есть множество мелких модулей, каждый из которых хорошо делает что-то одно) достоинством сообщества, сложившегося вокруг Node.js.
Пожалуй, я должен с ним согласиться, так как не раз видел, как небольшой модуль, созданный для интеграции в одинкакой-то более крупный проект, начинает со временем использоваться и в других проектах, подчас ещё более крупных и (или) ещё более популярных — то есть, наличествуя в готовом законченном виде, он экономит время других программистов.
Так случилось, что последний раз я увидал это на своём собственном примере:npm-пакет uue, к началу нынешнего июня созданный мною вообще-то для декодирования UUE-кодов из Фидонета (например, именно им декодируется SVG-файл во браузере гипертекстового векторного Фидонета), в том же месяце стал использоваться и пакетом mailparser (предназначенным для анализа не фидопочты, а интернетовского e-mail, в котором также ведь могут повстречаться UUE-коды) — так что в один прекрасный день я увидел, что его скачивают более трёх тысяч раз в месяц:
![[статистика]](https://habrastorage.org/getpro/habr/comment_images/7c0/499/db0/7c0499db0d2a6f121fc755d9559b1032.png)
![[гистограмма]](https://habrastorage.org/getpro/habr/post_images/868/ece/ee6/868eceee623da3c1bacd792decf19e67.png)
Иными словами, сотни готовыхnpm-пакетов — это клёво, и это превеликая польза сообществу.
Пожалуй, я должен с ним согласиться, так как не раз видел, как небольшой модуль, созданный для интеграции в один
Так случилось, что последний раз я увидал это на своём собственном примере:
Иными словами, сотни готовых
Благодарю за внеочередной пиар гипертекстового векторного Фидонета :)
У модульной архитектуры определенно есть достоинства, которые никто не отрицает. тем не менее сейчас npm репозиторий забит мусором, нет не плохими пакетами, а именно мусором, кто-то, когдато сделал пакет с именем name и закомитил, навсегда забыв о нем, а другие люди поддержавшие идею вынуждены называть свои пакеты name-1 name_1 и my_name. Получаеться что не зная зарание что ищешь, там очень сложно что либо найти. Выход из этой ситуации нашел bower который прекрасно кушает ссылку на github или maven который кушает имя пакета (имя сайта в обратном порядке)
теперь давайте отвлечемся от npm репозитория и посмотрим в package.json
это из моего текущего проекта, в нем 8 пакетов о которых я бы предпочел не думать, совсем, от слова вообще. Меня очень привлекает возможность заменить эти пакеты на другие, но других нет! нет ни вменяемого репозтитария прослоек для express, ни поиска, ни смысла их искать — проще сделать пулл реквест в существующие, так как они выпускают новые версии (патчи) раз в неделю, не реже.
И у вас, кстати, не одна функция а uue пакете
У модульной архитектуры определенно есть достоинства, которые никто не отрицает. тем не менее сейчас npm репозиторий забит мусором, нет не плохими пакетами, а именно мусором, кто-то, когдато сделал пакет с именем name и закомитил, навсегда забыв о нем, а другие люди поддержавшие идею вынуждены называть свои пакеты name-1 name_1 и my_name. Получаеться что не зная зарание что ищешь, там очень сложно что либо найти. Выход из этой ситуации нашел bower который прекрасно кушает ссылку на github или maven который кушает имя пакета (имя сайта в обратном порядке)
теперь давайте отвлечемся от npm репозитория и посмотрим в package.json
{
"express": "4.4.5",
"express-session": "1.6.1",
"serve-static": "1.3.0",
"compression": "1.0.8",
"body-parser": "1.4.3",
"morgan": "1.1.1",
"static-favicon": "1.0.2",
"cookie-parser" : "1.3.2",
"errorhandler": "1.1.1"
}это из моего текущего проекта, в нем 8 пакетов о которых я бы предпочел не думать, совсем, от слова вообще. Меня очень привлекает возможность заменить эти пакеты на другие, но других нет! нет ни вменяемого репозтитария прослоек для express, ни поиска, ни смысла их искать — проще сделать пулл реквест в существующие, так как они выпускают новые версии (патчи) раз в неделю, не реже.
И у вас, кстати, не одна функция а uue пакете
Воистину. Мне как-то понадобилась пара асинхронных функций: extend/defaults и each для объектов. Если вторая и является чисто оберткой классического each из пакета async, то extend — уже чуть посложнее. Я сделал эти модули сначала как часть библиотеки в своем проекте, а после решил выложить на npm. На пакет выходит примерно по 500 скачиваний в месяц — мелочь, а приятно.
скажите пожалуйста название пакета, очень хочеться посмотреть на асинхронный extend
Я думаю здесь нет тайны: https://github.com/radist2s/async-extend-defaults
Предлагаю теорию заговора: Гугл несколько лет силами своих разработчиков развивал виртуальный аккаунт TJ Holowaychuk, чтобы набрать авторитет среди разработчиков Node, а потом авторитетно заявить, что нужно валить на Go.
Эта теория имеет право на жизнь хотя бы из-за того, что о TJ Holowaychuk почти ничего не известно, он нигде не выступал и его никто не видел. Вот основная информация, которая о нем известна.
Переход на Go это дело времени, гугл другими способами этого добивается. А вот если бы ваш план существовал, TJ Holowaychuk бы сделал цикл статей про Google+
Все свелось в итоге к недостаткам яваскрипта, странно, что это заняло у него так много времени.
Лично с node js сбежал на Meteor, хотя пока еще нет 1.0 но все равно очень приятна работать
Марк Лехман (автор libev) утверждает, что ошибки и кривизна так или иначе заложены в самих механизмах асинхронной обработки (select, epoll, kqueue) на уровне ядер большинства современных ОС, поэтому нельзя так уж однозначно винить в кривости и убогости ту или иную надстройку над этими механизмами (будь то node.js или стандартная либа Go)…
Кто бы что не говорил о node.js — но в нем имеется одно для нас важное преимущество: один язык и один фреймворк для клиента и сервера. Скорость разработки приложения увеличилась у нас в разы, когда бизнес логика, хэлперы, сервисы и прочее используются по обе стороны.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
TJ Holowaychuk: Прощай Node.js