Item — HN Reader

Quarkus (and its dependent techs) has been in my radar for a while, and recently I've started using it, and I must say I'm impressed.

Code in modern Java (lamba etc) -> build native Linux exe -> package as Docker image -> deploy in Google Cloud Run. All wiring from CLI so CI/CD friendly (next is to use Google Cloud Build). Since it's native, memory usage small and boot time negligible. Since it's managed, it auto-scales (up and down, to zero cost).

My complaints:

* Quarkus is very opinionated. I'm used to this coming from Google App Engine.

* Building _native_ exe is slow. Like 1995 Java slow.

* Scala support is limited.

If you're used to App Engine, you know exactly the dream I'm living in. Without App Engine's limitations.

2 comments

I had the opposite reaction. They decided to reimplement almost everything and pushing hard on reactive stream, but their documentation is horrendous and the API is super complicated. After a month of tinkering I just gave up and used spring boot.

Please don't use Reactive in Java. Stick to plain imperative - and you'll be compatible with Project Loom in the future.

I don't see how using Reactive makes you incompatible with Project Loom.

I meant using the Reactive API types like using Publiher<Response> in REST APIs. These will be un-necessary in the future.

I almost fall into the same trap. Lucky the documentation for reactive approach is very lacking, and I'm lazy, so I stick with traditional approach.

I think that you have the option with Quarkus to use the traditional JVM with byte code for development, and only generate exe's for stage or production deployment. Best of both worlds.

If my experience with cross platforms (flutter, react native, phonegap, and now quarkus) tells me anything, it's to check everything (still) working everywhere after every small changes :)