Телеграмм чат группы fprog

Лучшая FRP библиотека - это STM (Александр Гранин) 10.06.2020

11:21пожаловаться #1

Jerzy Syrowiecki in fprog_spb

Leyλa

Наконец-то опубликовано видео доклада Лучшая FRP библиотека - это STM (Александр Гранин). Приятного просмотра! https://www.youtube.com/watch?v=L8rYYkQjzns

YouTube

у меня из доклада сложилось впечатление, что STM подходит для FRP, но хуже других. а какая библиотека на самом деле лучше?

11:21пожаловаться #2

Для начала нужно договориться, что такое FRP, или какие свойства хочется получить от решения

11:22пожаловаться #3

Ну я понял - от STM хотят свойство реактивности?

11:23пожаловаться #4

Например предложенный на докладе вариант подойдёт (и то не факт) для GUI, но не подойдёт для описания обработки и реакций на события.

11:23пожаловаться #5

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

11:24пожаловаться #6

Для GUI приложения, игр (не факт) и всякой графики это может быть подходящим вариантом.

11:24пожаловаться #7

Мне кажется, это хорошо, когда нужно иметь минимальный латенси)

11:25пожаловаться #8

Т.к. всё достаточно низкоуровнево

11:25пожаловаться #9

Ну и если хватает этого решения, понятно

11:25пожаловаться #10

Так же вариант FRP через STM в предложенном виде предполагает один легкий поток на одну ноду, это дорого при большом количестве объектов

11:26пожаловаться #11

Yan Shkurinskiy

Мне кажется, это хорошо, когда нужно иметь минимальный латенси)

Мне не достаточно ни опыта, ни знаний, чтобы оценить то даст ли этот подход меньший latency по сравнению скажем с подходом, где 1 поток обрабатывающий события, как во многих FRP фреймворках

11:28пожаловаться #12

Я про количество потоков не подумал)

11:28пожаловаться #13

тут я ничего сказать не могу

11:29пожаловаться #14

я скорее о том, что использование голого STM, наверное, достаточно дёшево, относительно фреймворков

11:29пожаловаться #15

хотя я ещё меньший знаток в этом

11:30пожаловаться #16

Alexander Tchitchigi... in fprog_spb

Доклад не смотрел, но "подписка" на изменения через общее изменяемое состояние (даже транзакционно) — такое себе. Транзакционные БД дают такую возможность уже почти пол-века, и в некоторых организациях приложения реально синхронизируют через общую БД. Но в приличных местах всё-таки используют очереди. Наверное, не с глупа. 🤔

11:33пожаловаться #17

Вообще мне интересна тема, как можно в хаскеле дешево и достаточно приемлемо организовать реактивщину

11:35пожаловаться #18

Имеющиеся фреймворки достаточно хороши?

11:35пожаловаться #19

(понимаю что слово "достаточно" очень размыто, но тем не менее)