3 ms·
Well you'd only use SubstrateVM when deploying to production, so I don't know why anyone wouldn't want to "worry about that precompilation step". During develop
by ehsanu1 10y ago
Well you'd only use SubstrateVM when deploying to production, so I don't know why anyone wouldn't want to "worry about that precompilation step". During development it should be irrelevant. Or am I missing something here?
- nirvdrum 10y agoIn an ideal world, you'd use the same Ruby for development and production -- you just get more predictable results that way. With SubstrateVM, we're addressing the startup time issue that usually drives a team to have different Ruby implementations in development and production. If you have another use case for split dev/production environments, please let me know. A limitation of the SubstrateVM build is you can't just start calling code in a JAR you load at runtime -- that needs to be built into the image. A common use case for JRuby is as a really awesome shell to Java. You won't have that capability with SubstrateVM because we can't load arbitrary Java code at runtime. Likewise, you couldn't just swap out JARs with different implementations of interfaces on the fly (e.g., JDBC usage patterns). And JRuby can load gems that themselves have Java code in them, which also wouldn't work (setting aside the fact we also don't support their extension API).
- ehsanu1 10y agoThanks, I was confusing myself there. Obviously you would really want to use SubstrateVM in development to get that sweet fast startup - I'm just blind to the startup time angle since I use the zeus gem to keep my application always already started up and fork off new processes as needed. I was considering the case of building a single executable, including the entire ruby application and its dependencies, via SubstrateVM. This could make deployment a lot simpler.