4 ms·

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

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.

MaxBarraclough 2y ago
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.
vient 2y ago
> I've been wanting a language with that feature Python, which realization CPython is mentioned in the article, has arbitrary precision integers.
omoikane 2y ago
> 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.
pfdietz 2y ago
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.
- globular-toast 2y ago
  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.
  - pfdietz 2y ago
    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.
nsguy 2y ago
Rexx (EDIT: https://en.wikipedia.org/wiki/Rexx https://en.wikipedia.org/wiki/Rexx )
mpweiher 2y ago
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 https://css.csail.mit.edu/6.858/2018/readings/qmail.pdf
epidemian 2y ago
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`.
- paldepind2 2y ago
  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.
  - epidemian 2y ago
    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.
deleted 2y ago
[deleted]
kazinator 2y ago
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.
aag 2y ago
Do you remember where you saw that talk? I'd like to watch it. Thanks.
- paldepind2 2y ago
  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 https://www.youtube.com/watch?v=yE5Tpp2BSGw
adgjlsfhk1 2y ago
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.
- deleted 2y ago
  [deleted]
samatman 2y ago
Zig isn't quite arbitrary precision, but it supports integer widths up to u65536. I've found this quite handy.

MaxBarraclough 2y ago

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.

vient 2y ago

> I've been wanting a language with that feature Python, which realization CPython is mentioned in the article, has arbitrary precision integers.

omoikane 2y ago

> 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.

pfdietz 2y ago

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.

globular-toast 2y ago
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.
- pfdietz 2y ago
  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.

nsguy 2y ago

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

mpweiher 2y ago

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 https://css.csail.mit.edu/6.858/2018/readings/qmail.pdf

epidemian 2y ago

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`.

paldepind2 2y ago
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.
- epidemian 2y ago
  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.

deleted 2y ago

[deleted]

kazinator 2y ago

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.

aag 2y ago

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

paldepind2 2y ago
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 https://www.youtube.com/watch?v=yE5Tpp2BSGw

adgjlsfhk1 2y ago

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.

deleted 2y ago
[deleted]

samatman 2y ago

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