Комментарии 63
ООП вульгарис имеет более низкий порог вхождения чем ФП или акторная модель. Особенно если не погружаться глубоко в эти ужасы.
Вопрос: почему же так важен низкий порог вхождения? Программист что одноразовый? Разве средний стаж программиста меньше года? Особенно сейчас, когда изучить библиотеки и фреймворки проще с LLM чем лет 5-10 назад когда опыт программиста приравнивался к задрачиванию знаний о фреймворках. (По ощущениям)
Бизнесу нужны стандартные и дешёвые юниты, увы!
Но не в интересах программиста такая узкая и дешёвая специализация.
тогда пусть llm сделает обратную(inverse) матрицу 4х4 сделает ну код будет верный?
случай с обраткой у меня какая-то модель начала глючить, и рядом было открыто полное руководство как это сделать, а модель предлагала мне усовершенствованные решения, когда я его просил не делать так, а всё развернуть, на что модель мне сказала, что да тут вот так и дала мне упакованное в алгоритм решение, в итоге пришлось по наитию погружаться, после чего где-то после еще 0-5 промпта я дал ему понять, что Минор для 4х4 он и детерминант он считает не правильно, он делал вид что понимает меня, но ответ был не верный, и потом он сам догадался что надо сверяться с калькулятором куда потом и посылал меня, НО замечу ошибку в моём решении он так и не указал, мне её пришлось самому искать, другая модель посильнее к примеру дала код на анимацию чтобы палочка 1-штука двигалась вверх вниз - только этот пример скомпилировался, расширенный пример мы так и не смогли запустить с ИИ он в одной ошибке ушел в дебри, может эти задачи генерируют большое количество токенов или чего-то там нужного, в одном случае рутина проверить повторяемые данные, в другом просто задача громоздкая
Я привел пример сравнения прямо в тексте и продолжаю пребывать в уверенности, что низкий порог входа — это сказки.
GenServer не похож на замену класса в ООП. Скорее, на замену микросервиса. Или как?
Если замена каждого класса то будет что-то непонятное с производительностью
GenServer не похож на замену класса в ООП. Скорее, на замену микросервиса. Или как?
GenServer — класс, процесс — инстанс класса.
Если замена каждого класса то будет что-то непонятное с производительностью
Угу, прям беды, вон спросите у команды вотсапа (или у меня). Очень всё понятно, легковесных процессов можно запустить на одной ноде примерно около миллиона (и больше, если прям надо).
Актор это обёртка над изменяемым состоянием, правилами его валидности, умеющая общаться с другими акторами в конкурентной среде, не имеющей гарантий передачи.
Для дошкольников так лучше.
А вот для детского сада:
Представь, что Актор — это такой маленький робот-помощник.
* У каждого робота есть своя коробочка с игрушками (это его "состояние", которое он меняет). Только он сам может играть со своими игрушками и следит, чтобы они были в порядке (это "правила валидности").
* Роботы могут передавать друг другу записочки (это "общение").
* Вокруг много таких роботов, и все они что-то делают одновременно. Робот примет несколько сообщений даже если не успел разобраться с предыдущими. (это "конкурентная среда").
* Когда робот отправляет записочку, он не знает точно, дойдёт ли она и когда (это "нет гарантий передачи").
В ООП методы объектов обычно вызываются напрямую и синхронно (вызвал метод – ждешь выполнения). И не записочками а командами.
Так понятнее? )
ООП вообще никак не влияет на синхронность. Вам не кажется странным, впринципе, разделять ООП и ФП? Чем отличается метод от функции? Мне кажется контекстом, отсюда и DDD, бизнес хочет глубже знать разработку, вот пожалуйста готовый подход.
ООП вообще никак не влияет на синхронность
Это для примера. Согласен, не точно.
Вам не кажется странным, в_принципе, разделять ООП и ФП?
Мне кажется ещё более странным вводить полиморфизм через ООП как сделано в статье. Сами найдете или вам цитаты искать?
Чем отличается метод от функции?
Метод есть только в ООП и имеет доступ к данным объекта. То есть функция сама по себе, метод только конкретного объекта. И из определения функция (если она не метод) чистая.
Мне кажется контекстом, отсюда и DDD, бизнес хочет глубже знать разработку, вот пожалуйста готовый подход
Не понял
Бизнесу проще говорить в терминах ООП? Спорно. Проще говорить про события, факты и правила, а это всё ФП
Объекты легче описать на понятный язык. Представить объект машины в голове и придумать ему свойства и функционал может каждый в бизнесе, а так сказать стать актором, не каждый
Ровно наоборот.
Каждый в этом мире как раз является актором. Получает сообщения от окружающего мира и асинхронно на них отвечает (или не отвечает). Джо Армстронг про это буквально тысячу раз говорил, и я с ним абсолютно согласен.
Объекты — вымученная парадигма, никто в реальном мире не ведет себя, как объект.
Каждый в этом мире как раз является актором.
Опишите, пожалуйста, мобильный телефон, его свойства и возможности на акторной модели
Опишите мобильный телефон хоть как нибудь
defmodule Handy do
use GenServer
@impl GenServer
def init(%{model: %Model{}} = state) do
{:ok, %{state | state: :idle}}
end
@impl GenServer
def handle_call({:call, number}, _from, %{state: :in_call}) do
{:reply, :busy, state}
end
def handle_call({:call, number}, _from, %{state: :idle}) do
GenServer.send(Dialer, number)
{:reply, :started, %{state | state: :in_call}}
end
@impl GenServer
def handle_cast(:ended, state) do
{:noreply, %{state | state: :idle}}
end
end
А вы знаете, что методы классов в питоне — это буквально обыкновенные функции, которые первым аргументом имплицитно получают ссылку на инстанс владельца?
А что методы класса в JS могут очень интересно интерпретировать this внутри себя?
Мне кажется, в принципе, что ООП странно противопоставлять ФП, но разделять их все-таки имеет смысл. Глядя на код, всегда можно сказать, в ОО или Ф парадигме он написан.
Нет, не понятнее.
Актор — это такой маленький робот-помощник
Кому он помогает и в чём? И насколько он маленький? Это важно, чтобы он был маленьким?
У каждого робота есть своя коробочка с игрушками
Вообще непонятно зачем нужна коробочка с игрушками. Она вводится как что-то явно важное, но потом повествование переключается на записочки а про коробочку больше не вспоминают. Зачем она нужна? Но при этом каждый робот за ней постоянно следит, чтобы коробочка была в порядке - а что значит в порядке?
Робот примет несколько сообщений даже если не успел разобраться с предыдущими.
Стоп. А что значит разобраться? До этого было сказано, что роботы могут передавить друг другу записочки и таким образом общаться. А оказывается, что записочки это не общение, а скорее какие то проблемы с которыми надо разбираться! Да ещё и суетиться надо, так как можно не успеть со всем разобраться. Всё запутано настолько, что жесть!
Когда робот отправляет записочку, он не знает точно, дойдёт ли она и когда
Да уже не важно. В любом случае, кто пытается понять это объяснение, к этому моменту уже поймёт, что это какая то дичь, которую невозможно понять. И слова про то, что доставка записочки толи будет, толи нет, толи дождик толи снег, окончательно его убедят в том, что даже не надо пытаться ничего понять.
Интересно, а те, кто программируют на эрланге в курсе, что используют акторную модель?) По моим наблюдениям, точно не все, даже из тех кто этот эрланг и otp преподаёт. Вот Go - в любой вики сразу написано, что это имплементация модели последовательных коммуницирующих процессов, или как там их.
Вы сравниваете акторную модель с ООП - насколько это корректно? Акторная - модель, а ООП - методология. Акторная модель вычислений может быть реализована на любом языке программирования и любой его методологией, и не только программно.
Мне кажется было бы корректней рассматривать акторную модель как разновидность потоковых вычислений, когда не поток инструкций определяет порядок выборки и обработки данных, а потоки данных инициируют выполнение тех или иных инструкций. Это способ организации вычислений, или их модель. Ну да, есть языки, предназначенные только для этого, но это не проблема понимания принципов акторной модели, имхо
Мне кажется было бы корректней рассматривать акторную модель как разновидность потоковых вычислений, когда не поток инструкций определяет порядок выборки и обработки данных, а потоки данных инициируют выполнение тех или иных инструкций
Много общего. Но у потока нет состояния.
Почему нет? Смотря что понимать под потоком. Пришла реализация данных, запустилась какая то функция, по результатам обработки вычислилась какая то переменная, которая используется при следующей инициации. Переменная - состояние актора. Если внутри актора стейт машина - у актора с каждой инициацией обновляется состояние. Поток не вычислительный тред, а сущность, отражающая распространение данных в системе. Акторная модель, описанная тут в контексте ЯП - частный случай потоковой модели организации вычислений.
Почему это? Может и быть, никто не запрещает.
Вы сравниваете акторную модель с ООП
Покажите, пожалуйста, где именно я сравнивал акторную модель с ООП? Я всего лишь написал код в двух разных парадигмах — и, о чудо, он получился практически одинаковым.
Акторная — модель, а ООП — методология.
ООП тоже всего лишь модель, что бы вам там инфоцыгане ни нарассказывали.
25 лет назад не было инфоцыган) А вот исследования различных моделей организации вычислений, в том числе для построения моделей в различных предметных областях были. Если правильно помню, то самый абстрактная модель организации вычислений называлась token based actor model, или как то так. В зависимости от содержания актора и того, что вкладывалось в ярлык, получались более специализированные модели - синхронные и асинхронные, иерархические, гетерогенные, метрического времени и тепе. В частности, INRIA и Беркли проводили конференции и разные специализированные языки пытались изобретать. Касалось правда это не эээ... "десктопного" программирования, а проектирования цифровых систем контроля и управления. В этом контексте ООП лишь методология. Она не отвечает на вопрос как организовать вычисления в программируемой цифровой системе, даже с SOLID и чистой аохитектурой)
25 лет назад не было инфоцыган)
Как это? А Роберт Мартин? :)
В этом контексте ООП лишь методология.
Ой, ладно, это софистика уже. Ну сложилась же с легкой руки Гослинга «модель вычислений, используемая в 99% ООП проектов».
Пока в существующих языках (эрланг, эликсир, gleam, lfe) — ① решается виртуальной машиной.
С недавних пор есть и в Swift'е как часть языка, на мой взгляд очень элегантная. Если коротко: организована на безстековых корутинах выполняющихся на кооперативном пуле, но есть возможность задать отдельным актора кастомного исполнителя с любой средой обработки сообщений.
Компилятор сам проследит из какого к какому контексту происходит обращение. Вызов одного и того же метода будет либо синхронным, если работа осуществляется внутри актора, либо явно асинхронным через корутину, если компилятор обнаружит что пересекается граница актора.
А можно ссылку на пример кода какой-нибудь?
Хорошие примеры с ходу не находятся, скорее наоборот, немало плохих, видимо потому что вещь относительно новая и уникальная в своём исполнении. Самый простой пример можно посмотреть в официальной документации, но к сожалению она безумно скудная на тему акторов.
Swift довольно органично (и инновационно на мой взгляд) сплавляет между собой безстековые корутины и акторную и ООП модели в единую мощную парадигму, и всё это посыпает статичными проверками на потоковую безопасность. На базе этой системы строится уже более продвинутые вещи из разряда:
Глобальные акторы - объединение набора классов в единный "акторный домен". Между собой классы взаимодействуют последовательно и синхронно, обращение из-вне домена - асинхронное.
Кастомные исполнители для локальных акторов - можно каждому актору назначить эксклюзивный поток, либо выделить один поток для набора акторов, либо любая другая логика планировщика на базе очередей и пула потоков, как душе угодно
Distributed actors - работа с акторами как с обычными объектами, но реально отправляющими сообщения, например, другой машине по сети или другому системному процессу. Ни разу не возникло необходимости использовать, но выглядит очень интересно
наш «developer» будет в «локальном кэше» — в состоянии уже запущенного процесса. Мы можем его изменять, получать из него данные — и всё это без походов в базу.
① за процессами кто-то должен следить, потому что если крысы перегрызут кабель — мы не должны потерять наши данные
① решается виртуальной машиной
Расскажите пожалуйста больше подробностей. Как именно это решается виртуальной машиной? Мы не сохраняли изменения в базу, потом сервер с этим процессом отключился, потому что в нем сломался жесткий диск, и что дальше?
Мы не сохраняли изменения в базу, потом сервер с этим процессом отключился, потому что в нем сломался жесткий диск, и что дальше?
Простите, а в вашем мире «БАЗА» — это такое магическое существо, волшебно сохраняющее всё навсегда, безотказно, даже в случае нетворк сплитов и отказов жесткого диска? Откуда у вас такая слепая вера в Великую Базу — и такое недоверие к процессам? Чем процесс хуже?
Вам, возможно, будет любопытно заглянуть в код RabbitMQ и даже местами Kafka. Там нет базы. Но вы их, наверное, могли бы использовать безоглядно, так?
больше подробностей
Есть миллиард способов эту конкретную проблему решить: писать event log, сохранять критические изменения состояний, да хоть черта в ступе, для каждой конкретной задачи — существует своё решение. Но доступ на чтение уж точно может обойтись без похода в базу.
а в вашем мире «БАЗА» — это такое магическое существо, волшебно сохраняющее всё навсегда
Нет. В моем мире «БАЗА» — это такое приложение, сохраняющее всё в файлы на жесткий диск. Не волшебно, не безотказно, и не навсегда, просто сохраняющее. С намеренно реализованной системой транзакций, которая имеет защиту от сбоев в середине записи. В отличие от состояния процесса, которое находится в оперативной памяти, на жесткий диск не сохраняется, и системы транзакций не имеет.
И являющееся общим источником данных для всех процессов, которые с ней работают. В отличие от процессов на нодах кластера, каждый из которых может загрузить себе из базы локальную копию данных одного и того же объекта.
Откуда у вас такая слепая вера в Великую Базу
Ниоткуда, потому что это не вера и не слепая. А знание о том, как работают базы, и зачем нужны походы в них.
Чем процесс хуже?
Тем, что процессом называют код в оперативной памяти, который изменяет состояние в оперативной памяти, которое по умолчанию на жесткий диск не сохраняется, и системы транзакций не имеет.
Если же процессы в Эрланге транзакционно сохраняют состояние на жесткий диск с защитой от сбоев, то являются базой данных, поэтому ваше утверждение "без походов в базу" ложно.
Бэкапы, распределенные транзакции, и другие особенности использования миллиона разных баз вместо одной пожалуй не будем обсуждать.
RabbitMQ и даже местами Kafka. Там нет базы. Но вы их, наверное, могли бы использовать безоглядно, так?
В RabbitMQ и Kafka есть персистентность, для ее корректной работы там написано много кода. Но они не являются источником данных, а просто передают их от источника к получателю. И да, если надо гарантировать отправку сообщений после сохранения изменений, то используется подход transactional outbox, который внезапно подразумевает использование базы данных.
Мы можем его изменять ... и всё это без походов в базу.
Но доступ на чтение уж точно может обойтись без похода в базу.
Вы же говорили про "изменять без походов в базу"? Теперь оказывается, что это только для чтения подходит?)
Доступ на чтение без похода в базу и даже изменение прекрасно реализуются без акторов и процессов в любых языках. А походы в базу нужны, чтобы измененное состояние стало доступно другим процессам, в том числе в случае перезапуска изменившего процесса, в том числе самой базы.
писать event log, сохранять критические изменения состояний
А, ну то есть вместо того, чтобы ходить в уже написанную базу, вы предлагаете писать свою базу и ходить в нее. Как-то не выглядит похоже на "без походов в базу". Выглядит как дополнительная работа, а не как преимущество, которым вы пытались его представить.
процесса […который…] системы транзакций не имеет.
процессов на нодах кластера, каждый из которых может загрузить себе из базы локальную копию данных одного и того же объекта
Процесс, конечно же, имеет механизм транзакций. И не бывает двух процессов для одного товара (если только этого зачем-то специально не захотел программист).
В RabbitMQ и Kafka есть персистентность, для ее корректной работы там написано много кода.
Не может быть. Чтобы что-то работало, нужен код.
вместо того, чтобы ходить в уже написанную базу, вы предлагаете писать свою базу
Нет конечно, реализаций Event Log’а полно́ на любой вкус и цвет. Просто обращений на запись к нему будет на порядки меньше и они будут на порядки быстрее стандартной RDBMS (и NoSQL тоже, но там все не так прозрачно).
———
Короче, я понял ваш основной тезис: диск — хорошо, память — плохо. Медленнее, у́же бутылочное горлышко, в разы хуже и сложнее масштабируется, но — лучше.
Я не понимаю, с каких херов, и уж подавно не разделяю этот тезис, но, как минимум — понял позицию.
Процесс, конечно же, имеет механизм транзакций.
Ну вот с этого и надо было начинать. "Не используйте одни транзакции, используйте другие".
Нет конечно, реализаций Event Log’а полно́ на любой вкус и цвет.
А он сам магически будет писать то что мне нужно, или надо писать какой-то код для его вызова в нужные моменты с нужными параметрами? Я, естественно, подразумевал использование сторонней библиотеки, а не написание всего с нуля.
База это в общем-то и есть одна из таких реализаций. Я ей говорю что надо изменить, она сама пишет нужные логи для защиты от сбоев.
И не бывает двух процессов для одного товара (если только этого зачем-то специально не захотел программист).
У нас 2 ноды, которые обрабатывают веб-запросы, обе запросили товар 321, процесса для которого еще нет. Они обе выполняют state = :db.read(321), запускают для него receive_loop, и записывают в свою область памяти, обозначенную в коде названием master, разные pid. Я верю, что Эрланг имеет какие-то средства для защиты от этого, но из вашего кода они неочевидны.
диск — хорошо, память — плохо
Для той задачи, для которой делают упомянутые вами "походы в базу" да. Именно затем их и делают. Там где не надо, просто не делают, есть кэш и локальные переменные. Кэш на отдельной ноде, который хранит данные в оперативной памяти и возвращает их по сетевому запросу, это примерно то же самое, что и процесс из примера в статье.
Медленнее, у́же бутылочное горлышко, в разы хуже и сложнее масштабируется, но — лучше.
По критерию консистентности данных да, лучше. Масштабируется тоже неплохо, запустили 10 контейнеров или 10 джобов в одном контейнере, и они работают себе параллельно. Поддержки языка для параллельности обычно нет, это да, но со способом сохранения данных это не связано.
«Не используйте одни транзакции, используйте другие.»
Нет, язык из коробки предоставляет транзакционное обращение к состоянию процесса, вы не можете получить там гонку.
А он сам магически будет писать то что мне нужно […]
EventLog? — Магически, разумеется. В любом языке, причем. Это же контракт.
У нас 2 ноды, которые обрабатывают веб-запросы, обе запросили товар 321, процесса для которого еще нет.
В данном случае 321 — это и есть идентификатор процесса. Создание процесса — синхронный вызов (если программист специально не извернулся). Поэтому первое обращение вернет {:ok, pid}, а второе — {:error, {:already_started, pid}}. В тексте этого действительно нет, потому что текст не об этом.
Кэш на отдельной ноде, который хранит данные в оперативной памяти и возвращает их по сетевому запросу, это примерно то же самое, что и процесс из примера в статье.
Нет. Потому что вы не можете просто разнести кэш по пяти нодам прозрачно для вызывающего кода, а где именно запущен процесс — вызывающему коду знать не нужно. Существуют distributed cache решения, но они очень накостыленные обычно, если нет прозрачного механизма отсылки сообщений (вызова методов) внутри кластера.
По критерию консистентности данных да, лучше.
Это утверждение основано на «с диском я работал, и мне нравится». Моё (обратное) основано на «я работал и с тем и с другим, и я так не думаю».
С намеренно реализованной системой транзакций, которая имеет защиту от сбоев в середине записи
транзакционное обращение к состоянию процесса
Как я написал в самом начале, я говорил про транзакционную запись на диск для защиты от сбоев. Что означает 1) для одного процесса отсутствие ситуации, когда записалась только половина нового имени пользователя, а потом произошел сбой, и процесс после перезапуска возвращает в поле name половину старых данных и половину новых, и 2) для нескольких процессов отсутствие ситуации, когда при отправке статьи на модерацию надо создать новую запись ModerationRequest и поменять Article.state = ON_MODERAION, но произошел сбой, и состояние ModerationRequest сохранилось, а состояние Article нет. Бизнесу такие ситуации почему-то не нравятся, и он просит сделать так, чтобы их было как можно меньше.
В любом языке, причем. Это же контракт.
Я не знаю, что вы имеете в виду, в тех языках с которыми я работал, никакие логи при записи нового значения в переменную state магически сами не пишутся.
Потому что вы не можете просто разнести кэш
Обычно это и не надо. В других языках никто не загружает все 100 гигабайт базы в оперативную память.
Это утверждение основано на «с диском я работал, и мне нравится»
Нет, не на этом. А на понимании того, что произойдет в обоих случаях, насколько это нужно бизнесу, и сколько дополнительной работы это может мне создать. В том числе на ваших утверждениях вида "можно просто забить на потерявшиеся колбасы". В моих проектах бизнес этого не хочет, и достичь этого довольно просто.
Простите, а в вашем мире «БАЗА» — это такое магическое существо, волшебно сохраняющее всё навсегда, безотказно, даже в случае нетворк сплитов и отказов жесткого диска? Откуда у вас такая слепая вера в Великую Базу — и такое недоверие к процессам? Чем процесс хуже?
Это вера в репликацию данных
А процесс реплицировать — законом запрещено, или что? Кроме того, репликация бывает разная, и при упомянутом отказе ЖД — вас и с базой ждут гораздо более серьезные сложности, чем «восстановление из бэкапа».
А зачем вы файлы сохраняете на жёсткий диск? У вас нету каких нибудь носителей с копией данных которые вы бы хотели сохранить?
Если честно это все спор ради спора, мне кажется, учитывая приведенный выше вами код, без каких либо комментариев даже.
Почему-то я открываю вики и оттуда мне понятно зачем акторы, а отсюда веет каким-то противопоставлениям ООП, опять же из комментариев. Я не могу вообще уловить суть как это сравнивать.
Акторная модель, будучи одной из самых математически элегантных концепций в Computer Science (наравне, пожалуй, с теорией категорий и property-based тестированием)
Вы сами говорите что это фундаментальные подходы в информатике и сравниваете их с ООП. Назовите хоть 1 книгу по CS где написано про ООП кроме упоминаний, и то сомневаюсь.
Почему-то я открываю вики и оттуда мне понятно зачем акторы […]
Это вы жалуетесь, или хвастаетесь?
Назовите хоть 1 книгу по CS где написано про ООП […]
Книжки я не читаю (кроме беллетристики). Диссертация подойдёт? Вот, одна из наиболее внятных.
хвастаетесь
И что это за хвастовство такое?) Если я давно в ИТ сфере, почему мне не понимать его?)
Мне кажется вы и хотите похвастаться, только не могу понять чем
Если я давно в ИТ сфере, почему мне не понимать его?
Старость иногда приходит одна.
Книжки я не читаю
А как вы познаете информацию? Например о сетях? О той же CS?
Если честно может стоит начать читать, там много полезного, ничего личного, но теперь эта статья висит в публичном доступе с 5 лайками и пометкой "Туториал", и каких "дошкольников" вы тут научите я не знаю
в публичном доступе с 5 лайками
О-о-о, измерение длины лайков, это прям выход в красное.
каких «дошкольников» вы тут научите я не знаю
Тех, которые считают целесообразным быть в мире акторами, а не объектами.
Объективный человек более логичен, разве нет?)
О-о-о, измерение длины лайков, это прям выход в красное.
Лайки к тому что это поднимает авторитет перед читателем (для чего ещё они созданы? Отсеевать что от чего?) особенно далёким от всего этого читателям.
Нет, конечно. Объективность — синоним усредненности. Логика не имеет ничего общего с философской моделью мира, это чистая математика.
Например: мне нужна всего одна работа, и не сто тысяч, поэтому пока объективный тезис звучит как: «работу на стандартном стеке найти проще», — логичный вот так: «если я не хочу искать работу, ходить по собеседованиям и работать за гроши — надо научиться решать те задачи, которые остальные 99 999 соискателей решить не могут хотя бы в силу узости кругозора, и интересную работу начнут сами предлагать».
‹del›
его сначала нужно откуда-то (из базы) достать. Отсюда все эти N+1 проблемы
pid будет работоспособным, вне зависимости от того, на какой ноде процесс в результате запущен
Проблема N+1 идет не из того, что надо что-то достать из базы. Потому что доставать из базы можно и без N+1. Она появляется из-за повторений относительно долгой операции в цикле.
В вашем подходе она тоже возможна. Если вы загрузили все товары из базы в виде таких процессов на одну ноду, заказ 123 на другую ноду, и выводите все его order items с названием товара, то у вас будет N запросов по сети с одной ноды на другую для получения названия товара по item.productId. Возможно это будет немного быстрее чем с базой, но проблема все равно присутствует. Чтобы ее избежать, надо специальным образом проектировать взаимодействие, чтобы выполнять несколько операций за одно обращение, так же как и с запросами в базу.
надо специальным образом проектировать взаимодействие
Это зачем еще? Стейт процесса «заказ» — по сути то же самое, что документ из NoSQL — я прямо в него добавляю товары.
Чтобы отправлять к ноде с товарами не N сообщений, аналогичных по действию SELECT name FROM product WHERE id = :id, а одно SELECT name FROM product WHERE id IN (:idList). Иначе у вас такой же N+1, и работает он примерно столько же времени, потому что сеть работает одинаково что для базы, что для ноды Эрланга.
Нет у меня никакого :idList, потому что его, для начала, хранить где-то надо, а это — лишнее. Предвосхищая вопрос про стейт на клиенте: у меня и джаваскрипта нет, мы всё давно на LiveView делаем.
Нажалась кнопка «add to cart» — выслалось сообщение, стейт заказа обновился.
Нет у меня никакого :idList
Я именно про это и говорю. Нет idList, значит есть N запросов по сети к ноде с товарами от ноды, которая работает с заказом, и по этому критерию ваш подход ничем не лучше базы. Джаваскрипт тут ни при чем. Сart тоже ни при чем, я говорю про отображение уже созданного заказа.
я прямо в него добавляю товары
Во-первых, я говорю не про добавление товаров, а про отображение заказа позже.
Во-вторых, создание заказа из моего примера тоже можно описать выражением "прямо в него добавляю товары".
Видимо вы подразумеваете копирование всего состояния товара, включая название, а не только id. В случае с заказами это имеет смысл, поэтому мой пример не совсем удачный, но вы пытаетесь перевести разговор на частности и увильнуть от темы, поэтому придется привести другой пример.
Вы загрузили всех Developer на одну ноду, потом выводите список задач на другой ноде, у каждой задачи надо вывести имя ответственного разработчика. Если человек поменял имя (например, девушка вышла замуж), должно выводиться текущее имя, если человек уволился, должен выводиться статус, что он уволился, поэтому копированием состояния при создании задачи вы это не решите. При выводе будет точно такая же проблема N+1. Аналогично список статей на Хабре. Пользователь поменял ник или аватарку, должно выводиться текущее состояние.
При создании заказа с вашим подходом она тоже возможна, если есть задача, чтобы "add to cart" поддерживал добавление нескольких товаров сразу. Аналогично несколько категорий в новости, хабы в статье на Хабре, и любые другие запросы на создание с множественными идентификаторами. Поэтому утверждение, что в вашем подходе ее нет потому что нет работы с базой, не соответствует действительности.
Я никогда не пытаюсь увильнуть от темы, это во-первых. Во-вторых, все ваши аргументы годятся для полного уничижения NoSQL баз. В-третьих, у вас реляционность головного мозга.
Я легко мог бы и тут показать, как такие задачи решаются без реляций, но сегодня воскресенье, а подаю я только по пятницам. Я не ставлю перед собой задачу научить заворачивать шурупы всех людей с молотками в руках.
Для протокола: при изменении фамилии я просто грохну процессы задач, супервизор их перезапустит и правильные актуальные данные подтянутся без моего участия.
Тот самый зирокод, матьиво.
Во-вторых, все ваши аргументы годятся для полного уничижения NoSQL баз.
Конечно. Поэтому их бум прошел и его повторение не намечается. Именно из-за проблем с реляционностью и транзакциями. В каких-то нишах они подходят и используются, как и любой инструмент.
я просто грохну процессы задач и актуальные данные подтянутся
Вот-вот, оказывается еще и грохать вручную что-то надо. А еще и сохранить перед этим, а то вдруг там менеджер только что большое описание добавил и ответственного поменял. А мне ничего искать и грохать не надо, именно для этого и придумали реляции и внешние ключи.
В-третьих, у вас реляционность головного мозга.
Нет, просто я знаю как они работают и могу оценить количество действий для поддержания консистентности данных с ними и без. Для моих языков и проектов с ними проще реализовывать нужные бизнес-требования.
их бум прошел и его повторение не намечается
А пацаны в курсе? А то вот каждый второй из предлагающих мне работу — либо на Кассандре, либо на Равене. ElasticSearch есть у 90%. Я не работаю на США по идеологиченским соображениям, но вот буквально на днях Блумберг хотел именно подружить эрланг с Кассандрой.
еще и сохранить перед этим
Нет, сохранить не надо.
могу оценить количество действий для поддержания консистентности данных с ними и без
Нет, без них вы не можете ничего оценить, что и наглядно демонстрируете в ветке выше. Вы критикуете Пастернака, которого не читали. Вы не понимаете бо́льшей половины того, что я говорю (а я использую лексикон для домохозяек, на таком уровне кругозора должно хватать даже упоротым хаскелистам).
Акторная модель для дошкольников