Yes, I agree that Julia could handle the whole stack, but in practice many aspects of robotics stack only have Python and C++ support. ROS 2, the main example we used in the article, does not and will not in the near future have a native Julia “ROS Client Library” that doesn’t rely on PythonCall.jl. There is a lot of type and code generation stuff, all in Python and C++.
Another example, we don’t mention in the article, is GitHub - boston-dynamics/spot-sdk: Spot SDK repo which is one of two interfaces (the other being GitHub - boston-dynamics/spot-cpp-sdk, which as you can tell from the name… is second-class) that exist for The Boston Dynamics Spot robots.
The underlying communication with the robot is some variant of gRPC Protobuf. Julia has some gRPC client library, so if someone figured out how to do that, handling whatever bespoke stuff might be around it, like authentication.
and the only reason people stick to Python is avoiding learning something new, which you euphemistically describe as “avoding disrupting the existing workflow”
Well, yes and no. It’s not just people want to avoid learning something new, (which I think we have to acknowledge does take effort. My coworkers don’t want to avoid learning anything new. The want to learn new things about the things they care about. ). They primarily want to avoid writing more code. There are sorts of code that fall under the category of “some low-level glue stuff”. It’s a matter of perspective.
But once all the relevant calculations have been migrated to well-tested and cleanly written Julia libraries,
I don’t think the article does a good job of touching on this at all, but one thing that I like to try to communicate to people about Julia is “clean”, but I don’t think I ever say “clean”. I try to convey that the package ecosystem has much smaller pieces than the pieces in other languages, because composition is easier. (If there is time, I’ll mention The Lisp Curse). I think the benefits of an all-julia stack are clear for composability, and it is fun to tease Python for lacking this really basic kind of composability, but also is a small example of how “pervasive multiple dispatch” scratches a very important itch. For example: Is Julia's way of OOP superior to C++/Python? Why Julia doesn't use class-based OOP? - #92 by goretkin
Lit makes little sense to keep a thin veneer of Python over it.
The thinner the veneer the better, because language interop is inherently complex and complicated (though really I think language interop between Julia and Python is MUCH better than probably any other combination I have experienced. This is what we meant by “existing workflow”. It’s really a euphemism for “dynamic type languages play together nicely, more than python and c++ do”). And if with little effort you don’t need the veneer at all, then great, get rid of it. But if there is effort in scraping it off, and it truly is just veneer, then I don’t think it is necessarily worth it to get rid of it.
The truth is that it’s not just veneer. It is substantial complexity to have language interop.