Thanks to @Benny and @Janis_Erdmanis for your responses; this did fill in some blanks for me. A few comments/responses and I’ll close this off:
The average Julia coder today has a local installation of Julia
This is a good point; part of what I’m looking at is how to broaden the base of Julia developers, and some of those folks may not be here in the forum at this point because the typical workflow doesn’t meet their needs.
juliac, the upcoming successor to PackageCompiler
Will be watching this closely. I think it will be important that this does the best it can while retaining as much of Julia’s base functionality as needed for a given code.
We don’t have cross-compilation of Julia code for different OSs and CPUs yet.
Right, the alternative being bringing along the JIT/AOT infrastructure (for each platform distro) and just compiling on the first run. I need to get smarter on how this works, particularly in an embedding scenario.
The two-language problem doesn’t assert using >1 language is fundamentally bad
True, but if we do require two languages (and environments) to build the logic vs the UI, that’s probably going to dissuade some potential developers.
Writing Julia to do one thing and Python to do another in cooperation is not the two-language problem
Understood, and maximizing interop is a good selling point.
Indeed, Julia does not cross-compile, which can be resolved using continuous deployment services. You may need to deploy your own CI infrastructure
This is a viable strategy in some cases, but may be too complex or expensive in others.
Looking forward to talking to folks about this at JuliaCon!