Would people like an introduction of a Julia debug mode? Possibly on by default in the REPL/Pluto/Jupyter

[Palli]

Julia has very few misfeatures. There are though a few footguns.

I’m thinking Julia needs a debug mode (if not removing the footguns in 2.0). I’m thinking this debug mode should be on by default on master, both in the REPL and for scripts, e.g. for PgkEval. Every package author would benefit, and should do CI on master.

If the code works in debug mode (does not throw an exception), it would work in regular mode, the one (still) used for scripts; in all released Julia versions.

The big question, to me, is should the debug mode be on in the REPL (also Pluto etc.). It seems like such a gain to know if you’re doing stuff wrong that it should be on even in release versions, but not for scripts, since we want old code to work in all cases.

So what are some examples of footguns that people might want to see detected? I can start by showing two examples:

A.

The speed of light is an integer. Why should we care?

Since 1983, the speed of light is defined to be exactly equal to 299,792,458 meters per second. So, it seems natural to define it as an integer while doing some culculations with Julia, for example, to calculate a Planck’s length. This is how it can be done in Julia REPL: c = 299_792_458; # the speed of light G = 6.67430e-11; # Gravitational constant h = 6.62607015e-34; # Planck's contant h_bar = h / (2*pi); # reduced Planck's constant planks_length = sqrt(G*h_bar/c^3) As a result, we imm…

@gevis

plancks_length = sqrt(G*h_bar/c^3)

As a result, we immediately get 3.5793584153084007e-32 which at first sight is what the Planck’s length should be.

However, Wikipedia says that the Planck’s length is equal to 1.616255e-35.

You probably already realized that the reason for this is the integer overflow that happens when raising c to the power of 3. Moreover, it is easy to fix this redefining c to be a float

You shouldn’t have to define c to a float (it is defined as an integer number), and it would be better to get an overflow error thrown (at least when developing; or even that ^ gives a Float64; or Rational).

The same code in Python (or slightly modified for its syntax gives the right answer).

There is already a PR fixing this (but will not be accepted until 2.0 because it’s a “breaking” change, though arguably helping, and at least perfectly ok for a debug mode):

WIP: Introduce Overflow Checking for ^(::Integer, ::Integer)

[This PR would though only notify you of the problem not fix it, though good enough for a debug mode, returning a Float64 by default would give you the right answer, arguably better. Let’s defer that discussion.]

B.
As with Python (and Lisp), Julia’s zip truncates, which is a known problem in Python (discovered in 2020 when the new non-default option was added to 3.10):

Built-in Functions

By default, zip() stops when the shortest iterable is exhausted.
[…]
Without the strict=True argument, any bug that results in iterables of different lengths will be silenced, possibly manifesting as a hard-to-find bug in another part of the program.

I think we should add such an strict argument, and if the debug mode it should be on by default (arguably also on by default in Julia 2.0).

“New in Python” (in case people think Python will not drop anything until 4.0):

Porting to Python 3.12
Legacy Unicode APIs based on Py_UNICODE* representation has been removed. Please migrate to APIs based on UTF-8 or wchar_t*.

Octal escapes with value larger than 0o377 (ex: “\477”), deprecated in Python 3.11, now produce a SyntaxWarning, instead of DeprecationWarning. In a future Python version they will be eventually a SyntaxError.

and:

sum() now uses Neumaier summation to improve accuracy when summing floats or mixed ints and floats.

[aplavin]

@Palli

The same code in Python (or slightly modified for its syntax gives the right answer).

Numpy does the same as Julia here: both np.int64(123456789)**3 and np.power(123456789, 3) return -2204193661661244627, exactly as Julias 123456789^3. If anything, the difference between builtin slow calculations (with bigintegers) and fast numpy ones are potentially confusing in Python. In Julia, it’s always fast with the same results.