I've been looking into Nim for some time and it raised a few questions so far. These questions are relatively abstract, although have direct implementation details. I'm really interested to hear a point on this from seasoned Nim devs.
Here's one case - a mobile game built for iOS with some static functionality (resource management, low-level network implementation details etc.) which is normally compiled AOT. And it also has some dynamic functionality written in Lua (just an example, please don't anchor on Lua), which can be downloaded from server and hot-swapped (special events, mini/micro games, logic updates and minor patching without actual store updates). As iOS doesn't allow for runtime machine code generation, we are bound to using text-based interpreted scripts for this functionality. Another case is hot swapping code for debugging and tighter development loop - when using Haxe for example (please don't anchor on this too, the question has nothing to do with it directly) we can use its bytecode runtime or compilation to JS/Lua to quickly hotswap code when developing and debugging and then compile a final test version to actual machine code so we are still getting performance. If I understand correctly, currently Nim has quite a focus on macros and direct AST manipulations during compile time and thus depends greatly on actual compilation process. Thus there's still (?) no robust REPL for Nim. I also see that there's currently no "core" need in making Nim an interpreted language because it would mean dropping the main selling point of Nim - performance. Of course there's always an option to still use another scripting language separately and write dynamic things there, but I have noticed that Nim also has "only one language in the project" policy (a recent blog post about rendering and using Nim as a shading language is one example), and it would also mean that we can't really prototype and hot-swap core things during development. As I've said, it's somewhat and abstract question, so obvious answers like "continue using what you are using now if it works for you" would serve little purpose. Now here's the question itself - how would you approach to making Nim a scripting + AOT compiled language? Is there is a way to make it "right now" without actual changes to the scope of Nim (we just say that scripting subset can't use macros for example)? If not - what changes to the language (and the compilation process) would be required? If required, how would you approach solving this problem? Thanks for your time, Cheers.
