This will always be the case for Julia code, unless you manage to fit the code into the narrow constraints of StaticCompiler. Important functionality such as exceptions, threading, and memory allocation + garbage collection is handled by the runtime.
Interfacing two languages with runtimes is naturally potentially risky since they might have different expectations on how e.g. stacks and signals are handled. Although I have never used it myself I have seen several discussions of that kind of trouble for Javacall.jl and there are traces of that in its README.
If runtime issues can be overcome, the following may, or may not, be of interest.
At work we have a GUI application written in C++ using the QT library. For some use cases we want to call Julia for doing computations but for other use cases we don’t want to depend on Julia at all. The way we implement this is to use dlopen to load Julia on demand. This requires Julia to be installed on the computers where this functionality is used but has no implications on the GUI application itself, apart from a small amount of loading and interfacing code. Importantly users who don’t need the Julia functionality don’t need to have Julia installed and it doesn’t need to be bundled with the application.
Obviously there are a number of non-trivial technical details involved in implementing this. Those are all documented in GitHub - GunnarFarneback/DynamicallyLoadedEmbedding.jl: Embed Julia with dynamical loading of libjulia at runtime.