AB
И atomic это именно мутабельная глобальная переменная получается? Прочитал доку, выглядит чужеродно для эрланга, не думал что прям в таком виде будет, ровно как и в языках с тредами
да ладно, это обычная cas-ячейка на int64.
Size: a a a
2020 September 01
AB
нормальный такой примитив
V
да ладно, это обычная cas-ячейка на int64.
Смущает мутабельность
AB
Смущает мутабельность
Так cas же, это не какая попало мутабельность, они синхронизированные
V
С точки зрения конкурентного программирования норм, но если смотреть еще на функциональную сторону, там же все персистентно стараются делать (в смысле как персистентные структуры данных)
AB
Я бы не отказался от каких-нибудь ещё cas-ячеек в beam, чтобы туда произвольные термы класть
V
Ну это прикольно на самом деле, что не форсируется так иммутабельность, как в хаскеле например
PG
В хаскеле ровно так же форсируется иммутабельность
PG
Только у них есть cas ячейки для произвольных термов
V
Ну там это в монадах, этим сложнее пользоваться, а тут просто вызывашь put и значение обновляется
AB
Я бы не отказался от каких-нибудь ещё cas-ячеек в beam, чтобы туда произвольные термы класть
Хотя, это с моделью памяти не вяжется примерно никак
LL
А crdt нужно делать самому или искать стороннюю реализацию, встроенного ничего нет? Есть ли хорошие реализации?
Есть сторонняя реализация. А так, самому
crdt замутить не сложно. Нужно сначала решить будет это state или operation репликация. Если state, то есть key-value crdt. Если не смотреть внутрь, работает вполне сносно. operation-based crdt очень легко самому сварить
V
Хотя, это с моделью памяти не вяжется примерно никак
Почему?
AB
Почему?
чтобы чтение не приводило к копированию и можно было compare проводить чисто по ссылке на данные, данные ячейки должны лежать в shared literal area(как persistent_term), а это в принципе не подходит для обновляемых данных, потому что при обновлении происходит примерно stop the world.
если копировать данные при чтении, нужны либо отдельные референсы для сравнения(compare опять же), либо сравнивать структурно, что небыстро.
ну и отдельный вопрос - владение этими ячейками и их жизненный цикл.
если копировать данные при чтении, нужны либо отдельные референсы для сравнения(compare опять же), либо сравнивать структурно, что небыстро.
ну и отдельный вопрос - владение этими ячейками и их жизненный цикл.
PG
Ну там это в монадах, этим сложнее пользоваться, а тут просто вызывашь put и значение обновляется
Лооол
LL
чтобы чтение не приводило к копированию и можно было compare проводить чисто по ссылке на данные, данные ячейки должны лежать в shared literal area(как persistent_term), а это в принципе не подходит для обновляемых данных, потому что при обновлении происходит примерно stop the world.
если копировать данные при чтении, нужны либо отдельные референсы для сравнения(compare опять же), либо сравнивать структурно, что небыстро.
ну и отдельный вопрос - владение этими ячейками и их жизненный цикл.
если копировать данные при чтении, нужны либо отдельные референсы для сравнения(compare опять же), либо сравнивать структурно, что небыстро.
ну и отдельный вопрос - владение этими ячейками и их жизненный цикл.
Ячейки вообще никак не коллектятся. Спасение утопающих — дело рук самих утопающих
AB
С точки зрения конкурентного программирования норм, но если смотреть еще на функциональную сторону, там же все персистентно стараются делать (в смысле как персистентные структуры данных)
эрланг к фп не имеет примерно никакого отношения, если что. абсолютно императивный язык, просто с персистентными данными
AB
Ячейки вообще никак не коллектятся. Спасение утопающих — дело рук самих утопающих
да, я об этом же, дополнительные сложности.
LL
эрланг к фп не имеет примерно никакого отношения, если что. абсолютно императивный язык, просто с персистентными данными
По-моему, эрланг внутри процесса достаточно функциональный. А вот во вне...
AB
По-моему, эрланг внутри процесса достаточно функциональный. А вот во вне...
с учетом расплывчатости ярлыка "функциональный", его не имеет смысла использовать.