3 ms·
Does that kinda throw off the whole concept about pushing language design if you can't do coroutines? That's a pretty critical feature of Lua that somewhat def
by vvanders 10y ago
Does that kinda throw off the whole concept about pushing language design if you can't do coroutines?
That's a pretty critical feature of Lua that somewhat defines it(along with it's low overhead + embeddability, both of with you won't get with the JVM).
It seems like engineers always want to build One Tool to Solve Them All(tm) and yet there are always tradeoffs to be made. The reason 90% of this industry is still employed is because we don't have these one size fits all problems that we'd so love to solve.
- grashalm 10y agoThere was a patch for coroutines on the JVM some time ago. Unfortunatly it did not make it into the platform. No reason why it could not be added to the JVM. SubstrateVM solves the embeddability part.
- vvanders 10y agoInfo out there on SubstrateVM looks a little sparse. For context we use to run VM + tuneable data + game logic code in a 400kb block allocated to Lua on the PSP. I'd love to hear how SubstrateVM compares. Lua has a really rich history of being embedding in some pretty small targets.
- nirvdrum 10y ago400 KB is a very aggressive target. I don't think anything in SubstrateVM would absolutely prohibit that, but currently our images are larger. Some of this is just simply a design trade-off. E.g., in JRuby+Truffle, we've implemented much of the core library in Ruby. This has allowed us to achieve a high level of language compatibility in a fairly short period of time -- implementing 3,000 core library methods in Java would be quite the undertaking. As a consequence, the static binary must include those full Ruby sources (compressed, but they're not in an optimized bytecode format). Having said that, if we wanted to optimize for size over a restricted subset of the language (think mruby), that would be straightforward to do.