Даже без native компиляции стартует значительно быстрее spring.
ИМХО просто потому, что в отлиции от spring, injection происходит compile time, а не runtime.

>а как это? я вот в спринге пишу в одном модуле что-то в духе:
>в надежде, что в другом модуле будет реализация, а тут как?

https://quarkus.io/blog/quarkus-dependency-injection/
Все тоже самое, @Inject ищет compile time имплементацию.

>всем известно, что футпринт изменяется в деньгах. Можете расчеты привести, чтобы можно было увидеть как ограниченность технологии со всеми вытекающими (баги, проблемы с кадрами, проблемы с поддержкой) приносило бы ощутимую экономию? А то может ну ево нах эту жаву и пора все на C писать.

Для нас в клаудных проектах критическим фактороми стали именно время старта, потребление CPU во время старта и память на поду.
Настолько критическим, что часть сервисов переписали на go, часть на с, там где это невохможно - quarkus.
Spring boot стал de-facto legacy.

Для in-house разработки, может это и не было проблемой, но приходится конскурировать с теми, у кого "микросервис" не стартует пару минут и не потребляет 250 Mb памяти на поду только на фреймворк. Т.е. это вопрос продаж а не cost cutting.

Баги есть у всех, и spring boot в новых версиях тоже приносил ошибки и обратную несовместимость.
Поддерживать все равно прходится самим.

проблемы с кадрами - эксперимент показал, что за две недели разработчик осваивает quarkus c сохранением уровня.
мидл отается мидлом, сеньер - сеньером.

>Может у вас там где-то явный косяк в инфраструктуре/архитектуре

Проблема в самом слабом звене - людях.
Spring boot очень мощный и вариабельный, и позволяет декларативно для run-time стадии описыывать кучу вещей.
Я 100% уверен, что хороший программист, который понимает что стоит за каждой аннотацией, и как она влияет на производительность сможет написать на spring boot сервис, который будет стартовать приемлемо быстро.

Но в "кровавом enterprise", где тысяи разработчиков всегда приходит ОН, разработчик уровня:

>разрабам и так хватает жести с докером и кубернетис ,всеми этими облачными деплоями и тд

Я видел реальный spring-boot код (не могу его показать по юридическим причинам), в котором только в одном Configuraton классе аннотоации занимали целый экран.
- Никто не понимает как это работает
- Никто не может быстро туда внести изменения

Есть известная фраза - хороший фреймворк позволяет легко делать правильные вещи, и тяжело неправильные.
Когда я только узнал о существовании spring (не помню, был это уже 1.0 или нет), он позиционировался как non-intrusive фреймворк. В коде приложения не должно быть упомнинания spring, только внешний DI. И это было очень круто.

Сейчас spring-boot из-за большого количества фич и возможностей просто провоцирует писать приложения, которые стартуют 1-2 минуты, и бороться с этим очень сложно.
Проще выбрать другой фреймворк, в котором тяжелее писать неправильные вещи, или даже другой язык, где не может быть spring из-за особенностей языка.

Наш опыт на наших реальных микросервисах, а не на "сферическом коне в вакууме", показывает улучшение время старта в 10-30 раз на quarkus.
На другой исходной кодовой базе с другими программистами эта пропорция будет другой.