Комментарии 11
Скоростью чего? Если сравнивать с TPL, то скорость получения коллбеков в 2 раза ниже, кроме того довольно сложно превратить императивную логику в Rx, потому что всегда надо держать в уме когда происходит подписка\отписка на IObservable и порядок прихода событий. Для увеличения стабильности приходится этот «красивый» linq обкладывать кучей костылей.
Еще одна проблема RX — работает только в stateful приложениях, ибо подписка на событие это состояние, которым надо управлять. Это сильно ограничивает область применения — UI в десктоп-приложениях и обработка сигналов (например от устройств). И то в UI далеко не все удобно делать в Rx.
Еще одна проблема RX — работает только в stateful приложениях, ибо подписка на событие это состояние, которым надо управлять. Это сильно ограничивает область применения — UI в десктоп-приложениях и обработка сигналов (например от устройств). И то в UI далеко не все удобно делать в Rx.
+6
Я один раз очень страшно поизвращался и «пробросил» EventHandler по сети от C# сервера на typescript-клиент в браузере через WebSockets.
Синтаксис получился примерно таким:
Синтаксис получился примерно таким:
sync.Events.RegisterHandler<long, FileProgressInfo, ProgressInfo>("share.file.progress",
x => _loads.ContainsKey(x) ? _loads[x] : null,
(o, h) => o.Progress += h,
(o, h) => o.Progress -= h);
+1
Я в рамках популяризации rx на работе переписал один сервис с TPL на Rx. Код получается компактный, красиво всё пайплайнится, всё читабельно, с небольшии примесями TPL получилась приличная параллелизация. Но итоговая скорость работы меня очень расстроила. Раза в полтора медленнее оригинального кода.
Потратил ещё несколько вечеров на профилирование и оптимизацию, а потом так этот форк и забросил.
Может я их готовить не умею нормально, но для performance critical приложений я бы Rx не рекомендовал.
Хотя, вот, Netflix свои сервера на Rx-Java пишут, и вроде довольны.
Потратил ещё несколько вечеров на профилирование и оптимизацию, а потом так этот форк и забросил.
Может я их готовить не умею нормально, но для performance critical приложений я бы Rx не рекомендовал.
Хотя, вот, Netflix свои сервера на Rx-Java пишут, и вроде довольны.
+1
Как-то совсем мало. Прямо даже и не видно примеров как было «грязно» и как стало хорошо с Rx.
Понятно, что с переводчика взятки гладки, но для популяризации и привлечения внимания к Rx можно было бы что-то более интересное найти.
А так же воткнуть отсебятины и ссылку на официальный сайт www.introtorx.com/
Понятно, что с переводчика взятки гладки, но для популяризации и привлечения внимания к Rx можно было бы что-то более интересное найти.
А так же воткнуть отсебятины и ссылку на официальный сайт www.introtorx.com/
0
Я сам далеко не специалист в Rx, просто попалась на глаза статья с интересным названием — вот решил перевести для себя и для других. Комментарии об этом подходе, плюсах и минусах — это приятный бонус и для меня в том числе :) Если ж тема интересна, думаю найдутся те, кому есть что рассказать и от себя. И я буду иметь в виду, если ещё что-то попадётся (специально искать и отсеивать пока времени нет). А вообще Rx на вид довольно просты, если есть опыт работы с LINQ.
Тема по замене событий на Rx (или обёртки событий в Rx) второй раз мне уже попадается — вот и заинтересовался и решил опубликовать для сообщества.
Тема по замене событий на Rx (или обёртки событий в Rx) второй раз мне уже попадается — вот и заинтересовался и решил опубликовать для сообщества.
0
это вынуждает приложение реагировать (to react), отсюда и название «Реактивные» (reactive)
WTF, to react — реагировать, отзываться, вызывать реакцию.
reactive — кроме перевода «реактивный» еще есть реагирующий, дающий реакцию.
Объясните мне, как слово «Реактивный» помогает понять суть Reactive Extensions?
Имхо только запутывает.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишите чистый код с Реактивными Расширениями (Reactive Extensions)