Информация об изменениях

Сообщение Re[9]: Книги по enterprise архитектуре основанные на примера от 09.12.2021 13:24

Изменено 09.12.2021 13:38 gyraboo

Re[9]: Книги по enterprise архитектуре основанные на примера
Здравствуйте, vsb, Вы писали:

G>>Reactive Streams — это же просто набор интерфейсов, без реализации. Причем основан на паттернах гофа, которые появились ещё до Java. Чем же эта спека тебе не нравится? И какая разница, как они реализуются, на базе легковесныхпотоков или классических джава-тредов? Это же все инкапсулировано внутри конкретной реализации.

G>>Какие конкретно претензии у тебя к этим технологиям, интересно услышать?

vsb>Конкретные претензии — невозможно читать этот код, невозможно понять проблему по стектрейсу, в нём куча багов, т.к. его нормально никто писать не умеет, причём эти баги неочевидные и не отлаживаются из-за этой асинхронщины.


vsb>node.js с его async/await адекватней сделан.


vsb>И в неосиляторстве меня не надо обвинять, я как раз осилил всю эту муть и теперь жду-недождусь, пока оно выйдет из моды (в Java).


Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).
Сложность реактивщины связана с тем, что бизнес требует создания многопоточных надежных систем, а многопоточность и реактивность противоестественны реактивщина (естественна для мышления к сожалению только тупая прямая императивность) — это только второй этап. Первым этапом является просто многопоточность со своими кривыми костылями.
Хотя, если ты умеешь писать некривые костыли на базовой многопоточности — то ок.
Re[9]: Книги по enterprise архитектуре основанные на примера
Здравствуйте, vsb, Вы писали:

G>>Reactive Streams — это же просто набор интерфейсов, без реализации. Причем основан на паттернах гофа, которые появились ещё до Java. Чем же эта спека тебе не нравится? И какая разница, как они реализуются, на базе легковесныхпотоков или классических джава-тредов? Это же все инкапсулировано внутри конкретной реализации.

G>>Какие конкретно претензии у тебя к этим технологиям, интересно услышать?

vsb>Конкретные претензии — невозможно читать этот код, невозможно понять проблему по стектрейсу, в нём куча багов, т.к. его нормально никто писать не умеет, причём эти баги неочевидные и не отлаживаются из-за этой асинхронщины.


vsb>node.js с его async/await адекватней сделан.


vsb>И в неосиляторстве меня не надо обвинять, я как раз осилил всю эту муть и теперь жду-недождусь, пока оно выйдет из моды (в Java).


Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).
Сложность реактивщины связана с тем, что бизнес требует создания многопоточных надежных систем, а многопоточность и реактивность противоестественны реактивщина (естественна для мышления к сожалению только тупая прямая императивность) — это только второй этап. Первым этапом является просто многопоточность со своими кривыми костылями.
Хотя, если ты умеешь писать некривые костыли на базовой многопоточности — то ок.
Гоф тоже раньше мало кто понимал, применяли криво и неправильно, а прошло 30 лет — и сейчас это уже стало азбукой, которую у джунов спрашивают. Надеюсь, то же будет и с реактивщиной.