Речь точно про лаконичность нового интерфейса? Примеры говорят об обратном: многословнее и обработка ошибок менее интуитивна. Вся затея как раз в реактивном подходе, но он тоже не для всех задач и ситуаций нужен.
Вот если нужен асинхронный ответ в виде Feature, например, то это один из возможных вариантов
В Java, если ключи Comparable , то вместо связанного списка в бакете создается дерево. Это снижает сложность поиска в бакете с O(N) до O(logN). В этом плане Go ещё направления для оптимизаций
А как ловко они перешли от "они своруют наши технологии" к "не дать Китаю получить свои 7нм". Т.е. дело не в воровстве, а в том, что они конкуренцию хотят задавить
из того что видел по производительности, Postgres это ~ 1000rps, ActiveMQ/RabbitMQ ~20000rps, Kafka уже миллионы. Но это всё разные решения с разными подходами, плюсами и минусами. Postgres/другая_SQL_DB могут быть полезны в плане работы в одной транзакции: изменение применяется и создаётся событие, либо всё откатывается - это сильно проще в реализации для каких то кейсов, но нужно понимать, достаточен ли rps
Увы, не получится - Spring Boot 2 работает с API javax.persistence, а в Spring Boot 3 уже jakarta.persistence. Есть небольшой шанс даунгрейднуть в SB 3 hibernate до версии 5.6-jakarta, но я в неё слабо верю
Речь точно про лаконичность нового интерфейса? Примеры говорят об обратном: многословнее и обработка ошибок менее интуитивна. Вся затея как раз в реактивном подходе, но он тоже не для всех задач и ситуаций нужен.
Вот если нужен асинхронный ответ в виде Feature, например, то это один из возможных вариантов
В Java, если ключи Comparable , то вместо связанного списка в бакете создается дерево. Это снижает сложность поиска в бакете с O(N) до O(logN). В этом плане Go ещё направления для оптимизаций
Вообще не понимаю, почему вдруг DI стал проблемой, когда есть annotation processors на этапе компиляции. Micronaut тому пример
А как ловко они перешли от "они своруют наши технологии" к "не дать Китаю получить свои 7нм". Т.е. дело не в воровстве, а в том, что они конкуренцию хотят задавить
из того что видел по производительности, Postgres это ~ 1000rps, ActiveMQ/RabbitMQ ~20000rps, Kafka уже миллионы. Но это всё разные решения с разными подходами, плюсами и минусами. Postgres/другая_SQL_DB могут быть полезны в плане работы в одной транзакции: изменение применяется и создаётся событие, либо всё откатывается - это сильно проще в реализации для каких то кейсов, но нужно понимать, достаточен ли rps
Увы, не получится - Spring Boot 2 работает с API javax.persistence, а в Spring Boot 3 уже jakarta.persistence. Есть небольшой шанс даунгрейднуть в SB 3 hibernate до версии 5.6-jakarta, но я в неё слабо верю