First, I’m just asking what other people feel or know regarding compared to other languages, say Python or C++.
This one, and BigInt in general isn’t a huge concern, just a talking point:
Another:
I DO see regressions regularly (that’s an understandable part of the development process), and some of them show up into e.g. Julia 1.8.
I’m not complaining about people, people are doing an excellent job, e.g. fixing in 1.8.1.
One argument for inclusion in Julia’s standard library is that Julia should only have what Julia itself needs (e.g. the compiler, and it’s hard for me to see it needs big or irrationals, or LinearAlgebra). Another argument is that having what (most) users want is convenient, and I would also like to get rid of LinearAlgebra module as stdlib, since I don’t use it (always). That in contrast, would be an non-breaking change.
I think by making Julia radically smaller (excision is already an ongoing process), will make for fewer possibilities of regressions. E.g. BigInt (and BigFloat) could no longer be a part of the standard library (but it would be a breaking change requiring Julia 2.0).
Would people oppose needing using Big first for such to work?
There’s an argument for Python to have big included, since it’s the default integer arithmetic, and it’s good that you can opt into that in Julia. But you have to do that, and I’m not sure how many people actually do that. For most it might be ok to rather opt into checked arithmetic which is already available, and much faster.
If e.g. big and LinearAlgebra is not part of Julia, then the release process can be faster, and fixes to those can be faster in packages, not needing to wait for the next major or minor Julia release.
LinearAlgegra has a startup-cost, meaning Julia is barred from the top of some benchmarks (e.g. Debian’s), and affects scripts that need to be fast.
While moving standard libraries has a lot of advantages, this would not be on the top of my list.
Regressions (= new bugs showing up for existing functionality that used to work) are mainly prevented by CI. No test suite covers everything, but for mature code test suites accumulate a lot of tests by accretion.
Whenever a standard library is moved to a package, tests are migrated too.
Your best hope to avoid regressions is to keep adding tests. Unfortunately, coverage reports are misleading with multiple dispatch: some version of a function may have been called, but bugs can be lurking in method combinations that were not tested.