Hacker News Reader

Comment by paldepind2 | Hacker News Reader

Speaking of bignum libraries, I recently watched a talk with Rob Pike where he mentioned that one thing he regretted about Go was not making the default integer implementation arbitrary precision. Supposedly the performance overhead for normal numbers is very small, and you avoid the weirdness and complicated semantics of fixed precision integers. I found that to be quite fascinating, especially coming from a "low-level guy" like Rob Pike. Ever since I've been wanting a language with that feature and to understand how bignum implementations work.

View on HN

It's a pretty common feature on high-level languages. Python, Ruby, Lisp(s), Haskell, etc, all use arbitrary-precision integers by default. Even JavaScript has integers now (since 2020), not as the default number type, but with the `n` suffix, like `42n`.

That's cool. I didn't realize that those languages used arbitrary-precision integers by default. I know that many language offer a bigint but to me the difference between having bigints and them being the default seems significant. For instance, in JavaScript the `n` notation and them being called `bigint` (and not just `int`) is going to mean that they will get used very rarely.

Yeah i absolutely agree. The saddest cases for me are languages like Java, which comes with working arbitrary-precision integers on its standard library, but using them feels so second-class compared to the "primitive" types like `int`. You need to import the class; initializing a value looks like `var a = new BigInteger("39")`; they don't support normal math operators, so you need to do `a.add(new BigInteger("3"))` just for a simple addition; and so on.

It's difficult to argue that arbitrary-precision integers are "simpler" (because they don't have an overflow edge-case on almost every operation) when they are so much more inconvenient to use.

Common Lisp has been like this forever. It makes testing the language much easier, as you don't have to check for overflows when constructing test code.

A dynamic language like CL has the added requirement that the integers fit with everything else under a single top type, which in practice limits fixnums to a few bits less than the word size.

CL also lets you "switch off" multiple precision if you know you don't need it. You can start with bignums everywhere then declare certain functions to use fixnums after you profile your program to speed it up. Compilers like SBCL can then produce code pretty much as fast as C.

You can write a macro to duplicate a piece of code with different type declarations, and switch between them at entry depending on the types of various values. Code blowup, yes, but you can optimize the common cases without manually duplicating code.

I'm "low-level guy, like Pike", yet I wouldn't have integers any other way in an application language.

Nobody uses Go for ethernet card drivers. Dealing with machine integers is just mental overhead for Go programmers, and a source of bugs.

> I've been wanting a language with that feature

GNU MP's C++ interface makes this mostly transparent, expressions like "x = y * z" just work due to operator overloading. The only time you need to know that the underlying class is "mpz_class" instead of "int" is at input/output.

For what it's worth, Haskell's Integer type is that way.

edit To be clear, in Haskell you 'default' to using its arbitrary-precision type, unlike say Java where they're available in the standard library but not in the core primitive types.

> I've been wanting a language with that feature

Python, which realization CPython is mentioned in the article, has arbitrary precision integers.

Smalltalk is another language that has had this feature since forever.

Tagged pointers / SmallInteger encodings make the memory overhead zero to negligible, and with the CPU / memory-bandwidth gap being what it is, the few extra CPU operations rarely matter.

Daniel Bernstein made the argument that integers should default to these semantics for security reasons:

https://css.csail.mit.edu/6.858/2018/readings/qmail.pdf

Zig isn't quite arbitrary precision, but it supports integer widths up to u65536. I've found this quite handy.

Rexx (EDIT: https://en.wikipedia.org/wiki/Rexx )

eh, I disagree. It's not massive overhead, but it turns literally every integer operation into a branch. Sure the branch is going to get ~100% prediction accuracy if you aren't using bigints, but that's still a pretty big cost especially since the branches inserted make all sorts of compiler optimizations illegal.

Do you remember where you saw that talk? I'd like to watch it.

Thanks.

Yes, the talk is called "What We Got Right, What We Got Wrong" from GopherConAU 2023. It's available on YouTube: https://www.youtube.com/watch?v=yE5Tpp2BSGw

Reply on news.ycombinator.com