I would like to know what is the current state of using Julia as a backend for an R package. I writing a code for a statistical model, but I aware that most of the people will use R to run those analysis so I would like to know if is possible now days to have a R package with Julia running in the backend.
If is not possible, at the moment so it might not be worth the pay off of trying to implement in Julia from the scratch.
There was some development of compiling Julia code to small binaries which R can then call. It was in another thread. I expect to see development over the next 2 years or so
It’s already possible to call Julia from R (as other have suggested for package development), and done, and note also RCall.jl for calling in other direction, with its R mode.
Note also:
And upcoming juliac compiler will likely make this even more compelling, but it’s strictly not needed, current tools good enough.
I think everything is handled with this dual Julia/Python binding package
That PythonCall package is of course Python specific, but it relies on CondaPkg.jl which isn’t. I’m not sure, maybe, probably, it helps for R users installing Julia dependencies?
See this thread. With the work that has gone into small binary compilation of Julia code, it now seems possible to create a dynamic library that you can just call in R. You may want to reach out to the authors there to see if you can help with this.
As described in that paper, the R package fwildclusterboot uses the Julia package WildBootTests.jl as a back end. For some problems the Julia backend is optional (but faster). For others, it is required. The Stata package boottest can use the same back end.
For sure, once juliac is more official, I’ll try to move to that so that users need not install Julia.
I am expecting juliac built small binaries to work for this purpose by Julia 1.12, but no later than Julia 1.13. Probably, we’ll need some tooling to then make it all work well together.
which will invoke install_julia automatically if Julia is not found and also do initialization of JuliaCall.
I don’t know if there are any problems, if it’s as smooth as calling Julia from Python (PythonCall.jl can also install Python automatically) using that other package with same name:
JuliaCall manages its Julia dependencies using JuliaPkg. It will automatically download a suitable version of Julia if required.
Package ‘fwildclusterboot’ was removed from the CRAN repository.
Formerly available versions can be obtained from the archive.[that’s a link at target, that didn’t copy-paste.]
Archived on 2024-05-29 as issues were not corrected in time.
[Note, in Julia you can’t remove packages from the index, that would be a security irsk, as happened for JavaScript…]
Yes, as @ xiaodai says, while ideally Julia installation should be smooth as butter, dependence on it is still a source of fragility. More things can go wrong if Julia is required than if you can just deliver a shared library to the user’s file store. There may also be some speed benefit, at least the first time the library is called in a session.
fwildclusterboot uses the JuliaCall package you referenced, or some comparable package.