I don’t mean that physicists never encounter groups, but I think it’s clear that a large majority of the CAS userbase does not directly encounter such objects nor do they need to. Let’s just take a look at the statistics of it. From the reverse dependencies list there’s one package making use of Oscar: SIAN.jl for structural identifiability in ODEs. Since SymbolicUtils.jl already makes use of AbstractAlgebra.jl (yes, we already use some of these tools under the hood), cross-referencing the reverse dependencies list shows the overwhelming vast majority of AbstractAlgebra.jl uses are through SymbolicUtils.jl and Symbolics.jl. The remaining 10% or so reverse dependencies are other CAS tools (Nemo.jl, GrobnerBasis.jl, SymbolicUtils.jl, Symbolics.jl, etc.). So if you just look at the statistics, it seems there’s a major unmet need here.
If you dig around, you see that these tools have been around for years, but if you open up say the RigidBodyDynamics.jl robotics library’s documentation:
you will see that they are using SymPy. If you look at probabilistic programming libraries like Soss.jl, you will see they are making use of SymPy. So even in Julia there seem to be more people making use of SymPy than all of these other symbolic algebra libraries combined times 10, many times not including it as a dependency to the library to avoid the Python deps, only making the problem worse.
We can at each other saying “those uncultured fools should know how to make use of Galois fields in order to do symbolic integration!”, but at the end of the day, they don’t care: they just want to do symbolic integration. Trivializing this aspect does not improve the ecosystem nor does it hit the unmet need, which is why more people use SymPy or Mathematica today than anything else. Given how we are using AbstractAlgebra.jl and hopefully soon Oscar.jl, some of Symbolics.jl is just translating “real CAS’s” to the people. The more we don’t have to write, the better. We’re not in competition with the other groups in Julia, rather we’re hoping to expand their reach.
I hope that is all it is. However, as we know with CAS work, sometimes it ends up not so simple.
Many people are worried that GMP is under GPL, along with SuiteSparse, which is why people are trying to actively remove it from Julia Base. There are quite a few issues and PRs, and forum posts and Slack posts and Zulip posts, etc. In fact, it’s discussed so much it’s almost a meme, so yes, a very non-trivial number of people are worried about it, and for good reasons. This is such a big issue that SuiteSparse was made into a separate package in Julia v1.0 and scheduled to be removed to a package, and there is still an ongoing debate about what to do to finish this.