Catalyst.jl VS Unityper.jl

ModelingToolkit.jl adds a different spin on this by noting what makes a good modeling system isn't top down but a system that allows for bottom up contributions. ModelingToolkit is built on Symbolics.jl which uses OSCAR.jl etc., so every time the symbolics community gets better ModelingToolkit.jl gets better. It connects to the whole SciML ecosystem, so any improvement to any of the SciML interface packages is directly an improvement to ModelingToolkit.jl. ModelingToolkit is made to be a set of composable compiler abstractions called transformations, so anyone can add new packages that do new transformations that improve the ecosystem. One that I really like is MomentClosure.jl which symbolically transforms stochastic ModelingToolkit models (ReactionSystem) to approximate symbolic ODESystem models of the moments. And there's domain-specific langauges like Catalyst.jl being built on the interface to give more ways to build models, which is spawning the biocommunity to make model importers into the symbolic forms, when then feeds more ODE models into the same compiler. JuliaSim is then building on this ecosystem, adding cloud infrastructure that is special-purpose made for doing parallel computations of these models, automatic symbolic model discovery from data, automatic generation of approximate models with machine learning, and tying the Julia Computing compiler team into the web that is building this ecosystem.

I'm pretty sure it is type instability. The faster way to do this would be with something like https://github.com/YingboMa/Unityper.jl which would fix that. The problem with profiling unstable code in Julia is that it makes everything slow so the profiler will just show a big mess of everything being slow. We do need better resources, but I have no idea what they would like like.