diffeqpy VS ModelingToolkitStandardLibrary.jl

With Python you have to write packages in some other language anyways, so you might as well do that with Julia. One of the reasons for getting all of this precompilation going is to eventually ship precompiled system images with things like https://github.com/SciML/diffeqpy, effectively using Julia as a replacement for where C/Fortran is traditionally used there. If I can make that pipeline smooth, then I think Julia as a Python package building source will be a good option for a lot of folks. Right now it's a very manual, but it could easily improve with a bit of tooling.

10-100x speed increase was not an exaggeration for me. With julia I was able to run things quickly on my own machine which I had been running on a compute cluster. I agree that numba could be just as fast as julia. I also just saw that you can run that DE library from julia that I like so much from python using this package. https://github.com/SciML/diffeqpy

I see, yes, RigidBodySim is in a bit of a bad place since Twan and Robin spend all of their time doing "real robotics projects" now (they are both at Boston Dynamics). I think it's fine though, since I don't think that that is the right implementation anymore anyways. Robotics simulators like Drake, (Diff)Taichi, MuJoCo, etc. end up numerically unstable when trying to model real physics, which is why still the big industrial simulations use Dymola. This is why these days it's all going the route of ModelingToolkit. MTK plus a differentiable simulator (DifferentialEquations.jl) already runs circles around MuJoCo and DiffTaichi, it just needs to complete its library to make building rigid body simulations a lot simpler. Once the mechanical components portion of the ModelingToolkit Standard Library is completed, we plan to demonstrate some things like control of UAVs and such. That's all slated for this year (and is connected to some things going on in JuliaSim), in which case I think we'll be in a much better state for this domain.

The thing to watch in the space of Simulink/Modelica is https://github.com/SciML/ModelingToolkit.jl . It's an acausal modeling system similar to Modelica (though extended to things like SDEs, PDEs, and nonlinear optimization), and has a standard library (https://github.com/SciML/ModelingToolkitStandardLibrary.jl) similar to the MSL. There's still a lot to do, but it's pretty functional at this point. The two other projects to watch are FunctionalModels.jl (https://github.com/tshort/FunctionalModels.jl, which is the renamed Sims.jl), which is built using ModelingToolkit.jl and puts a more functional interface on it. Then there's Modia.jl (https://github.com/ModiaSim/Modia.jl) which had a complete rewrite not too long ago, and in its new form it's fairly similar to ModelingToolkit.jl and the differences are more in the details. For causal modeling similar to Simulink, there's Causal.jl (https://github.com/zekeriyasari/Causal.jl) which is fairly feature-complete, though I think a lot of people these days are going towards acausal modeling instead so flipping Simulink -> acausal, and in that transition picking up Julia, is what I think is the most likely direction (and given MTK has gotten 40,000 downloads in the last year, I think there's good data backing it up).

And quick mention to bring it back to the main thread here, the DataDrivenDiffEq symbolic regression API gives back Symbolics.jl/ModelingToolkit.jl objects, meaning that the learned equations can be put directly into the simulation tools or composed with other physical models. We're really trying to marry this process modeling and engineering world with these "newer" AI tools.