@world-peace, I can no longer quote your post, but to answer you, there’s e.g. this use case:
To a Python developer, SciML is SciPy, but with the high-performance GPU, capabilities of PyTorch, and neural network capabilities, all baked right in. With SciML, there is no “separate world” of machine learning sublanguages: there is just one cohesive package ecosystem.
Performance - The key reason people are moving from SciPy to Julia’s SciML in droves is performance. Even simple ODE solvers are much faster!, demonstrating orders of magnitude performance improvements […]
Package Management and Versioning - Julia’s package manager takes care of dependency management, testing, and continuous delivery in order to make the installation and maintenance process smoother. For package users, this means it’s easier to get packages with complex functionality in your hands.
Composable Library Components - In Python environments, every package feels like a silo. Functions made for one file exchange library cannot easily compose with another. SciML’s generic coding with JIT compilation these connections create new optimized code on the fly and allow for a more expansive feature set than can ever be documented. […]
Easier High-Performance and Parallel Computing - With Julia’s ecosystem, CUDA will automatically install of the required binaries and […] Basically, libraries give you a lot of parallelism for free, and doing the rest is a piece of cake.
Use PyCall.jl to more incrementally move code to Julia.
It seems the docs are a bit outdated, I would not recommend PythonCall.jl rather than PyCall.jl (though both work even together is you’re careful).
You can use SciML alone from Julia (e.g. abandon Python), or you can clal it from Python (or R) with:
That package used to be implemented differently until I suggest julicall/PythonCall.jl. A lot of stuff online is outdated that way (not rather mentioning it):
In the space of symbolic regression, Julia has a clear advantage in terms of support. The most widely adopted library for symbolic regression is SymbolicRegressions.jl [17]. The Python alternative PySR is simply a wrapper for this library, which is in turn a dependency for PyTorch [62].
Here’s an example for a Python package using Julia as a numerical backend: QuanEstimation.
It’s perhaps not the most common use case, but I wouldn’t call it “niche”.
There is always value in being able to call a library in one language from any other language. Not the least of which, simply that that library might implement some very non-trivial algorithm, which you may not want to re-implement in a new language. Presumably, the semantics of the original language were particularly well-suited for the problem at hand, so it may not even be desirable to rewrite it in some other language with less-suitable semantics. Even if time and effort were not a factor.
I have no trouble imagining someone wanting to call the SciML ecosystem from inside C++.
One of the most popular Julia packages (at least early on) is Pyplot.jl, which allows you to interface with matplotlib, through Python. This is a typical example, calling libraries in a different language to get access to specific functionality.
I have called julia from C a couple of times. The reason was that it was much simpler to express the transformations and data generation I needed in julia than in C. Unfortunately I can’t go into any details about that project.
Apologies to all those who were trying to continue the civil discussion here. It appears some people had quite the absurd overreaction to the most harmless comment.
I don’t feel like commenting any further because I don’t want to get banned, but I will just respond to the matplotlib comment because I think I have something beneficial to add here.
Just to say when Julia becomes more established, it might be the case that calling matplotlib directly is no longer required. I’ve always considered this to be a temporary thing. I’m sure someday soon someone will come up with something equally as good, written entirely in Julia.
Apologies to all those who were trying to continue the civil discussion here. It appears some people had quite the absurd overreaction to the most harmless comment.
I don’t feel like commenting any further because I don’t want to get banned, but I will just respond to the matplotlib comment because I think I have something beneficial to add here.
The issue was put into an unlisted thread for a reason, there’s no need to continue harping on and blaming others about it.
Just to say when Julia becomes more established, it might be the case that calling matplotlib directly is no longer required. I’ve always considered this to be a temporary thing. I’m sure someday soon someone will come up with something equally as good, written entirely in Julia.
Makie has already come pretty far for this especially. I wouldn’t say matplotlib is required at all for using Julia for most things (any?) at this point really.
Absolutely, I would not use Pyplot.jl over Makie at all! I just mentioned it as a well-established and known example of a use case for calling into other dynamic languages. And I don’t think the usefulness of doing that will disappear, even though it might be less common.