Сообщение Re[9]: Книги по enterprise архитектуре основанные на примера от 09.12.2021 13:24
Изменено 09.12.2021 13:27 gyraboo
Re[9]: Книги по enterprise архитектуре основанные на примера
Здравствуйте, vsb, Вы писали:
G>>Reactive Streams — это же просто набор интерфейсов, без реализации. Причем основан на паттернах гофа, которые появились ещё до Java. Чем же эта спека тебе не нравится? И какая разница, как они реализуются, на базе легковесныхпотоков или классических джава-тредов? Это же все инкапсулировано внутри конкретной реализации.
G>>Какие конкретно претензии у тебя к этим технологиям, интересно услышать?
vsb>Конкретные претензии — невозможно читать этот код, невозможно понять проблему по стектрейсу, в нём куча багов, т.к. его нормально никто писать не умеет, причём эти баги неочевидные и не отлаживаются из-за этой асинхронщины.
vsb>node.js с его async/await адекватней сделан.
vsb>И в неосиляторстве меня не надо обвинять, я как раз осилил всю эту муть и теперь жду-недождусь, пока оно выйдет из моды (в Java).
Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).
Сложность реактивщины связана с тем, что бизнес требует создания многопоточных надежных систем, реактивщина — это только второй этап. Первым этапом является просто многопоточность со своими кривыми костылями.
Хотя, если ты умеешь писать некривые костыли на базовой многопоточности — то ок.
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).
Сложность реактивщины связана с тем, что бизнес требует создания многопоточных надежных систем, а многопоточность и реактивность противоестественны реактивщина (естественна для мышления к сожалению только тупая прямая императивность) — это только второй этап. Первым этапом является просто многопоточность со своими кривыми костылями.
Хотя, если ты умеешь писать некривые костыли на базовой многопоточности — то ок.
G>>Reactive Streams — это же просто набор интерфейсов, без реализации. Причем основан на паттернах гофа, которые появились ещё до Java. Чем же эта спека тебе не нравится? И какая разница, как они реализуются, на базе легковесныхпотоков или классических джава-тредов? Это же все инкапсулировано внутри конкретной реализации.
G>>Какие конкретно претензии у тебя к этим технологиям, интересно услышать?
vsb>Конкретные претензии — невозможно читать этот код, невозможно понять проблему по стектрейсу, в нём куча багов, т.к. его нормально никто писать не умеет, причём эти баги неочевидные и не отлаживаются из-за этой асинхронщины.
vsb>node.js с его async/await адекватней сделан.
vsb>И в неосиляторстве меня не надо обвинять, я как раз осилил всю эту муть и теперь жду-недождусь, пока оно выйдет из моды (в Java).
Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).
Сложность реактивщины связана с тем, что бизнес требует создания многопоточных надежных систем, а многопоточность и реактивность противоестественны реактивщина (естественна для мышления к сожалению только тупая прямая императивность) — это только второй этап. Первым этапом является просто многопоточность со своими кривыми костылями.
Хотя, если ты умеешь писать некривые костыли на базовой многопоточности — то ок.