Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
В ноде нет волокон. Есть плагин для реализации волокон, который является сугубо экспериментальным, сложным для понимания и практически невозможным для отладки.
они ставятся через npm как и любые другие модули. используются через require как и любые другие модули. какая разница в ядре они или «плагином»?
и в чём же заключается его «экспериментальность»? по моим наблюдениям работает исправно.
опять же, что сложного для понимания в схеме «запускаем поток и когда надо ставим его на паузу»? это простая и естественная схема, в отличие от «городим кучу функций и через прямую кишку прокидываем между ними переменные»
а с отладкой что за сложности? единственная сложность — стектрейс не учитывает контекст старта асинхронной операции. характерна она для любого асинхронного кода, а не только для волокон. однако библиотеки реализующие «продолжения» подклеивают стектрейс вызова. кроме того, приятный бонус — ошибки в асинхронных запросах вызывают исключение в волокне, а не пытаются убить весь процесс.
так что ты лучше не вороти нос от прогрессивных технологий и не изобретай колесо. сделай лучше что-нибудь действительно полезное.
и в чём же заключается его «экспериментальность»? по моим наблюдениям работает исправно.
опять же, что сложного для понимания в схеме «запускаем поток и когда надо ставим его на паузу»? это простая и естественная схема, в отличие от «городим кучу функций и через прямую кишку прокидываем между ними переменные»
а с отладкой что за сложности? единственная сложность — стектрейс не учитывает контекст старта асинхронной операции. характерна она для любого асинхронного кода, а не только для волокон. однако библиотеки реализующие «продолжения» подклеивают стектрейс вызова. кроме того, приятный бонус — ошибки в асинхронных запросах вызывают исключение в волокне, а не пытаются убить весь процесс.
так что ты лучше не вороти нос от прогрессивных технологий и не изобретай колесо. сделай лучше что-нибудь действительно полезное.
Во-первых, сложно то, что мы «ставим поток на паузу». Во-вторых, пытаться написать асинхронный код в синхронном стиле — это как раз-таки «экспериментальность». Волокна скрывают асинхронную природу кода, усложняя его понимание при чтении и поддержке. Опять же, по причине того, что код начинает выглядеть «синхронно», появляются дополнительные проблемы с параллельным выполнением асинхронных запросов, которые уже не вписываются в эту уютную концепцию и добавляют ложку дегтя в эту «прогрессивную» бочку:
Чем в этом примере отличаются последовательные вызовы от параллельных? И это пример из документации библиотеки по твоей же ссылке.
С «приятными бонусами» в виде отлова ошибок тоже спорно. Если ошибку можно обработать, то и во «Flowy» (и в любом подобном инструменте) ее можно поймать на последнем шаге. А она вылетела, пытаясь убить весь процесс, то это, видимо, ошибка, которую нужно чинить, а не отлавливать в волокнах — существует же лог консоли и утилиты наподобие
Прогрессивные технологии — это замечательно. Волокна, в частности, — это очень мощный в умелых руках инструмент. Но это пока что не традиционное средство, к которому привык разработчик на Node.js (да что уж там, любой разработчик), а незнакомые инструменты — это первый шаг к беспорядку в проекте и ошибкам в коде.
console.time( 'serial' )
console.log( get().statusCode )
console.log( get().statusCode )
console.timeEnd( 'serial' )
console.time( 'parallel' )
var resp1= get()
var resp2= get()
console.log( resp1.statusCode )
console.log( resp2.statusCode )
console.timeEnd( 'parallel' )
Чем в этом примере отличаются последовательные вызовы от параллельных? И это пример из документации библиотеки по твоей же ссылке.
С «приятными бонусами» в виде отлова ошибок тоже спорно. Если ошибку можно обработать, то и во «Flowy» (и в любом подобном инструменте) ее можно поймать на последнем шаге. А она вылетела, пытаясь убить весь процесс, то это, видимо, ошибка, которую нужно чинить, а не отлавливать в волокнах — существует же лог консоли и утилиты наподобие
forever, в конце-концов.Прогрессивные технологии — это замечательно. Волокна, в частности, — это очень мощный в умелых руках инструмент. Но это пока что не традиционное средство, к которому привык разработчик на Node.js (да что уж там, любой разработчик), а незнакомые инструменты — это первый шаг к беспорядку в проекте и ошибкам в коде.
> Во-первых, сложно то, что мы «ставим поток на паузу».
и что же в этом сложного? особенно в сравнении с асинхронной лапшой.
> Во-вторых, пытаться написать асинхронный код в синхронном стиле — это как раз-таки «экспериментальность». Волокна скрывают асинхронную природу кода, усложняя его понимание при чтении и поддержке.
прежде чем говорить эти глупости не мешало бы самому попробовать с ними поработать.
> Опять же, по причине того, что код начинает выглядеть «синхронно», появляются дополнительные проблемы с параллельным выполнением асинхронных запросов, которые уже не вписываются в эту уютную концепцию и добавляют ложку дегтя в эту «прогрессивную» бочку:
нет там таких проблем. в моей либе используется автоматическое распарралеливание. волокно не останавливается, пока нам не потребуется работа с результатом. аналогичный код на fibers/promise выглядел бы так:
console.time( 'serial' )
console.log( get().wait().statusCode )
console.log( get().wait().statusCode )
console.timeEnd( 'serial' )
console.time( 'parallel' )
var resp1= get()
var resp2= get()
console.log( resp1.wait().statusCode )
console.log( resp2.wait().statusCode )
console.timeEnd( 'parallel' )
> С «приятными бонусами» в виде отлова ошибок тоже спорно. Если ошибку можно обработать, то и во «Flowy» (и в любом подобном инструменте) ее можно поймать на последнем шаге. А она вылетела, пытаясь убить весь процесс, то это, видимо, ошибка, которую нужно чинить, а не отлавливать в волокнах — существует же лог консоли и утилиты наподобие forever, в конце-концов.
некоторые подобные либы не ловят, ну да хрен с ними. основная проблема всяких этих либ в том, что они ловят только ошибки в коде, который с их помощью написан. любой сторонний код для них — чёрный ящик, который может упасть и утащить с собой весь сервер. это не годится для продакшена совершенно. к тому же, какой стектрейс мы получим в случае ошибки в колбэке?
> Прогрессивные технологии — это замечательно. Волокна, в частности, — это очень мощный в умелых руках инструмент. Но это пока что не традиционное средство, к которому привык разработчик на Node.js (да что уж там, любой разработчик), а незнакомые инструменты — это первый шаг к беспорядку в проекте и ошибкам в коде.
можно подумать Flowy или любая другая либа являются традиционными и к ним привыкли разработчики) да и вообще, ратовать за явную асинхронность в то время как работа с нею является самой большой болью разработчиков на ноде — это что-то из практик BDSM)
всякие такие библиотеки-выравниватели реализуют лишь один вид потока — последовательное выполнение. однако, реальная жизнь интересней, в ней нужно часть потока выполнять в зависимости от условия, в ней нужно некоторые ветви выполнять циклично. и тому подобное. в js есть все основные операторы контроля потока, зачем их переизобретать на своём асинхронном dsl, если ест возможность дожидаться завершения асинхронных операций не теряя контекста?
и что же в этом сложного? особенно в сравнении с асинхронной лапшой.
> Во-вторых, пытаться написать асинхронный код в синхронном стиле — это как раз-таки «экспериментальность». Волокна скрывают асинхронную природу кода, усложняя его понимание при чтении и поддержке.
прежде чем говорить эти глупости не мешало бы самому попробовать с ними поработать.
> Опять же, по причине того, что код начинает выглядеть «синхронно», появляются дополнительные проблемы с параллельным выполнением асинхронных запросов, которые уже не вписываются в эту уютную концепцию и добавляют ложку дегтя в эту «прогрессивную» бочку:
нет там таких проблем. в моей либе используется автоматическое распарралеливание. волокно не останавливается, пока нам не потребуется работа с результатом. аналогичный код на fibers/promise выглядел бы так:
console.time( 'serial' )
console.log( get().wait().statusCode )
console.log( get().wait().statusCode )
console.timeEnd( 'serial' )
console.time( 'parallel' )
var resp1= get()
var resp2= get()
console.log( resp1.wait().statusCode )
console.log( resp2.wait().statusCode )
console.timeEnd( 'parallel' )
> С «приятными бонусами» в виде отлова ошибок тоже спорно. Если ошибку можно обработать, то и во «Flowy» (и в любом подобном инструменте) ее можно поймать на последнем шаге. А она вылетела, пытаясь убить весь процесс, то это, видимо, ошибка, которую нужно чинить, а не отлавливать в волокнах — существует же лог консоли и утилиты наподобие forever, в конце-концов.
некоторые подобные либы не ловят, ну да хрен с ними. основная проблема всяких этих либ в том, что они ловят только ошибки в коде, который с их помощью написан. любой сторонний код для них — чёрный ящик, который может упасть и утащить с собой весь сервер. это не годится для продакшена совершенно. к тому же, какой стектрейс мы получим в случае ошибки в колбэке?
> Прогрессивные технологии — это замечательно. Волокна, в частности, — это очень мощный в умелых руках инструмент. Но это пока что не традиционное средство, к которому привык разработчик на Node.js (да что уж там, любой разработчик), а незнакомые инструменты — это первый шаг к беспорядку в проекте и ошибкам в коде.
можно подумать Flowy или любая другая либа являются традиционными и к ним привыкли разработчики) да и вообще, ратовать за явную асинхронность в то время как работа с нею является самой большой болью разработчиков на ноде — это что-то из практик BDSM)
всякие такие библиотеки-выравниватели реализуют лишь один вид потока — последовательное выполнение. однако, реальная жизнь интересней, в ней нужно часть потока выполнять в зависимости от условия, в ней нужно некоторые ветви выполнять циклично. и тому подобное. в js есть все основные операторы контроля потока, зачем их переизобретать на своём асинхронном dsl, если ест возможность дожидаться завершения асинхронных операций не теряя контекста?
особенно в сравнении с асинхронной лапшойРаботая с Node.js, люди ожидают увидеть именно асинхронный код.
в моей либе используется автоматическое распарралеливаниеИ ты никогда не узнаешь, читая код, было ли тебе возвращено просто immediate значение, или же прилитело что-то из колбека.
любой сторонний код для них — чёрный ящик, который может упасть и утащить с собой весь сервер.это уже проблемы стороннего кода — зачем моей либе с ним разбираться?
это не годится для продакшена совершенноОтчего же? Если не нужно писать сверхотказоустойчивую автономную систему, то вполне годится. Я еще раз подчеркну, есть лог консоли приложения и утилиты автоматического перезапуска упавшего инстанса.
можно подумать Flowy или любая другая либа являются традиционными и к ним привыкли разработчикиСудя по моему опыту, это наиболее распространенный подход к организации такого кода. Уж не волокна точно.
ратовать за явную асинхронность в то время как работа с нею является самой большой болью разработчиков на нодеАсинхронность никогда не доставляла никакой боли ни мне, ни другим разработчикам, с которыми мне приходилось работать. Откуда дровишки-то? Из статей блоггеров-хэлловорлдщиков?
всякие такие библиотеки-выравниватели реализуют лишь один вид потока — последовательное выполнение.Все понятно: «статью не чилал, но осуждаю».
зачем их переизобретать на своём асинхронном dsl, если ест возможность дожидаться завершения асинхронных операций не теряя контекста?Программа, может, и не потеряет контекст, но разработчик, читающий код, сойдет с ума. Write-only код — это как раз то, что не нужно для продакшена, а не вылетевший иксепшн из-за бага, который тут же пофиксят следом.
> Работая с Node.js, люди ожидают увидеть именно асинхронный код.
ага, особенно используя require и *Sync методы) не знаю как насчёт людей, а я предпочитаю простой, ясный и понятный синхронный код, а не костыли типа Flowy и ко
> И ты никогда не узнаешь, читая код, было ли тебе возвращено просто immediate значение, или же прилитело что-то из колбека.
в этом-то вся и соль. мне совершенно не важно откуда там оно прилетело — я работаю с простым апи: запрашиваю данные и потом с ними работаю.
> это уже проблемы стороннего кода — зачем моей либе с ним разбираться?
очевидно затем, что из-за него падает твоё приложение. и ты никак не можешь эту ошибку перехватить и продолжить выполнение.
> Отчего же? Если не нужно писать сверхотказоустойчивую автономную систему, то вполне годится. Я еще раз подчеркну, есть лог консоли приложения и утилиты автоматического перезапуска упавшего инстанса.
быстро поднятое упавшим не считается?)) смотри как бы сервер у тебя в один прекрасный момент не ушёл в бесконечную перезагрузку.
> Судя по моему опыту, это наиболее распространенный подход к организации такого кода. Уж не волокна точно.
нет, у каждой такой библиотеки свой апи с которым приходится разбираться.
> Асинхронность никогда не доставляла никакой боли ни мне, ни другим разработчикам, с которыми мне приходилось работать. Откуда дровишки-то? Из статей блоггеров-хэлловорлдщиков?
из многочисленых статей описывающих очередной велосипед выстраивания колбэков в цепочки на подобии синхронного кода.
> Все понятно: «статью не чилал, но осуждаю».
а скажешь нет? как, например, пропустить один шаг?
> Программа, может, и не потеряет контекст, но разработчик, читающий код, сойдет с ума. Write-only код — это как раз то, что не нужно для продакшена, а не вылетевший иксепшн из-за бага, который тут же пофиксят следом.
на этом закончим наш спор. похоже у тебя неизлечимая деформация мозга, если такой код ты считаешь write-only:
function leaveMessage( username, text ){
....var user= model.users.findOne( username )
....if( !user ) throw new Error( 'user not found' )
…
....var message= model.messages.create( user, text )
....model.notifications.create( message )
}
а такой простым и понятным:
function leaveMessage(username, text, callback) {
....Flowy(
........function() {
............model.users.findOne(username, this.slot());
........},
........function(err, user) {
............if (!user) throw new Error('user not found');
............model.messages.create(user, text, this.slot());
........},
........function(err, message) {
............model.notifications.create(message, this.slot());
........},
........callback //any error will be automatically propagated to this point
....);
}
ага, особенно используя require и *Sync методы) не знаю как насчёт людей, а я предпочитаю простой, ясный и понятный синхронный код, а не костыли типа Flowy и ко
> И ты никогда не узнаешь, читая код, было ли тебе возвращено просто immediate значение, или же прилитело что-то из колбека.
в этом-то вся и соль. мне совершенно не важно откуда там оно прилетело — я работаю с простым апи: запрашиваю данные и потом с ними работаю.
> это уже проблемы стороннего кода — зачем моей либе с ним разбираться?
очевидно затем, что из-за него падает твоё приложение. и ты никак не можешь эту ошибку перехватить и продолжить выполнение.
> Отчего же? Если не нужно писать сверхотказоустойчивую автономную систему, то вполне годится. Я еще раз подчеркну, есть лог консоли приложения и утилиты автоматического перезапуска упавшего инстанса.
быстро поднятое упавшим не считается?)) смотри как бы сервер у тебя в один прекрасный момент не ушёл в бесконечную перезагрузку.
> Судя по моему опыту, это наиболее распространенный подход к организации такого кода. Уж не волокна точно.
нет, у каждой такой библиотеки свой апи с которым приходится разбираться.
> Асинхронность никогда не доставляла никакой боли ни мне, ни другим разработчикам, с которыми мне приходилось работать. Откуда дровишки-то? Из статей блоггеров-хэлловорлдщиков?
из многочисленых статей описывающих очередной велосипед выстраивания колбэков в цепочки на подобии синхронного кода.
> Все понятно: «статью не чилал, но осуждаю».
а скажешь нет? как, например, пропустить один шаг?
> Программа, может, и не потеряет контекст, но разработчик, читающий код, сойдет с ума. Write-only код — это как раз то, что не нужно для продакшена, а не вылетевший иксепшн из-за бага, который тут же пофиксят следом.
на этом закончим наш спор. похоже у тебя неизлечимая деформация мозга, если такой код ты считаешь write-only:
function leaveMessage( username, text ){
....var user= model.users.findOne( username )
....if( !user ) throw new Error( 'user not found' )
…
....var message= model.messages.create( user, text )
....model.notifications.create( message )
}
а такой простым и понятным:
function leaveMessage(username, text, callback) {
....Flowy(
........function() {
............model.users.findOne(username, this.slot());
........},
........function(err, user) {
............if (!user) throw new Error('user not found');
............model.messages.create(user, text, this.slot());
........},
........function(err, message) {
............model.notifications.create(message, this.slot());
........},
........callback //any error will be automatically propagated to this point
....);
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не надо давать обещания, или Promises наоборот