There are trade-offs using Native Image, for sure. Part of eliminating the JVM is that you won't have the JVM at runtime so you can dynamically load classes. Consequently you need to AOT compile any code you'd dynamically load as well. Release-over-release the tooling and support for dealing with reflection have become more user friendly. More of it is auto-detected during native image build and the remainder can be generated by a runtime agent (at least in my experience). I expect it'll be even easier with the new 25 release.
We've been shipping TruffleRuby as native image builds for years. Other Truffle languages have as well. And it's been quite popular with microservice frameworks. Recently I saw someone on the GraalVM Slack say they AOT compiled a large JavaFX application.
It's work, but probably far less than a rewrite in another language and the tooling is getting better. Obviously I can't speak to your experience, but if you haven't looked at it in a while it might be worth giving newer releases a shot.
Thank you for the insight. It has been a while and now I do want to give it a try again! Maybe it could be nice for small CLI applications instead of using Go.
How is it performance wise? Are there some big things/roadblocks to be aware of?
We've been shipping TruffleRuby as native image builds for years. Other Truffle languages have as well. And it's been quite popular with microservice frameworks. Recently I saw someone on the GraalVM Slack say they AOT compiled a large JavaFX application.
It's work, but probably far less than a rewrite in another language and the tooling is getting better. Obviously I can't speak to your experience, but if you haven't looked at it in a while it might be worth giving newer releases a shot.