# Does Julia have more regressions than other languages? Possible solutions

**URL:** <https://discourse.julialang.org/t/does-julia-have-more-regressions-than-other-languages-possible-solutions/87203>\
**Category:** General Usage\
**Created:** [September 13, 2022, 10:40am UTC](https://discourse.julialang.org/t/does-julia-have-more-regressions-than-other-languages-possible-solutions/87203 "2022-09-13T10:40:24Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 13, 2022, 10:40am UTC](https://discourse.julialang.org/t/does-julia-have-more-regressions-than-other-languages-possible-solutions/87203/1 "2022-09-13T10:40:24Z")

</div>

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:

> <https://github.com/JuliaLang/julia/issues/46665>
>
> It would be great if the following could be fixed for 1.8 (it is working fine on… \<= 1.7).
> 
> \`\`\`julia
> julia\> prod(BigInt\[0, 0\])
> ERROR: InexactError: check\_top\_bit(UInt64, -64)
> Stacktrace:
> \[1\] throw\_inexacterror(f::Symbol, #unused#::Type{UInt64}, val::Int64)
> @ Core ./boot.jl:614
> \[2\] check\_top\_bit
> @ ./boot.jl:628 \[inlined\]
> \[3\] toUInt64
> @ ./boot.jl:739 \[inlined\]
> \[4\] UInt64
> @ ./boot.jl:769 \[inlined\]
> \[5\] convert
> @ ./number.jl:7 \[inlined\]
> \[6\] cconvert
> @ ./essentials.jl:412 \[inlined\]
> \[7\] init2!
> @ ./gmp.jl:143 \[inlined\]
> \[8\] BigInt
> @ ./gmp.jl:56 \[inlined\]
> \[9\] prod(arr::Vector{BigInt})
> @ Base.GMP ./gmp.jl:673
> \[10\] top-level scope
> @ REPL\[1\]:1
> \`\`\`
> The line
> https://github.com/JuliaLang/julia/blob/83658d265d815c15baa199782954598592770230/base/gmp.jl#L672
> looks wrong, in particular the \`unsafe\_load(x.d)\`.
> 
> CC: @rfourquet

Another:

> <https://github.com/JuliaLang/julia/issues/46650>
>
> Discovered when running unit tests on nightly: https://github.com/jagot/MatrixPo…lynomials.jl/runs/8208663752?check\_suite\_focus=true#step:6:123
> 
> Works fine on e.g. Julia 1.8.
> 
> MWE:
> \`\`\`julia
> julia\> versioninfo()
> Julia Version 1.9.0-DEV.1297
> Commit cad4bc58b93 (2022-09-06 09:09 UTC)
> Platform Info:
> OS: macOS (x86\_64-apple-darwin21.4.0)
> CPU: 8 × Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
> WORD\_SIZE: 64
> LIBM: libopenlibm
> LLVM: libLLVM-14.0.5 (ORCJIT, skylake)
> Threads: 1 on 8 virtual cores
> Environment:
> JULIA\_NIGHTLY = /Applications/Julia-0.7.app/Contents/Resources/julia/bin/julia
> 
> julia\> using Test
> 
> julia\> a = rand(ComplexF64, 10)
> 10-element Vector{ComplexF64}:
> 0.5455316396314835 + 0.5871568741825269im
> 0.1711560834205118 + 0.559313023279538im
> 0.08048160770332391 + 0.02144583972400227im
> 0.35451948668119837 + 0.38953512553886116im
> 0.5988634140053631 + 0.9915552588562572im
> 0.8140146155177268 + 0.03465175324289793im
> 0.4024593106930263 + 0.9365910083425163im
> 0.9779762769506364 + 0.21666079958127393im
> 0.8915574012031455 + 0.5310056545199755im
> 0.8216676230864705 + 0.4066094732379455im
> 
> julia\> b = Vector{Number}(a)
> 10-element Vector{Number}:
> 0.5455316396314835 + 0.5871568741825269im
> 0.1711560834205118 + 0.559313023279538im
> 0.08048160770332391 + 0.02144583972400227im
> 0.35451948668119837 + 0.38953512553886116im
> 0.5988634140053631 + 0.9915552588562572im
> 0.8140146155177268 + 0.03465175324289793im
> 0.4024593106930263 + 0.9365910083425163im
> 0.9779762769506364 + 0.21666079958127393im
> 0.8915574012031455 + 0.5310056545199755im
> 0.8216676230864705 + 0.4066094732379455im
> 
> julia\> @test a ≈ b atol=1e-14
> Error During Test at REPL\[21\]:1
> Test threw exception
> Expression: ≈(a, b, atol = 1.0e-14)
> - not defined for ComplexF64
> Stacktrace:
> \[1\] error(::String, ::String, ::Type)
> @ Base ./error.jl:44
> \[2\] no\_op\_err(name::String, T::Type)
> @ Base ./promotion.jl:484
> \[3\] -(x::ComplexF64, y::ComplexF64)
> @ Base ./promotion.jl:487
> \[4\] \_broadcast\_getindex\_evalf
> @ ./broadcast.jl:683 \[inlined\]
> \[5\] \_broadcast\_getindex
> @ ./broadcast.jl:656 \[inlined\]
> \[6\] getindex
> @ ./broadcast.jl:610 \[inlined\]
> \[7\] copy
> @ ./broadcast.jl:912 \[inlined\]
> \[8\] materialize
> @ ./broadcast.jl:873 \[inlined\]
> \[9\] broadcast\_preserving\_zero\_d
> @ ./broadcast.jl:862 \[inlined\]
> \[10\] -(A::Vector{ComplexF64}, B::Vector{Number})
> @ Base ./arraymath.jl:8
> \[11\] isapprox(x::Vector{ComplexF64}, y::Vector{Number}; atol::Float64, rtol::Float64, nans::Bool, norm::typeof(LinearAlgebra.norm))
> @ LinearAlgebra /Applications/Julia-1.9.app/Contents/Resources/julia/share/julia/stdlib/v1.9/LinearAlgebra/src/generic.jl:1772
> \[12\] eval\_test(evaluated::Expr, quoted::Expr, source::LineNumberNode, negate::Bool)
> @ Test /Applications/Julia-1.9.app/Contents/Resources/julia/share/julia/stdlib/v1.9/Test/src/Test.jl:332
> \[13\] top-level scope
> @ /Applications/Julia-1.9.app/Contents/Resources/julia/share/julia/stdlib/v1.9/Test/src/Test.jl:477
> \[14\] eval
> @ ./boot.jl:370 \[inlined\]
> \[15\] eval\_user\_input(ast::Any, backend::REPL.REPLBackend, mod::Module)
> @ REPL /Applications/Julia-1.9.app/Contents/Resources/julia/share/julia/stdlib/v1.9/REPL/src/REPL.jl:152
> \[16\] repl\_backend\_loop(backend::REPL.REPLBackend, get\_module::Function)
> @ REPL /Applications/Julia-1.9.app/Contents/Resources/julia/share/julia/stdlib/v1.9/REPL/src/REPL.jl:248
> \[17\] start\_repl\_backend(backend::REPL.REPLBackend, consumer::Any; get\_module::Function)
> @ REPL /Applications/Julia-1.9.app/Contents/Resources/julia/share/julia/stdlib/v1.9/REPL/src/REPL.jl:233
> \[18\] run\_repl(repl::REPL.AbstractREPL, consumer::Any; backend\_on\_current\_task::Bool)
> @ REPL /Applications/Julia-1.9.app/Contents/Resources/julia/share/julia/stdlib/v1.9/REPL/src/REPL.jl:372
> \[19\] run\_repl(repl::REPL.AbstractREPL, consumer::Any)
> @ REPL /Applications/Julia-1.9.app/Contents/Resources/julia/share/julia/stdlib/v1.9/REPL/src/REPL.jl:357
> \[20\] (::Base.var"#1013#1015"{Bool, Bool, Bool})(REPL::Module)
> @ Base ./client.jl:421
> \[21\] #invokelatest#2
> @ ./essentials.jl:805 \[inlined\]
> \[22\] invokelatest
> @ ./essentials.jl:802 \[inlined\]
> \[23\] run\_main\_repl(interactive::Bool, quiet::Bool, banner::Bool, history\_file::Bool, color\_set::Bool)
> @ Base ./client.jl:405
> \[24\] exec\_options(opts::Base.JLOptions)
> @ Base ./client.jl:322
> \[25\] \_start()
> @ Base ./client.jl:522
> ERROR: There was an error during testing
> \`\`\`

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 13, 2022, 12:05pm UTC](https://discourse.julialang.org/t/does-julia-have-more-regressions-than-other-languages-possible-solutions/87203/2 "2022-09-13T12:05:23Z")

</div>

> [@Palli](#):
>
> I think by making Julia radically smaller (excision is already an ongoing process), will make for fewer possibilities of regressions.

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.