Yeah its really not exciting… but a lot of us have numeric packages that could get 10x more use if they were more accessible in R or Python. And imagine if Rs src directory could contain Julia instead of C++. I know a lot of scientists writing awful C++ because they have to for their hot loops in R.
15 Likes
In addition, It is often the case where you can’t directly switch the language for a large simulation software, and easily callable Julia libraries could greatly help the progressive adoption of Julia.
9 Likes
In (further) addition, for commercial dev using Julia, it can be necessary to be able to provide closed-source piece of software (binaries).
4 Likes
For Apple you would actually need a compiled launcher/entry point if your would like to sign the software. This is however hardly an issue as it is possible to tell a compiled launcher to launch the bash script next to it as I have done so in AppBundler.jl.
2 Likes
It absolutely IS exciting! (IMO) 
Both scenarios, numeric libraries AND e.g. standalone apps with UI, are exciting use cases where Julia currently isn’t well suited.
At least I am excited to see this thread again with some news on this topic 
7 Likes
If you love writing R/Python wrappers for Julia binaries, that’s great 
I do think its really important to make easy numerical binaries from Julia for the majority use-cases in many fields of science, but also not at the cutting edge of anything we do here except that its technically hard.
For me it means pre-bundling some configurable algorithms on a limited set of standard types, like you normally get from a C++ backend in R or Python, just written in Julia. Rather than allowing add-hoc user-defined functions on arbitrary types and total freedom to customise anything - and have it compile at runtime like it’s hand tuned C++. The open-endedness of Julia is what is exciting to me, but I also know its a 10% use case, and the standard stuff is the 90% use case.
10 Likes
I know I’m a bit late to the party, but I’m really following this topic with enthusiasm now since this year’s JuliaCon. I work in the field of industrial data science, developing apps for engineers/technicians. To me, creating small c-callable Julia binaries that can be easily integrated in other software environments is extremely exciting for a few reasons:
- Engineering principles are broad, but the applications are very different. Flexibility is still non-negotiable if we want to scale, but for harder problems, performance is important too.
- Being able to statically compile Julia to small binaries really reduces the barriers to deployment at the edge where a lot of customers want things to be done, and allows us to more easily protect our I.P. in these applications.
- Being able to statically compile the same Jula code for different top-level types effectively allows us to re-optimize our codebase for different applications with a fraction of the effort for a language like C++.
In the space of industrial data science, the last two points spell significant competitive advantage for anyone adopting Julia vs any other language out there. The open-ended nature of Julia is still really important, but it’s the ability to seamlessly distill that into something that is closed-ended, optimal and deployable for different applications that would make it so powerful. This problem may seem niche, but it’s a very profitable one. I’m really looking forward to more news on this.
32 Likes