FWIW I would say that PyJulia is still unmaintained ; I wouldn’t want to give the impression that my tiny PRs are anything more than keeping the lights on. juliacall is still highly experimental and has issues with standard Julia features like multithreading (Bus error with multithreading linear algebra · Issue #298 · JuliaPy/PythonCall.jl · GitHub ).
I also want to take this thread to bump my comment here:
Good points @jlapeyre .
To the Julia team: The return-on-investment for well-maintained Python and C++ interoperability is colossal. I can’t emphasize this enough. A couple dedicated maintainers for PyJulia now could bring contributions from hundreds of external engineers for other packages in the future.
When I was working at a FAANG company I chatted with someone researching potential languages to use in the future. I mentioned Julia as an option for high-performance compute, and most of thei…
and
I entirely agree with you. Nobody who uses 100% Julia would have a use-case for this, and if that is who you interact with, it can be hard to see outside the bubble. But most of industry, at least in my area of machine learning, use Python and C++. If they are a well-established company, they would never rewrite their software stack from scratch: they will introduce new languages and libraries gradually, relying on interoperability. So, for Julia even to get its foot in the door there, it requi…
I want to argue that those in charge of Julia funding need to direct some to a dedicated team working on Python interop, rather than relying on community maintenance. I really do not see any other part of Julia development as important as this, with such a large a return on investment.
21 Likes