The average Julia coder today has a local installation of Julia, downloads packages of source code, precompiles package-specified call signatures for a particular environment of versioned packages and Julia, and JIT-compiles other evaluated source code on demand. AOT compilation of binaries and standalone deployment is far less mature, though it obviously has its places so there’s a lot of interest or active development.
I don’t know all (or maybe most of) the ways to do GUIs over Julia code, but it typically involves scripts and web apps. Some interactive graphics are also often done with some plotting libraries and notebooks. As you’ve linked, it’s possible to use PackageCompiler.jl to deploy a standalone GUI app, but that’s relatively rarer for now.
There are many good reasons for that, which you have somewhat brought up.
-
Even if you don’t run into some of the rough edges, PackageCompiler products are often too big. It bundles the Julia runtime (which lets users not have to install it themselves), the packages, and whatever you specified for precompilation. That is far less than “access to the whole…ecosystem”, but it’s already a pain to distribute and can’t fit in some contexts like Arduino microcontrollers. Arbitrary
evaland JIT compilation isn’t necessary to print “hello world”, but a Julia process can’t tell even if provided a script that only containsprintln("hello world"). -
The obviously follow-up idea is to ditch interactivity and bundle minimal code. That is exactly the trimming option of juliac, the upcoming successor to PackageCompiler. Until it comes out and further develops, we don’t know how it’ll do trimming or how well, but there’s no fundamental difference from familiar executables and shared libraries. Trimming costing functionality is not an alarming limitation; if you want your binary to just take up 1-2MB, you really don’t want the full Julia runtime around or compile arbitrarily more code. That will limit how we write the source code as well; for one example, we’ll have to specify all the code to compile ahead-of-time and remove runtime dispatches that try to JIT compile. If you don’t want those limitations, juliac defaults to no trimming, like PackageCompiler.
-
We don’t have cross-compilation of Julia code for different OSs and CPUs yet. As far as I’ve read, it’s technically possible but needs significant work; linking a much better comment from last year. This doesn’t really concern the typical workflow of locally compiling code on demand in varying package environments, so this work will probably need juliac to develop a bit. Cross-compilation is routinely used to run supportable Julia on GPUs, but that doesn’t amount to the same thing.
So while you can do some of the things you want, the Julia ecosystem isn’t as capable or mature as others. If you’re just curious and would like to witness the developments, that’s no problem. If you need to do real work, you need to consider how Julia is used in practice. I wouldn’t really know, but there does seem to be people using Julia on some level for modeling and simulation. Ask around, look at what they do, and see if that can benefit your own job.
The two-language problem doesn’t assert using >1 language is fundamentally bad, and as far as I know, no language has ever aspired to be the only useful one. Julia’s own core is written in C, many Julia packages wrap binaries compiled (and cross-compiled) from other languages, and there are a few packages for interop with other interactive languages like Python and R. The problem is developing in a more convenient, often interactive language then reimplementing in another language to perform efficiently enough in practice, and Julia doesn’t prevent that in all circumstances e.g. microcontrollers. Writing Julia to do one thing and Python to do another in cooperation is not the two-language problem. Writing Python that already performs nearly optimally because >90% of the executed code was compiled from C is not the two-language problem.