Модель обслуживания выбрана спорная. Легковесные потоки по всем параметрам предпочтительней. И работают не хуже, и многопроцессорность можно сделать, и код получается читабельным, а не лапша из коллбэков.
ЯП спорный. Сам по себе JS мне очень нравится, но наслоения со времён 90-х, невнятная стандартная библиотека, это всё делает его очень спорным выбором.
Что реально мне понравилось — возможность использовать общий код в богатом клиенте в браузере и на сервере. Но сколько этого общего кода? Много ли? Мне кажется, что нет. Навскидку приходит в голову только валидация. Да рендеринг на сервере страницы перед тем, как её отдать, в AJAX приложении, аналогичный рендерингу на клиенте, но это, вроде, практически нигде пока не реализовано. Валидация, в принципе, делается кодогенерацией из декларативного описания на сервере для любого ЯП, если хочется убрать тут дубликацию.
Ещё мне понравилось коммьюнити. Очень интересные миниатюрные библиотеки, отличное качество документации. Но это, наверное, не заслуга языка. Поэтому пока интересует исключительно технические плюсы.
Здравствуйте, vsb, Вы писали:
vsb>Модель обслуживания выбрана спорная. Легковесные потоки по всем параметрам предпочтительней. И работают не хуже, и многопроцессорность можно сделать, и код получается читабельным, а не лапша из коллбэков. vsb>ЯП спорный. Сам по себе JS мне очень нравится, но наслоения со времён 90-х, невнятная стандартная библиотека, это всё делает его очень спорным выбором.
Спорить можно всегда и с чем угодно, эт дело такое.
Есть простой факт:
Нода начиналась как проект-эксперимент и выросла в полноценную серверную платформу с богатой инфраструктурой. Поэтому не уверен что спору по поводу модели/языка будут … эффективными.
vsb>но наслоения со времён 90-х, невнятная стандартная библиотека
Могли бы вы раскрыть эту мысль. О каких наслоениях идет речь? И о какой "стандартной библиотеке"? По факту в джавасрипте ее нет. А нода привнесла очень много своих "стандартных библиотек" + нестандартные.
vsb>Ещё мне понравилось коммьюнити. Очень интересные миниатюрные библиотеки, отличное качество документации. Но это, наверное, не заслуга языка.
Почему же, вполне может быть заслуга языка, сообщество ноды сформировалось с фронт-эндшиков (в обоих смыслах: "браузерные" разработчики и разработчики серверных фронт-этдов), а в той сфере много людей с шилом в одном месте
vsb>Поэтому пока интересует исключительно технические плюсы.
Из технических моментов:
Однопоточность и колбеки убирают/уменьшают вероятность дедлоков.
Модель ноды (1 поток — 1 процесс) упрощает администирование. В случае утечки ресурсов с легковесными потоками не всегда может получится удалить "зависшие" и освободить ресурсы. Поэтому реально выход один — убить весь процесс, который у вас занимал несколько, а скорее всего все, ядра. В случае с нодой вы убиваете процесс который завис на одном ядре, а процессы на других ядрах у вас продолжают работать. То есть масштабирование у вас кошерное горизонтальное, нет разницы запускаетесь вы на супер-компьютере или на десятке микроинстансов.
Довольно нетребовательный к ресурсам для простых задач. Приложение на той же джаве в реальном мире будет рассчитывать на хотя бы 1-2 Гб
"Один язык". Упрощается подбор команды, так как язык, подходы, иногда библиотеки одни и те же. А в случае если используется МонгоДБ, то и язык БД совпадает с языком сервера и клиентской части.
Здравствуйте, vsb, Вы писали:
vsb>Модель обслуживания выбрана спорная. Легковесные потоки по всем параметрам предпочтительней. И работают не хуже, и многопроцессорность можно сделать, и код
А у каких библиотек, платформ есть легковесные потоки, не считя erlang?
Здравствуйте, Sharov, Вы писали:
S>А у каких библиотек, платформ есть легковесные потоки, не считя erlang?
В Rust вроде встроены зелёные потоки. А так, наборы "сделай сам" в виде coroutines/fibers есть практически для всех языков — C++, D, Go, Python.
Кстати, для Python есть готовая библиотека, делает monkey-patch стандартных сокетов и т.п.:
"""Spawn multiple workers and wait for them to complete"""from __future__ import print_function
urls = ['http://www.google.com', 'http://www.yandex.ru', 'http://www.python.org']
import gevent
from gevent import monkey
# patches stdlib (including socket and ssl modules) to cooperate with other greenlets
monkey.patch_all()
import urllib2
def print_head(url):
print('Starting %s' % url)
data = urllib2.urlopen(url).read()
print('%s: %s bytes: %r' % (url, len(data), data[:50]))
jobs = [gevent.spawn(print_head, url) for url in urls]
gevent.wait(jobs)
Наверняка, многим серьезным веб-программистом преходилось испытать неприязнь, когда они узнавали, что чтобы выложить веб-сайт надо еще изучать пхп. Все соглашаются (и в интернете я тоже читал) что это очень, очень плохой язык. Это на самом деле глупость и когда я прочитал я долго не мог поверить ходил спрашивал и оказалось не зря. Тепер ьвеб-сайты можно писать на самом популярном в мире языке джаваскрипте. Это революционный переворот и он происходит прямо на наших глазах. Что это значит для нас, ребята? Что мы уже знаем, как писать сйты по сути. Я был шокирован, как там все организовано, но похоже они все вопросы продумали с самого начала и договорились что это будет очень востребованный проект.Более того, умные C++ перцы из гугл которые по утрам ездят в автобусах набитых баскетбольными мечами уже работают над тем, чтобы джаваскрипт работал быстрее С++, потому что он комплируется сразу в результат, минуя стадию вычисления! Вы наверняка заметили это по тому, что gmail.com открывается за 5 секунд, а не 20 как это было в до-интернетную эпоху, может хотя бы самые древние. Его кстати тоже делали в гугл. Что это если не порыв я не знаю. То есть, если вы напишете свой сайт на nodejs, он автоматически будет бытсрым и будет масштабироватсья (обрабатывать столько клиентов, сколько пришло, это настоящая проблема в пхп была и некто не знал как с ней быть). Например, данные между разными запросами не изолированны и вообще можно использовать одни и те же глобальные переменные для всех клиентов и экономить память. В том же пхп это в принципе не возмонжно и засчет этого у ноды такая гиганская производительность. Там даже продумано если вы будете работать с другом или кто-то допустим, то я зык специально за счет очень удобной типизации можно писать так что вы не будете знать что и как вам передает ваш друг. Это очень удобно потому что позволяет меняь програму в одном месте и вообще не парится о том же друге что там у него програма все равно запустится.Только представьте! Любой кусок кода можно насать один раз. Например, функцию, переворачивающущю строку, и вызывать ее из браузера или включать музыку с телефона. Особенно если заморочиться совместимостью северного кода и особеностей разных браузеров. Также они добавили возможность создавать внутри функции другие функции и это очень круто, но я пока не понял как потом вернуться в первую функцию. Но самое главное, что над нодой сейчас работает туча народу просто, они переписывают все что было до них написано на ноду и у них получается лучше потому что они сразу заточились на производительность и чтобы было лучше а так же просто использовать. Например нужно сходить в базу данных создал проект на гитхабе сразу набежали форкнули завтра только пуллреквесты принять и можно заливать в продакшн на свой ноутбук. Сообщество очень дружелюбное, если кому-то удается сделать что-то работающее на ноде его обязательно хвалят и подбадревают потому что это правда успех. Я пока не понял как допустим считать файл но говорят эт из-за безопасности,там все очень надежно, ведь если к тебе вдруг идет миллион клиентов и вы облажаетесь в 10% случаев ты облажаешься перед 100 000 человек. Поэтому например если где-то произошла ошибка лучше сразу аккуратненько завершиться чем пазориться перед остальными, тем более если перезапустить сервер то там и память лишняя освободится и бегать начнет пошустрее, да и перезапускается он очнь бытсро. Иногда бывает быстрее перезапустить сервер чем дождаться окончания сборки мусора. Ктому же nodejs так оптимизирован что никогда не займет больше одного ядра а это значит что базу данных например можно поставить на тот же ноут на другое ядро для экономии ресурсов и надежности (иметь что-то на той же машине всегда надежнее, много ли что, все у кого есть дома интернет вы это итак знаете) и все будет быстро бегать и даже можно во что-нибудь пошпилить или дальше форум по nodejs почитать но тогда надо побольше ядер купить. Но в серверы как раз много ядер и ставят и как видите nodejs прекрасно справляется с этой задачей. Правда что бы писать на ноде нужно купить макбук потому что все примеры в интернете написаны на мак буке но я думаю если выделаете высокопроизводительный веб-сервис, вам всеравно прийдется пройти раунд финансирования у родителей чтобы потом его запускать. Вообщем я в восторге хотя немного напрягает что гдето должны быть проблемы но я пока не понял не столкнулся ая уже очнь долго с ней разбираюсь и пока не понял.
Здравствуйте, LuciferSpb, Вы писали:
LS>перцы из гугл которые по утрам ездят в автобусах набитых баскетбольными мечами уже LS>(с) http://tonsky.livejournal.com/266519.html Никита Прокопов (tonsky)
Как можно серьезно воспринимать персонажа, который очевидно неграмотен?
Как относится к неграмотному персонажу, который не моргнув глазом, цитирует другого неграмотного?
Здравствуйте, silverwolf, Вы писали:
vsb>>ЯП спорный. Сам по себе JS мне очень нравится, но наслоения со времён 90-х, невнятная стандартная библиотека, это всё делает его очень спорным выбором. S>Спорить можно всегда и с чем угодно, эт дело такое. S>Есть простой факт: S>Нода начиналась как проект-эксперимент и выросла в полноценную серверную платформу с богатой инфраструктурой. Поэтому не уверен что спору по поводу модели/языка будут … эффективными.
Это чисто эстетическое. Писать можно на чём угодно, но красивые ортогональные решения приятней и подсознательно имеют большой вес при выборе.
vsb>>но наслоения со времён 90-х, невнятная стандартная библиотека S>Могли бы вы раскрыть эту мысль. О каких наслоениях идет речь? И о какой "стандартной библиотеке"? По факту в джавасрипте ее нет. А нода привнесла очень много своих "стандартных библиотек" + нестандартные.
Всякие ===, undefined, false, null, переменные, создаваемые по умолчанию, многословный синтаксис для анонимных функций, какие-то неявные нелогичные преобразования типов, это по языку.
Стандартная библиотека в JS есть, но она отстойная. Массивы, которые одновременно хеш-таблицы, причём неизвестно как реализованные, без контроля хеш-функции, нет связных списков, нет нормального ООП-апи, нет нормального ФП-апи, какой-то студент накидал функций случайным образом, половину слизав с Java 1.0, половину придумав, чтобы зачёт получить и забыть как страшный сон.
Нестандартные библиотеки для основы языка это плохо. С этим можно жить, но это плохо. Потому что на них основаны все остальные библиотеки. И при их использовании будет боль. Хороший пример — 100500 классов строк в С++, потому что нормального класса в своё время не было (и, я так понял, до сих пор нет).
Здравствуйте, LuciferSpb, Вы писали:
LS>Здравствуйте, Stanislaw K, Вы писали: LS>>>перцы из гугл которые по утрам ездят в автобусах набитых баскетбольными мечами уже LS>выделенное — единственное, что глаз резануло?
Исё началось тут: "Наверняка, многим серьезным веб-программистом преходилось испытать неприязнь", а к "мечам" уже накатило что то.
LS>>>(с) http://tonsky.livejournal.com/266519.html Никита Прокопов (tonsky) SK>>Как можно серьезно воспринимать персонажа, который очевидно неграмотен? LS>весь текст — очевидный стеб.
ты прервал.
Здравствуйте, Sharov, Вы писали:
EP>>Кстати, для Python есть готовая библиотека, делает monkey-patch стандартных сокетов и т.п.: S>Питон не очень удачный пример, поскольку он изначально сильно однопоточный.
Так JS по дизайну _полностью_ однопоточный.
В Python, для примера, в PyPy или JPython используются реальные параллельные потоки без всякого GIL.
Здравствуйте, Sharov, Вы писали:
EP>> Python. EP>>Кстати, для Python есть готовая библиотека, делает monkey-patch стандартных сокетов и т.п.: S>Питон не очень удачный пример, поскольку он изначально сильно однопоточный.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А node.js разве не однопоточный?
Я к тому, что Вы поставил питон в один ряд с языками или платформами, где есть встроенная поддержка (легковесных) потоков.
Питон там не очень к месту, хотя есть реализации питона (см. выше комментарий), где он уже обладает
вполне себе взрослой многопоточностью.
Здравствуйте, Sharov, Вы писали:
EP>>А node.js разве не однопоточный? S>Я к тому, что Вы поставил питон в один ряд с языками или платформами, где есть встроенная поддержка (легковесных) потоков.
gevent как раз предоставляет легковесные потоки.
Да и кстати, в node.js ведь нет встроенных легковесных потоков, так? Автоматы ведь вручную по callback'ам размазываются.
Здравствуйте, silverwolf, Вы писали:
S>Из технических моментов: S>
S> Однопоточность и колбеки убирают/уменьшают вероятность дедлоков. S>
Это заблуждение. Дедлоки происходят от двух вещей — многозадачность и разделяемые ресурсы. Хотя поток один, асинхронных цепочек может быть несколько.
Итого — кооперативная многозадчность на марше. Теперь все цепочки работают с одним разделяемым ресурсом — опаньки !
Как и с любой многозадачности и разделяемыми ресурсами, происходят гонки. Решаем эти гонки и получаем асинхронные примитивы синхронизации.
Применяем...
...две асинхронных нити, 1 и 2, захватывают 2 ресурса, А и Б, но в разной последовательности. Нить 1 захватывает А и пытается захватить Б, а нить 2 захватывает Б и пытается захватить А.
Опаньки — дедлок асинхронного кода.
Итого — асинхронщина это АДъ в отладке. Нужно устранять разделяемые ресурсы, даже если это обойдётся в 100гб адресного пространства
Здравствуйте, vsb, Вы писали:
vsb>Стандартная библиотека в JS есть, но она отстойная. Массивы, которые одновременно хеш-таблицы, причём неизвестно как реализованные, без контроля хеш-функции, нет связных списков, нет нормального ООП-апи, нет нормального ФП-апи, какой-то студент накидал функций случайным образом, половину слизав с Java 1.0, половину придумав, чтобы зачёт получить и забыть как страшный сон.
ООП и ФП гораздо лучше чем в C# и Java и даже С++. В новом стандарте станет вообще недостижимо лучше.
vsb>Нестандартные библиотеки для основы языка это плохо. С этим можно жить, но это плохо. Потому что на них основаны все остальные библиотеки. И при их использовании будет боль. Хороший пример — 100500 классов строк в С++, потому что нормального класса в своё время не было (и, я так понял, до сих пор нет).
С++ как язык слишком сложен. Пока люди разберуется, что к чему, то уже прирастают к своим велосипедам (классам строк и смартпоинтерам) и жить без них не могут, тащут во все проекты.
В джаваскрипте код в целом пишется довольно быстро, набрал и всё палит, т.е. за свой код мало кто держится. Есть несколько основных стеков, на которых все построено и унутре стека все довольно гладко. Выбор библиотек довольно большой, с одной тсороны хорошо, с другой стороны может понадобиться время на этот выбор.
Есть несколько правил в JS — нужно, в порядке убывания важности
1 избегать лишних связей и обрезать оные по возможности.
2 держать код в виде пригодном для рефакторинга
3 избегать лишних сущностей и обрезать по возможности.
4 соблюдать соглашения, давать качественные имена
5 следить за локальностью
Если все 5 кажутся трудными в исполнении, то самый минимум это 1. Без него вообде никуда. Если непонятно как этого добиться — лучше вообще уйти от динамических языков.
п2 он немного парадоксальный. JS сам по себе довольно гибкий язык. Но как сказал Ленин, если слишком сильно взять влево, окажешься справа. Слишком много гибкости даёт хрупкость.
п5 он тоже не совсем очевидный. Очень просто на JS наваять такое решение, что придется вникать во все модули и либы, что бы понять локальную строчку — т.е. фактически возврат во времена плохого С++ или даже ассемблера — в каждой строчке надо думать о том, что может произойти в другой части системы.
Здравствуйте, Ikemefula, Вы писали:
vsb>>Стандартная библиотека в JS есть, но она отстойная. Массивы, которые одновременно хеш-таблицы, причём неизвестно как реализованные, без контроля хеш-функции, нет связных списков, нет нормального ООП-апи, нет нормального ФП-апи, какой-то студент накидал функций случайным образом, половину слизав с Java 1.0, половину придумав, чтобы зачёт получить и забыть как страшный сон.
I>ООП и ФП гораздо лучше чем в C# и Java и даже С++. В новом стандарте станет вообще недостижимо лучше.
Чем лучше? Что будет в новом стандарте? Когда его будут поддерживать все браузеры?
К ФП у меня претензии — нет нормального синтаксиса для анонимных однострочных функций, писать function (x, y) { return x + y; } это очень много в сравнение с другими языками. Нет нормальной библиотеки коллекций в функциональном стиле.
Про ООП странно слышать. Я в JS вообще ООП нормальный не вижу, вижу некую симуляцию, как в каком-нибудь перле. Вроде внешне всё как в ООП, но внутри костылях и хеш-таблицы. В Java с этим по-моему лучше.
vsb>>Нестандартные библиотеки для основы языка это плохо. С этим можно жить, но это плохо. Потому что на них основаны все остальные библиотеки. И при их использовании будет боль. Хороший пример — 100500 классов строк в С++, потому что нормального класса в своё время не было (и, я так понял, до сих пор нет).
I>В джаваскрипте код в целом пишется довольно быстро, набрал и всё палит, т.е. за свой код мало кто держится. Есть несколько основных стеков, на которых все построено и унутре стека все довольно гладко. Выбор библиотек довольно большой, с одной тсороны хорошо, с другой стороны может понадобиться время на этот выбор.
Какие стеки есть?
I>Есть несколько правил в JS — нужно, в порядке убывания важности I>1 избегать лишних связей и обрезать оные по возможности. I>2 держать код в виде пригодном для рефакторинга I>3 избегать лишних сущностей и обрезать по возможности. I>4 соблюдать соглашения, давать качественные имена I>5 следить за локальностью
Правила хорошего тона для любого языка на мой взгляд.
Здравствуйте, Ikemefula, Вы писали:
I>Как и с любой многозадачности и разделяемыми ресурсами, происходят гонки. Решаем эти гонки и получаем асинхронные примитивы синхронизации.
Да, но в дополнение есть мощный и дешёвый примитив синхронизации, которого нет в вытесняющей многозадачности: отдать управление после совершения всей транзакции.
Здравствуйте, vsb, Вы писали:
I>>ООП и ФП гораздо лучше чем в C# и Java и даже С++. В новом стандарте станет вообще недостижимо лучше.
vsb>Чем лучше? Что будет в новом стандарте? Когда его будут поддерживать все браузеры?
Лямбды, короутины, классы, модули, прокси. Не в курсе.
vsb>К ФП у меня претензии — нет нормального синтаксиса для анонимных однострочных функций, писать function (x, y) { return x + y; } это очень много в сравнение с другими языками. Нет нормальной библиотеки коллекций в функциональном стиле.
А что ты хочешь от этой нормальной библиотеки функций ?
vsb>Про ООП странно слышать. Я в JS вообще ООП нормальный не вижу, вижу некую симуляцию, как в каком-нибудь перле. Вроде внешне всё как в ООП, но внутри костылях и хеш-таблицы. В Java с этим по-моему лучше.
Там прототипное ООП, в ём реализуемо всё что тебе надо.
I>>В джаваскрипте код в целом пишется довольно быстро, набрал и всё палит, т.е. за свой код мало кто держится. Есть несколько основных стеков, на которых все построено и унутре стека все довольно гладко. Выбор библиотек довольно большой, с одной тсороны хорошо, с другой стороны может понадобиться время на этот выбор.
vsb>Какие стеки есть?
node.js, sencha, jQuery
I>>Есть несколько правил в JS — нужно, в порядке убывания важности I>>1 избегать лишних связей и обрезать оные по возможности. I>>2 держать код в виде пригодном для рефакторинга I>>3 избегать лишних сущностей и обрезать по возможности. I>>4 соблюдать соглашения, давать качественные имена I>>5 следить за локальностью
vsb>Правила хорошего тона для любого языка на мой взгляд.
Приоритеты разные. Скажем, п2, п4 и п5 для C# или джавы вообще можно выкинуть
