Pavel
я в таких случаях Алана Кея вспоминаю
Pavel
Если вы используете языки с ранним связыванием, как это делает большинство, то вы запираете себя в рамки того, что уже написали. Переформулировать с легкостью уже не получится.
Pavel
И потенциал для изменений на ходу и более быстрых итераций:
Одна из ключевых идей: система должна продолжать работу во время тестирования о особенно во время произведения изменений. Даже крупные изменения должны быть поэтапными и занимать не больше доли секунды.
Pavel
https://habr.com/company/hexlet/blog/303754/
Alexander
будто у типизации есть какие-то проблемы с этим
Alexander
факт в том, что ill-typed система не работает правильно
Alexander
быстро обновлять неправильную системы - такое себе требование
Pavel
быстро обновлять неправильную системы - такое себе требование
хорошее тербование, особенно для систем, которые нельзя останавливать
Alexander
это требование не противоречит типизации никак
Alexander
вот совсем никак
Pavel
раньше увлекался и писал на ерлаге. там там его так и несмогли сделать типизированным как раз токи изза проблемы горячего обновления кода
Pavel
как они пишут. задача оказалась очень сложной
Alexander
кстати ни одна из фирм с эрлагном не пользовалась горячим обновлением
Alexander
и многие ругали
Pavel
где про это можно прочитать, очень интересная информация
Pavel
насколько мне известно там оно изначально закладывалась при проектирвоании языка и даже вовсю использовалось
Alexander
но лучше @voidlizard он использовал или тут еще были те кто и сейчас используют спросить
Alexander
в любом случае статическое ядро + динамическая логика позволяет рантайм обновление
Alexander
в erlang статическое ядро это RTS (интерпретатор)
Евгений
Горячее обновление это не та проблема, которая решается на уровне приложения
Alexander
на уровне приложения ее тоже можно решить
Alexander
от RTS требование уметь отключать модули когда они уже не используются
Alexander
приложение должно быть aware of update чтобы по настоящему горячее обновление было возможно
Alexander
просто инфраструктурой обновление не сделать для произвольной программы
Alexander
если она не stateless
Евгений
Ну, стейтфулл приложения это очень особенное явление.
По больше части современные приложения стейтфулл больше от небрежности чем из-за необходимости
Alexander
не уверен
Anonymous
Евгений
Ну мне сложно придумать юзкейсы стейтфул серверных приложений, которые не сводятся к "мне было лень прикручивать базу"
Евгений
Базы нужны, но они как раз и есть очень особенное явление
саша
Alexander
да что угодно где инициализация состояния будет дорогой
Alexander
хотя если можно делать стейтлесс, то лучше делать стейтлесс
Евгений
да что угодно где инициализация состояния будет дорогой
Но состояние можно же хранить в специализированных местах
Евгений
Не могу понять почему нет
NC
Всё же для игровых серверов базы слишком медленные
Евгений
Базы разные бывают
NC
Ну если туда занести inmemory хранилища, то вопросов нет
Alexander
Но состояние можно же хранить в специализированных местах
ты постепенно дампаешь часть стейта чтобы восстановиться, это да
Alexander
но процесс восстановления дорогой и разрешает что-нибудь потерять (иногда)
Евгений
Под базой я понимаю любое приложение, нацеленное на хранение состояния и доступное через сеть.
Не юзать базы практически всегда означает написать свою, но дёргать её не через удалённые вызовы, а через шарад-мемори
Alexander
ну вопрос будет в ее zero downtime обновлении
NC
И единственный случай, когда надо писать shared memory хранилище, это игры (считай любые симуляции)
Евгений
Евгений
Латенси?
NC
Именно
NC
Приходится всё кешировать агрессивно в памяти сервера
Апач
embeded memchached базы нет?
NC
Я в embeded не лез, мб это второй случай
Апач
эмбедед это встроенная в приложение бд
Евгений
Ну эмбеддед делает автоматически приложение стейтфул
Апач
в оперативе
Апач
та же самая СУБД
саша
А в чём проблема?
В том, что для некоторых серверов даже инмемори базы - слишком медленно, нужен raw state и по песочнице для каждой сессии (игры).
Апач
и нету оверхеда
Апач
проблема зеро даунтайма решается шардами, орхестраторами и микросервисами
Евгений
В стейтфуле? Нет же
Евгений
Только писать кластер
Апач
кластер всё решает
Евгений
Написать кластер это непростая задача
Апач
да ладно.
Апач
Если есть одна бд, и стейтлесс приложухи, то там их дробить на инстансы одно удовольствие
Евгений
Так блин :(
Апач
Распределённое и стейтфулл плохо дружат
Anonymous
Riak как-то их подружили..
https://en.wikipedia.org/wiki/Riak
Cheese
Anonymous
и где теперь тот риак?
даже хорошему продукту могут не найтись покупатели. Время такое - разруха..
Pavel
даже хорошему продукту могут не найтись покупатели. Время такое - разруха..
там дело не в продукте, а в менеджменте
Anonymous
там дело не в продукте, а в менеджменте
может и так. я не в курсе. А что они делают неправильно?
Riak попробовал. Работает, но не подошёл.
Pavel
может и так. я не в курсе. А что они делают неправильно?
Riak попробовал. Работает, но не подошёл.
а они уже не делают. они уже закрылись. вроде как код договорились выложить в OSS. а в кратце, там выпилили очень ок руководителей и поставили "эффективных" менеджеров, которые по итогу уволили некоторое кол-во очень техничных людей и следом за ними ушли почти все остальные. дальше это все превратилось уже больше в бодишоп под распиаренным ранее брендом. ну и в итоге это как-то уже и продавать не сильно стало получаться или такие же "эффективные" продажники пришли на смену. и по итогу - они банкроты
Anonymous
печально.
Апач
Riak как-то их подружили..
https://en.wikipedia.org/wiki/Riak
Ну они же много усилий для этого потратили.
Апач
Тратить их каждый разкогда тебе нужно нелокальное состояние для больше чем одного исполнителя, на сой взгляд, дурная работа.
A64m
комитетчики весь год не особо работают, но как время чего-нибудь принять уже до релиза подходит - вообще мертвые
Anonymous
Нужно всё взвесить 🧐
Они каждый релиз одобряют?
A64m
они одобряют отдельные фичи