sbt-revolver VS sbt-native-packager

Another thing to look into is sbt-revolver, this will shorten the turnaround time on whatever machine is running sbt. I remember it being pretty helpful when I was working with scala.js. Good luck!

SBT. It's not because of the pseudo-scala config language, that looks especially alien next to braceless Scala 3 code. Or the weird symbolic operators. The big problem is correctness; in almost every project I've had to use spray-resolver because I've encountered weird bugs because SBT reuses the same dirty JVM. I really thing Drip would help here. I'll keep using SBT because it has the best Scala ecosystem support and great plugins like sbt-crossproject. It would also be great to be able to write build.sbt files in modern, regular Scala.

once you outgrow scala-cli, you should know sbt has a lot of plugins ( some might say it's ecosystem is the only thing keeping it relevant....) like sbt-native-packager which again does the heavy lifting for you

So far, we have been working mainly with projects that use https://github.com/sbt/sbt-native-packager, still, projects building fat jars should also work smoothly.

You should use sbt-jib. (You shouldn't use sbt-native-packager either, it doesn't work well in this regard: [1], [2].)

As others have stated, this is mainly due to the nature of the JVM. You can try using GraalVM however, which basically complies JVM bytecode to native-code avoiding startup time issues, sbt-native-packager lets you do this quite easily.

IMO don't take any of this advice and use https://github.com/sbt/sbt-native-packager