StatsBase.jl VS Optimization.jl

so finally I tried running Pkg.add(Pkg.PackageSpec(url="https://github.com/JuliaStats/StatsBase.jl", rev="v0.24.0")) but encountered an error saying in needed to download dependencies like DataStructures.

The author identified some bugs and those were fixed. But they were all edge cases or footguns that are obviously bad to do, but allowed because Julia is a flexible language. For example, in this issue, the author overwrites the array they are sampling from. Which is obviously going to produce bad results.

Well, out of the issues mentioned, the ones still open can be categorized as (1) aliasing problems with mutable vectors https://github.com/JuliaLang/julia/issues/39385 https://github.com/JuliaLang/julia/issues/39460 (2) not handling OffsetArrays correctly https://github.com/JuliaStats/StatsBase.jl/issues/646, https://github.com/JuliaStats/StatsBase.jl/issues/638, https://github.com/JuliaStats/Distributions.jl/issues/1265 https://github.com/JuliaStats/StatsBase.jl/issues/643 (3) bad interaction of buffering and I/O redirection https://github.com/JuliaLang/julia/issues/36069 (4) a type dispatch bug https://github.com/JuliaLang/julia/issues/41096

So if you avoid mutable vectors and OffsetArrays you should generally be fine.

As far as the argument "Julia is really buggy so it's unusable", I think this can be made for any language - e.g. rand is not random enough, Java's binary search algorithm had an overflow, etc. The fixed issues have tests added so they won't happen again. Maybe copying the test suites from libraries in other languages would have caught these issues earlier, but a new system will have more bugs than a mature system so some amount of bugginess is unavoidable.

Interesting response. I develop the Julia SciML organization https://sciml.ai/ and we'd be more than happy to work with you to get wrappers for PRIMA into Optimization.jl's general interface (https://docs.sciml.ai/Optimization/stable/). Please get in touch and we can figure out how to set this all up. I personally would be curious to try this out and do some benchmarks against nlopt methods.

There are also Optimization and Nonconvex , which seem like umbrella packages and I am not sure what methods to use inside these packages. Any help on these?

> but would you say most packages follow or enforce SemVer?

The package ecosystem pretty much requires SemVer. If you just say `PackageX = "1"` inside of a Project.toml [compat], then it will assume SemVer, i.e. any version 1.x is non-breaking an thus allowed, but not version 2. Some (but very few) packages do `PackageX = ">=1"`, so you could say Julia doesn't force SemVar (because a package can say that it explicitly believes it's compatible with all future versions), but of course that's nonsense and there will always be some bad actors around. So then:

> Would enforcing a stricter dependency graph fix some of the foot guns of using packages or would that limit composability of packages too much?

That's not the issue. As above, the dependency graphs are very strict. The issue is always at the periphery (for any package ecosystem really). In Julia, one thing that can amplify it is the fact that Requires.jl, the hacky conditional dependency system that is very not recommended for many reasons, cannot specify version requirements on conditional dependencies. I find this to be the root cause of most issues in the "flow" of the package development ecosystem. Most packages are okay, but then oh, I don't want to depend on CUDA for this feature, so a little bit of Requires.jl here, and oh let me do a small hack for OffSetArrays. And now these little hacky features on the edge are both less tested and not well versioned.

Thankfully there's a better way to do it by using multi-package repositories with subpackages. For example, https://github.com/SciML/GalacticOptim.jl is a global interface for lots of different optimization libraries, and you can see all of the different subpackages here https://github.com/SciML/GalacticOptim.jl/tree/master/lib. This lets there be a GalacticOptim and then a GalacticBBO package, each with versioning, but with tests being different while allowing easy co-development of the parts. Very few packages in the Julia ecosystem actually use this (I only know of one other package in Julia making use of this) because the tooling only recently was able to support it, but this is how a lot of packages should be going.

The upside too is that Requires.jl optional dependency handling is by far and away the main source of loading time issues in Julia (because it blocks precompilation in many ways). So it's really killing two birds with one stone: decreasing package load times by about 99% (that's not even a joke, it's the huge majority of the time for most packages which are not StaticArrays.jl) while making version dependencies stricter. And now you know what I'm doing this week and what the next blog post will be on haha.