Integer types in current versions of Ruby and Python both have arbitrary precision (as is also true for lots of other languages these days). That's not enough to make either intrinsically bug-free...

python does have bignum integer, but there are subtle things, like if you divide an integer with an integer you get a float, where you do lose precision:

>>>(100000000000000000000000000000000000000000000000000/2+1) % 2 == 0

True

if you want to get an integer you have to use the relatively recent "//" operator:

>>> (100000000000000000000000000000000000000000000000000//2+1) % 2 == 1

True

in smalltalk you'd get a Rational or something like that.

bignum as the default integer is quite common in lots of languages[1]. Notably, Lisp, Scheme, Erlang, Python.

Scheme is a bit interesting in that they have a "numeric tower", which contains rationals and even complex numbers (implementations were free to implement a subset of this tower, at least as far as R5RS, not sure today)

[1] https://en.wikipedia.org/wiki/List_of_arbitrary-precision_ar...

Just to elaborate a bit, in CL, numbers are FIXNUMs by default but are promoted to BIGNUMs if needed. CL also has rational and complex numbers, which it probably got from Scheme but I'm not familiar with that history.

Excel achieves its robustness (and it hardly ever crashes) by protecting the user against arithmetic errors, and circular reasoning. Excel doesn't offer infinite precision arithmetic, that is rarely needed in practice.

Null pointers are something that plagues Java, which are primarily caused by having some computation out of sequence. By using the State-Action-Model pattern, most of Beads code will be devoted to rendering the model on the screen, and that one-way transfer of information can be made very robust, provided you have a closed arithmetic, which it does.

That's definitely one way to solve the issue, but I wouldn't say it's the only way.

In Rust, you can configure Clippy to ban the usage of +-*/ and require explicit behavior of each calculation. For example, 10u8.checked_add(10) returns an Option<> (similar to Maybe in Haskell) so you can handle overflows. You can also use 1u8.saturating_sub(100) which will not allow wraparound but values will saturate at the max/min.