StatsBase.jl VS StaticLint.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.

Yes, tooling around this is being developed in the form of linters (e.g. https://github.com/julia-vscode/StaticLint.jl) and through real compiler integration tools like the very cool https://aviatesk.github.io/JET.jl/dev/ but this is definitely somewhere that the tooling in julia is weaker than in other languages. It seems to be picking up a lot of speed though.

It is correct if `A` is of type `Array` as normal Array in julia has 1-based indexing. It is incorrect if `A` is of some other type which subtypes `AbstractArray` as these may not follow 1-based indexing. But this case errors normally due to bounds checking. The OP talks about the case where even bounds checking is turned off using `@inbounds` for speed and thus silently giving wrong answers without giving an error.

An issue was created sometime ago in StaticLint.jl to fix this: https://github.com/julia-vscode/StaticLint.jl/issues/337

Statically lint = find errors in the Julia file like using variables that are not defined, and functions with the wrong arguments. For Julia, StaticLint.jl is an actively developed library that does static linting. It basically provides a bunch of functions that spit out errors in your Julia file like those that I mentioned above. If you are an Emacs editor user, this project is like a "convenience" which will run Julia silently in the background, and communicate with it to extract errors in the file that you currently have open. These errors are then highlighted in your editor view using the Flycheck package that is one of the ways to highlight errors in Emacs.