Введение

Я продолжаю свой небольшой цикл статей относительно средств организации и реализации конкурентных вычислений.

В прошлой статье мы посмотрели на абстракцию потоков, позволяющую делать вид, что код функций выполняется одновременно и непрерывно.

В этой мы посмотрим на ещё две модели, одна из которых не делает такого вида, а вторая смотрит на конкурентные вычисления с более абстрактной стороны.

• Параллелизм (часть 1)
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2, текущая)
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3)
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

Привет, хабравчане! В этой статье я познакомлю вас с фреймворком Comedy — реализацией акторов в Node.JS. Акторы позволяют масштабировать отдельные модули вашего Node.JS приложения без изменения кода.

Сейчас уже мало кто пишет на Perl'е, но известная максима Ларри Уолла "Keep simple things easy and hard thing possible" стала общепринятой формулой эффективной технологии. Ее можно трактовать в аспекте не только сложности задач, но и подхода: идеальная технология должна, с одной стороны, позволять быструю разработку средних и малых приложений(в т.ч. "write-only"), с другой — предоставлять инструменты для вдумчивого девелопмента сложных приложений, где на первое место ставиться надежность, поддерживаемость и структурированность. Или даже, переводя в человеческую плоскость: быть доступной для джунов, и в то же время удовлетворять запросы синьйоров.

Популярный ныне Редакс можно покритиковать с обеих сторон — взять хотя бы тот факт, что написание даже элементарного функционала может вылиться в множество строчек, разнесенных по нескольких файлах — но не будем углубляться, ведь об этом уже и так немало сказано.

"Вы будто бы храните все столы в одной комнате, а стулья — в другой"
— Юха Паананен, творец библиотеки Bacon.js, о Редаксе

Технология, о которой сегодня пойдет речь, не является серебрянной пулей, но претендует на большее соответствие указанным критериям.

В этой статье будет рассказ об опыте использования акторного подхода в одном интересном проекте автоматизированной системы управления для театра. Это именно впечатление от использования, не более того.

Где же держать бизнес логику приложения?

 "Та че уж там парится - прямо в компонентах." - скажут некоторые. И в некоторых ситуациях это правильное и удобное решение.

Но что если мы все-таки хотим чего-то большего? Например, масштабируемости, несколько юзер интерфейсов, лёгкой смены дизайна. Тогда логично разделить приложение на два слоя. Слой бизнес логики и слой представления. 

Как написано на сайте reactjs.org, React - это библиотека для создания UI. 

А для модели и бизнес логики написано несколько других замечательных библиотек.

Так уж получилось, что проекты, на которых я работал, использовали redux. Поэтому дальше речь про него. А конкретней - про то, как построить бизнес логику в большом react/redux приложении, чтобы потом не закрывать рукой глаза при виде того огромного количества редюсеров, экшенов и так далее и тому подобное.

Акторы (Actors) — это фича, являющаяся частью структурированного параллелизма (Structured Concurrency) Swift, которая предлагает совершенно новый формат для написания и обработки асинхронного кода. Хотя они и являются чем-то инновационным для языка Swift, сама технология новой не является. Многие языки успели обзавестись поддержкой акторов и async/await раньше, чем Swift, но что интересно, так то, что везде они реализованы одинаково. Только-только получив этот функционал в Swift, мы уже можем многому научиться на опыте разработчиков, использовавших их в других языках.

Всем привет! 

Вышел AppCode 2021.3, а значит, пора о нем рассказать.