4 ms·

Slight tangent, but I recently realised that the built in integer type in Python and Erlang support arbitrary-precision arithmetic while the built in integer ty

Slight tangent, but I recently realised that the built in integer type in Python and Erlang support arbitrary-precision arithmetic while the built in integer types in Go don't. In Go each integer type has a maximum value. eg int32 has a max value of 2,147,483,647. You can still perform arbitrary-precision arithmetic in Go but it requires using the math/big library.

foota 6y ago
This isn't that surprising to me since go is built for c like performance.
OskarS 6y ago
That's the case for almost all programming languages, Python and Erlang (and a few others, like Raku) are the exceptions there. Any language that's made to be at least a little bit performant (C, C++, Rust, Go, Java, C#, and many, many others) works like this.
leecarraher 6y ago
I think this may comes down to interpreted vs compiled. Compiled language assumes some hardware instruction that interacts with primitives at some point. Where interpreted languages are using subroutines to deal with every object. So why not have a check if the value is in bounds, and if not, use arbitrary precision.
marktangotango 6y ago
Concretely, it’s because an int is generally defined as 4 bytes and with a sign bit the remaining 31 can have values 2^31.
SloopJon 6y ago
In Python 2, int and long were separate types, where int was either a 32- or 64-bit signed integer, and long was arbitrary precision. Python 3 unified the types under the name int: https://www.python.org/dev/peps/pep-0237/ https://www.python.org/dev/peps/pep-0237/ This was a nice enhancement with very few drawbacks, but I can see how it wouldn't necessarily be appropriate in Go.
- neillyons 6y ago
  That is super interesting. I programmed in Python 2 for a good six years and didn't know it had a long type! >>> type(1) <type 'int'> >>> type(1111111111111111111111111111111111111111111111111111111111111) <type 'long'>

foota 6y ago

This isn't that surprising to me since go is built for c like performance.

OskarS 6y ago

That's the case for almost all programming languages, Python and Erlang (and a few others, like Raku) are the exceptions there. Any language that's made to be at least a little bit performant (C, C++, Rust, Go, Java, C#, and many, many others) works like this.

leecarraher 6y ago

I think this may comes down to interpreted vs compiled. Compiled language assumes some hardware instruction that interacts with primitives at some point. Where interpreted languages are using subroutines to deal with every object. So why not have a check if the value is in bounds, and if not, use arbitrary precision.

marktangotango 6y ago

Concretely, it’s because an int is generally defined as 4 bytes and with a sign bit the remaining 31 can have values 2^31.

SloopJon 6y ago

In Python 2, int and long were separate types, where int was either a 32- or 64-bit signed integer, and long was arbitrary precision. Python 3 unified the types under the name int: https://www.python.org/dev/peps/pep-0237/ https://www.python.org/dev/peps/pep-0237/ This was a nice enhancement with very few drawbacks, but I can see how it wouldn't necessarily be appropriate in Go.

neillyons 6y ago
That is super interesting. I programmed in Python 2 for a good six years and didn't know it had a long type! >>> type(1) <type 'int'> >>> type(1111111111111111111111111111111111111111111111111111111111111) <type 'long'>