Доступен (https://iojs.org/en/releases.html) выпуск серверной JavaScript-платформы io.js 2.0 (https://iojs.org), которая может быть использована как для серверного сопровождения работы Web-приложений, так и для создания обычных клиентских и серверных сетевых программ. Проект io.js является ответвлением от кодовой базы Node.js. С точки зрения организации процесса разработки, io.js примечателен привлечением для координации развития проекта управляющего совета (https://github.com/iojs/io.js/blob/v1.x/GOVERNANCE.md), сформированного из активных представителей сообщества и не зависящего от отдельных компаний. Io.js также отличается более коротким циклом разработки новых выпусков, что позволяет оперативно доводить новшества до пользователей.
Мотивом создания форка было (http://www.opennet.me/opennews/art.shtml?num=41144) недовольство политикой компании Joyent, курирующей разработку проекта Node.js, проявлявшейся в игнорировании мнения сообщества и затягивания процесса разработки новых выпусков. После создания форка компания Joyent учла свои ошибки и перенесла разработку на нейтральную площадку, передав проект и связанную с ним интеллектуальная собственность некоммерческой организации Node.js Foundation, в управляющий совет которой кроме сотрудников Joyent вошли представители других компаний и активные участники сообщества.Выпуск io.js 2.0 примечателен (https://github.com/iojs/io.js/blob/master/CHANGELOG.md) обновлением JavaScript-движка до версии 4.2 (https://chromium.googlesource.com/v8/v8/+/refs/heads/4.2.77/...) и, как следствие, появлением поддержки классов (директива class) и конструкций "{ method() { }, property }". В тестовом режиме также доступен расширенный формат определения функций "function(...args) {}" ("--harmony-rest-parameters"), вычисляемые свойства "{['foo'+'bar']:'bam'}" ("--harmony-computed-property-names") и экранирование unicode-символов в регулярных выражениях '\u{xxxx}' ("--harmony_unicode").
Кроме того, отмечается незначительное изменение C++ API, обеспечение переносимости вызова os.tmpdir() на разных платформах, существенное снижение потребления памяти при использовании TLS через модуль crypto, обновление пакетного менеджера npm до версии 2.9.0, увеличение производительности вызова process.nextTick() на 2-42%.
Модуль 'smalloc' переведён в разряд устаревших, в связи с прекращением его поддержки в движке V8 4.4.
URL: https://github.com/iojs/io.js/releases/tag/v2.0.0
Новость: http://www.opennet.me/opennews/art.shtml?num=42168
Нужно.
* Some problems with unreferenced timers running during beforeExit are still to be resolved. See #1264.
* Surrogate pair in REPL can freeze terminal #690
process.send() is not synchronous as the docs suggest, a regression introduced in 1.0.2, see #760 and fix in #774
* Calling dns.setServers() while a DNS query is in progress can cause the process to crash on a failed assertion #894
* url.resolve may transfer the auth portion of the url when resolving between two full hosts, see #1435.
readline: split escapes are processed incorrectly, see #1403Проблемы фиксить к релизу тоже нужно!
Не говоря про вот это: https://github.com/iojs/io.js/issues/1622"... we don't pretend to support libresssl, or anything besides the bundled openssl."
То есть мало того, что они в худших традициях таскают с собой библиотеки, так ещё и отказываются поддерживать что-то кроме. И кто-то ещё хочет доверять такому продукту свои данные? Успехов таким героям в откармливании очередного монстра, что уж.
Вам никто не запрещает собрать io.js из исходников c --shared-openssl
Товарищ, по-видимому имел в виду несколько другое - то, что слинковать можно только с openssl, который в последнее время засветился несколькими серьёзными дырами.
> Вам никто не запрещает собрать io.js из исходников c --shared-opensslУгу. Только: а) поддерживается в любом случае только OpenSSL, а не его стремительно набравшие популярность форки от OpenBSD и Google (и с чего бы?..); б) поддерживается только версия, идущая в комплекте, помогать при использовании --shared-openssl разработчики no.js принципиально отказываются.
Угу. только
а) надо _тебе_
б) имсходники открыты
ЦЭ) профит :)
> Угу. только
> а) надо _тебе_Слава богу, _мне_ оно (пока) не надо. А если будет надо - постараюсь держать подальше от интернета. Ибо нести ответственность за такой софт не хочется совсем.
> Нужно.Ещё раз форкнуть, Бог троицу любит, а иначе не взлетит.
Так и не понятно, в чем плюс по сравнению с обычной нодой.
В том, что функционал расширяется на порядки оперативнее. И расширяется набором который нужен сообществу, а не Joyent у который всегда было свое особое оригинальное мнение о том, что нужно, а что нет.
https://ru.wikipedia.org/wiki/Функционал
> https://ru.wikipedia.org/wiki/Функционалhttps://ru.wiktionary.org/wiki/функционал
Нода погрязла на V8 двухлетней давности, максимум поддержки - ES5(без расширения ES5.1)
io.js уже поддерживают большую часть ES6.
Если быть точным, то в последней версии ноды движок лета 2014 и есть базовая поддержка ES6, но до io им далеко
Прошло столько лет, а я так и не понял зачем писать сервера на джаваскрипте o_0 .
Так и умрете не просвещенным.
Я вот попробовал недавно. Был ярым противником этого. Стал изучать и что-то втянулся.
Ещё одна технология. У каждого есть выбор, это хорошо. Раньше кстати на Python/Django сидел.
В интернетах говорят, что первый сервер на js появился в 1998 Ж)
Nonblocking (неблокирующий) I/O. Хотя, не уверен, что вы понимаете, что значат эти слова.
fcntl(2): F_SETFL, O_NONBLOCK. Хотя, не уверен, что вы понимаете, что значат эти слова.
Круто, осталось понять, как это относится к написанию сервера.
Или вы любитель забивать гвозди микроскопом?
Микроскоп - это сервер. Я любитель микроскопы делать из деталей микроскопов, а не из кирпичей, как нынче принято.
Как бы вам попроще объяснить. В ноде на JS пишется высокоуровневая часть сервера, а вся сетевая часть и VM уже написаны на тех самых сях и доступны через API. Функционально-событийная асинхронная модель JS (и снова не уверен, что вы знаете что это значит) отлично ложится на неблокирующий IO, позволяя делать Highload решения. Реального конкурента в этом я вижу только GO.
> Реального конкурента в этом я вижу только GO.Erlang, Java, Dart
>> ErlangСогласен, про старичка то я и забыл.
>> Java
JAVA.nio? Сомнительный монстр. Paypal выкладывали графики сравнения производительности, после того, как переписали бэкенд с JAVA на Node.js.
>> Dart
Жаль не получил распространения, лучше бы он заменил собой JS :)
>JAVA.nio?Netty. NIO2. Алсо есть vertx.io.
>Paypal выкладывали графики сравнения производительности, после того, как переписали бэкенд с JAVA на Node.js.
Слышал где звон, да не знаешь где он.
http://developer-blog.cloudbees.com/2013/12/about-paypal-nod...
>> Слышал где звон, да не знаешь где он.Почел по ссылке. Какой-то демагог, не имеющий никакого отношения к paypal, попытался выгородить свою любимую JAVA. Целый пост неочемного бла-бла-бла из серии "вы все врёте!". Так что там со звоном, м?
>Целый пост неочемного бла-бла-бла из серииНу что поделать, не все способны понимать прочитанное.
>"вы все врёте!"
Пи..шко проекции. Цитату из текста на "врёти".
>Так что там со звоном, м?
Там же, всё звенит.
Не имею желания спорить с фанатиком. С фанатиком JAVA тем более.
Это всё для челяди..
В сях также возможны функционалы - указатели на функции, которые позволяют выполнит ту же асинхронную модель, когда обработчик передаётся в аргументах некоей функции и вызывается ею тогда, когда приходит подходящей для этого момент. Это раз.
Два: описание "асинхронной модели JS" даётся с первых страниц введения в программирование на JS. Если вам и удалось их осилить, не следует считать это исключительным достижением: будьте уверены, люди в России знают, что такое асинхронная, что такое модель и что такое JS.
Функционалы это круто, но JS из коробки реализует уже готовый event loop, который никогда не блокируется (да-да, я знаю про рудиментарные sync методы)."Сервер на сях" уже стал лакмусовой бумажкой на хеллвордщиков, которые никогда не поднимали хайлоды в продакшене.
Я не спорю, иногда сервера на сях почти без вариантов (те же варгейминги с их обработкой всей игровой логикой на сервере), но для большинства серверов это маразм. Даже FB с их ресурсами сидит на унылой связке Apache+Hack(JIT PHP). Или Wikipedia, которая свой хайлоад базирует на Apache+PHP+Memcache и не бежит срочно переписываться на сях.
Повторюсь еще раз - пример реального хайлоада на ноде - бэкэнд paypal и система мгновенных сообщений (личка) вконтакте.
>>Повторюсь еще раз - пример реального хайлоада на ноде - бэкэнд paypal и система мгновенных сообщений (личка) вконтакте.как-то маловато...на питоне instagram, pinterst, mozilla, mail.ru
А если дополнить список с нодой?
Yahoo!, Academia.edu, eBay, General Electric, Microsoft (да-да, эти даже здесь успели отметиться), Palm/HP и даже некоторые сервисы Wikipedia.Вот список, где компании сами отмечались, что использую Node у себя в продакшене - https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node
Вообще-то если нет реалтайма то пофиг на чём хайлоад делать - 99.9% работы берёт на себя пяток уровней кэширования. А под ним может жить бакэнд любой степени тормозности и уродства. Поэтому в общем случае использование в хайлоаде - не показатель качества софтины. Поэтому википедия и может жить как живёт - с апачем и тормозной MediaWiki - сплошная кэшированная статика.
Ну тут ты не прав. На работе сервер - система сдачи в аренду процессинга другим банкам на c++ со своим самодельным аналогом стандартной библиотеки. Не так уж и сложно поддерживать/расширять и работает по пол года без перезапуска и то перезапуск по причине доработки. А вот в другом отделе другая приблуда сходной загруженности на ноде так ее несколько раз в неделю перестартовуют из за утечек памяти.
Справедливости ради на пользователях системы на ноде эти перезапуски практически не сказываются.
Из того, что мне очевидно из достоинств ноды: просто найти разработчика, хотя коллега, который ей занимается говорил, что она течет по памяти из-за того, что разботчики "простые".
Мне кажется, что можно и на ноде и на сях хорошо написать: был бы персонал нормальный. А свои плюсы и минусы везде будут.
>> А вот в другом отделе другая приблуда сходной загруженности на ноде так ее несколько раз в неделю перестартовуют из за утечек памятиБить по рукам больно! Пускай собирают heapdump с продакшена и изучают кучу для поиска. Не удивлюсь, если у них сессии/кэш хранятся в памяти процесса, а не во внешнем storage).
Чтобы не перезапускать сервер - мастер процесс должен делать форк кластера и завершать предыдущий. Тогда все работает бесшовно.>> Мне кажется, что можно и на ноде и на сях хорошо написать: был бы персонал нормальный. А свои плюсы и минусы везде будут.
Согласен.
> Как бы вам попроще объяснить. В ноде на JS пишется высокоуровневая часть
> сервера, а вся сетевая часть и VM уже написаны на тех
> самых сях и доступны через API. Функционально-событийная асинхронная модель JS (и
> снова не уверен, что вы знаете что это значит) отлично ложится
> на неблокирующий IO, позволяя делать Highload решения. Реального конкурента в этом
> я вижу только GO.И все это будет работать в вакууме, а не в ОС, написанной на Сях, верно?
>Реального конкурента в этом я вижу только GO.C++
Mojolicious на Perl.
> Как бы вам попроще объяснить. В ноде на JS пишется высокоуровневая часть
> сервера, а вся сетевая часть и VM уже написаны на тех
> самых сях и доступны через API. Функционально-событийная асинхронная модель JS (и
> снова не уверен, что вы знаете что это значит) отлично ложится
> на неблокирующий IO, позволяя делать Highload решения. Реального конкурента в этом
> я вижу только GO.сколько унылого бреда. «Функционально‐событийная асинхронная модель» в ноде — это идиотские мегакостыли с колбэками. потрясающий своей силой дебилизм. smalltalk и scheme с нормальными continuations, D с файберами из коробки — все печально смотрят на ребёнка‐дауна «ноду.жысы».
А в D появились файберы? Там же вроде только "настоящие" потоки были - или я что-то упустил?
> А в D появились файберы? Там же вроде только "настоящие" потоки были
> - или я что-то упустил?давно достаточно появились, прямо в фобосе. и vibe.d как раз на их основе построен.
> А в D появились файберы? Там же вроде только "настоящие" потоки были
> - или я что-то упустил?p.s. собственно, даже генераторы на файберах в std.concurrency уже запихали.
Python + twisted/gevent. И все то же самое будет.
> Nonblocking (неблокирующий) I/O. Хотя, не уверен, что вы понимаете, что значат эти
> слова.А чё, на Сях нельзя создать неблокирующий файловый дескриптор?
Можно: если грубо, то так: fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_NONBLOCK).
Но это дорого - надо искать специально обученного человека. Тогдка как для написания на JS достаточно найти средненького школьнега-фрилансера или оторвать от работы уже найденного.
Да-да. Посадить школьников, и пусть пишут свой школо код на JS. Иногда получится что-то, отдаленно напоминающее сервер.
Обоим икспертам™ по сям рекомендую глянуть на paypal, продакшен которого в данный момент работает на node.js (если еще не закончили переход на io, объявленный в феврале). Куда им лохам до анонимов с опеннета!
никто не утверждает, что на node.js нельзя написать дельный сервер. утверждвается, что для того, чтобы сервер был дельным, писатель должен быть грамотным, с чем и наблюдается проблема у людей, не способных написать сервер на сях.
Потому что кто способен написать его на сях, способен написать его и на js, и на питоне, и на заборе мелом.
Программистов с синдромом туррета, понятно, не рассматриваю.
Ну вот кто был способоен и написали сервер на сях - ноду. А теперь поверх него прикладники пишут свою прикладуху. Не понимаю, о чём стон? Вы ж не требуете, чтобы каждый, кто в файлы пишет, сам реализовывал ФС?JS - всё равно убогий язык, конечно (хотя, судя по всему, версии к восьмой его таки приведут в порядок) - но возмущаться тем, что кто-то использует готовую низкоуровневую часть - вы не охренели ли, господа?
никто не возмущается использованием готового. речь о минусах повального увлечения высокоуровневыми языками: грамотного специалиста найти сложнее, поэтому один из критериев - способность работать на уровне алгоритмов отдельно от языка, или, что звучит иначе, но по-сути то же самое: накидать (хотя бы) функциональный каркас простого сервера на сях, апи которого будет построен так, что не придётся прибегать к низкоуровневому программированию. при умении строить такое апи и понимать уже построенные высокоуровневость значения не имеет.как пример безграмотности, что царила 15 лет назад с сиплюсплюсами, можно привести неспособность отличить работу с шаблонами от работы с классами/методами/функциями. Это приводит к очень тяжёлым проектам.
Чепуха. 90% знаний, нужных для написания хоть как-то вменяемого сервера на сях - это специфика работы OS, нюансов работы TCP, умение разумно управлять памятью, писать те самые event loops с приличной производительностью, плюс уметь бороться с убогими возможностями C, который даже исключений толко не умеет. К умению писать бизнес-логику всё это практически не имеет отношения.Кроме того - в подавляющем большинстве случаев сама бизнес-логика абсолютно тривиальна и недалеко уходит от CRUD, там приличный (и дорогой) алгоритмист банально не нужен, а где нужен - там скорее в роли консультанта/архитектора.
Нсчёт плюсов - надо понимать, что это наследие времён, когда шаблонов нормальных не было, а те, что были - каждый компилятор реализовывал по-своему. Собственно, пятнадцать лет назад в этом плане была полная разруха, особенно если MS учитывать.
Очень сомневаюсь, что PayPal нанял для этого орду школьников. :-)А сам по себе nodejs - инструмент нормальный, вот только было обидно, когда, получив пачку денег от мелкософта, выпилили posix-врапперы, не сделав человеческой замены.
>А сам по себе nodejs - инструмент нормальный, вот только было обидно, когда, получив пачку денег от мелкософта, выпилили posix-врапперы, не сделав человеческой замены.У вас тут взаимоисключающие параграфы, или шизофрения.
Ну почему, выкрутился, портировав код из предыдущих версий в с++-расширение. Это несложно было, просто обидно от самого факта такого отношения.
Ну почему, выкрутился, портировав код из предыдущих версий в с++-расширение. Это несложно было, просто обидно от самого факта такого отношения. А так-то пользоваться можно было.А позже они и сами подтянулись, сделали типа-кроссплатформенно все то же.
> Прошло столько лет, а я так и не понял зачем писать сервера на джаваскрипте o_0 .не искать дабы программеров на сях. чисто бизныс.
Сервер напрямую на сях? Ох уж эти диванные аналитики с опеннета.
закляните в сквид.
Автор Postfix`а, Nginx Inc, Apache Foundation сейчас все разом вздрогнули.
Я бы посмотрел на огромный проект с полноценной бизнес логикой на голом NGINX. Разницу между фронтенд (nginx) и бэкенд (node) не ощущаем? Они, кстати, отлично уживаются в одной связке - первый играет роль балансировщика.В Apache на сях столько же когда, сколько и в node - вся core часть. А вот логика в обоих случаях пишется уже на скриптовых языках.
Писать бизнес-логику на JS - та еще радость.Для описания развесистой бизнес-логики ничего лучше классического Java-style ООП не придумано. TypeScript и прочие Dart - шаг в верном направлении (введение типизации), но при программировании чистой бизнес-логики не должно быть необходимости думать о всяких callbacks, promises, yield и async, с чем пока что проблемы.
>> не должно быть необходимости думать о всяких callbacks, promises, yield и asyncЭ... что? Аснхронность - главный плюс JS, а если приходится от "этом" думать, значит кто-то пишет бестолковый лапшакод. Кривые руки программиста не спасет ни одна парадигма/язык.
>> Java-style ООП не придумано
Читать до просветления - https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
Прототипное ООП ничем не хуже, единственное - в JS нужно больше времени уделять типизации.
Асинхронность - это свойство инфраструктуры, а не бизнес-модели. Если разница не ясна, читайте Эванса. До просветления, да. :-)В JS проблема не в прототипности, а в отсутствии типизации и понятия интерфейса. Читайте Эванса, опять же.
Все эти проблемы, конечно же, относятся именно к уровню domain model - с инфраструктурным кодом проблем нет, он прекрасно пишется на JS.
>> Асинхронность - это свойство инфраструктуры, а не бизнес-модели.А и не говорил обратного. Не надо демагогии.
>> а в отсутствии типизации
1. Типизация не может отсутствовать, она там как минимум динамическая (утиная).
2. Про проблемы типизации я писал, читайте внимательней.
3. Проблемы с типизацией в критичных местах обходятся с помощью shema типов в геттерах/сеттерах конструктора.>> понятия интерфейса
В общем: больше классов богу классов, или когда ООП становится самоцелью?
>> Читайте Эванса
Кстати, лапшакод всегда быстрее ООП (Линус не даст соврать!), но это не руководство к действию, а просто информация к размышлению...
я конечно другой аноним, но ты реально нубко.
> Кстати, лапшакод всегда быстрее ООП(Линус не даст соврать!)если ты не понял ты сейчас оскорбил много программистов,
которые кодят гораздо лучше тебя.
> В общем: больше классов богу классов, или когда ООП становится самоцелью?вы даже не понимаете походу зачем нужно ооп я правильно понимаю?
> 1. Типизация не может отсутствовать, она там как минимум динамическая (утиная).с понятием типизации тоже у тебя тоже плохо, расскажи мне какая типизация у ассемблера или форта?
Надергал цитат из контекста, дабы переврать изначальный смысл фразы? Поздравляю, теперь ты полноценный демагог. А теперь беги делать уроки.
> Кстати, лапшакод всегда быстрее ООПа также лучше, удобней и читаемей. код существ с ООП черепа нечитаем в принципе: чтобы понять, что делает myobj.mymethod(), надо отследить всё до момента, когда этот самый myobj создаётся — и только тогда можно узнать, какой же конкретно из перекрытых mymethod'ов вызвался.
впрочем, ООП‐шники решили эту проблему, хоть и неоригинально: вместо сопровождения чужого ООП‐кода они его выкидывают и пишут заново такой же, но свой.
Э... вот ты иногда как сморозишь, сорри. В ООП есть ровно два варианта - либо у тебя с кодом в данной точке трабл, и тогда лог/отладчик прекрасно покажут, какой именно у тебя объект. Либо трабла нет, и тебе по определению должно быть пофигу, какой метод вызвался - ибо инкапсуляция - лишь бы класс свои контракты вополнял.Ну нет там проблемы "непонятно, что за метод вызвался". Вообще нет. Во всяком случае, пока в ход не пошли извращения вроде прототипного наследования в JS - но это совсем-совсем другая песня.
> Ну нет там проблемы "непонятно, что за метод вызвался". Вообще нет.ну да, потому что опп‐код никто не читает.
а вообще — прекрасная иллюстрация, спасибо. чтобы прочитать и понять ооп‐код, без отладчика не обойдёшься. я столько писал‐писал, а ты одним предложением мегагвоздь вбил.
Я, конечно, ООП-шник тот ещё - больше на сях с перлом писал, чем на плюсах или, тем более, джаве (а на плюсах - больше шаблоны гонял, чем наследование) - но проблемы "непонятно какой метод" не видел ни сам, ни вокруг себя. Вообще. По самой методологии ты и не должен знать, какой объект вызывается - пока он выполняет контракт. а если нет - то это проблемы того, кто объект тебе отдал. А если ты его сам создал - то ты знаешь точно, какой там тип, а уж что у него за методы - любая IDE тебе радостно покажет, если оно такое развесистое, что со взгляда не видно.Это в JS тебе может через 20 коллбеков прилететь невесть что и через полчаса обвалить программу так как не имеет нужного метода или поля. А там, где обычные статически определённые классы/объекты - всё прозрачно. Вот в том же D с его метапрограммированием - там да, что откуда взялось - не всегда понятно, и то больше с непривычки.
> По самой методологии
> ты и не должен знать, какой объект вызывается - пока он
> выполняет контракт. а если нет - то это проблемы того, кто
> объект тебе отдал.я, как уже говорил, с удовольствием бы жил в таком мире.
> Вот в том же D с его метапрограммированием - там
> да, что откуда взялось - не всегда понятно, и то больше
> с непривычки.в D обычно проще, потому что классами злоупотребляют только новички, остальные предпочитают структуры. поэтому достаточно попасть в call site, и там видно тип обычно.
Если такие проблемы возникают, это плохой ООП-код, негодный. Злоупотребление наследованием вместо делегирования.
> Если такие проблемы возникают, это плохой ООП-код, негодный. Злоупотребление наследованием
> вместо делегирования.я бы с удовольствием жил в мире, где все пишут только хороший код, но не знаю, как туда попасть. а при одинаковой рукожопости быдлокодера ООП разобрать сложнее, чем обычный процедурный — просто потому, что приходится больше листать.
Вот не сказал бы. Объекты хочешь-не-хочешь, а заставляют хоть как-то код организовать. Как раз для рукожопых различие хорошо видно. Что до листания - один хрен в большой куче кода приходится пользоваться какими-то средствами навигации - хотя бы ctags, а лучше всё же чем-то, что синтаксис разумеет. А там всё равно всё в одном прыжке.
> Вот не сказал бы. Объекты хочешь-не-хочешь, а заставляют хоть как-то код организовать.ага. причём в одном из двух вариантов: либо god object, либо развесистая и ненужная иерархия, в которой задолбаешься ковыряться.
> Как раз для рукожопых различие хорошо видно. Что до листания -
> один хрен в большой куче кода приходится пользоваться какими-то средствами навигации
> - хотя бы ctags, а лучше всё же чем-то, что синтаксис
> разумеет. А там всё равно всё в одном прыжке.в том‐то и дело, что не в одном. это в процедурном в одном: шмяк по имени — и попал в код. а вот в объектном… шмяк по имени — и попал в дурацкую заглушку в суперклассе. отлично, прелестно, великолепно. и бесполезно. после чего начинаются поиски, кто же нас сюда привёл, какими путями, и что же за объект в конце концов поступает. без отладчика — сизифова работа. то есть, без отладчика ооп нечитаем.
>Я бы посмотрел на огромный проект с полноценной бизнес логикой на голом NGINXНеосилятор
>>> Прошло столько лет, а я так и не понял зачем писать сервера на джаваскрипте o_0 .
>> не искать дабы программеров на сях. чисто бизныс.
> Сервер напрямую на сях? Ох уж эти диванные аналитики с опеннета.критерий тролля: переход с разумных доводов на эмоции.
Вот и я не пойму, к чему это извращение?...
> После создания форка компания Joyent учла свои ошибки"Опыт - это такая штука, которая появляется сразу после того как он был нужен".
Короче вангую, JS сожрёт всё. Это язык 21.5 века.
Если его будут и дальше допиливать - то через пару-тройку мажорных версий он этого будет вполне достоин.
> Если его будут и дальше допиливать - то через пару-тройку мажорных версий
> он этого будет вполне достоин.Ну так он и написал 21.5 - раньше 2050 года можете не беспокоиться, а до тех пор те кто на js делает большие проекты - будут узнавать что каждый буратина сам себе враг :)
Ну да, как-то так.
> Это язык 21.5 века.Проблемы с целочисленными величинами?
попробовал эту вашу ноду, т.е io.js
и чего в ней такого хорошего не пойму, к примеру:есть фунцкия обертка над http.get(урл), которой отдали на сбор пачку урлов с резултатами в глобальный объект, и ушли дальше.
Далее, чтобы подождать и проверить результат в глобальной переменной, идем в while (true) - который заблокирует тред тем самым не даст каллбэку хттп.гет даже отработать.
Либо, другой вариант, отложить проверку результата в глоб переменной через setTimeout, но тут вся асинхронность теряется.Как это делают в ноде?
> Как это делают в ноде?колбэками детка
Смотрите в сторону промисов
они же в драфте ещё...если пользуетесь, примеры покажите
> они же в драфте ещё...если пользуетесь, примеры покажитеНе обязательно использовать нативные промисы, есть например https://github.com/kriskowal/q
вот такой вещью можно воспользоваться
https://github.com/audreyt/node-webworker-threads
> Как это делают в ноде?через задницу, как и всё остальное.
Я вот и не понял этой шумихи вокруг этой ноды, как такового удобства в ней нет, отчего столько шума что это якобы более совершенное средство - не понятно.
Если сюда прибавить "нюансы-изяны" самого Яваскрипта, то вообще ущербно всё как-то получается.
> Я вот и не понял этой шумихи вокруг этой нодыуеб‐быдлокодеры ВНИЗАПНА! смогли сказать, что они теперь могут Крутые Сервера Для Хайлоада делать, вот и весь секрет.
ну, и ещё тупость уеб‐быдлокодеров, которые уверены, что концепцию async i/o до них никто не придумал, сопрограммы и continuations для удобного (а не как в «нодежысы») использования в таких сценариях никогда не существовали.
Не без того, но есть и более банальные причины. Ну вот захотел кто-то сделать веб-проект - то, что нынче стартапами обзывают. Морда ему один хрен нужна, а бэкэнд запросто может оказаться тривиальным, особенно если вся работа в браузере делается. И за счёт нода вполне реально сэкономить на бэкэндщике. Когда оно делается без финансирования от большого дяди - вполне важный фактор.А для живого проекта - это возможность более равномерно загружать команду и, опять-таки, сэкономить на зарплатах. Минусом, понятное дело - то, выходит больше кода на JS, поддерживать его - невелика радость, но местами нода - вполне разумный выбор.
И таки в виде "для масс" async i/o в ноде появился таки первым. Оно было где-то там в виде libevent, в эрланге, в скале... А тут - в совершенно мейнстримной упаковке.
ну так я и не говорил, что нода совсем уж никуда не годна и должна непременно умереть. я, в общем‐то, говорил о том, за счёт какого контингента (в основном) она стала такой популярной.я, впрочем, всё равно не могу постичь глубины мазохизма людей, пишущих на динамических языках что‐либо сложнее тривиальных throw-away scripts.
Потому что иметь один и тот же язык на клиенте и на сервере - выгодно со многих точек зрения. И (иногда) это перекрывает даже тот факт, что этот язык - паршивый JS.
Java-капец? ;)