Hacker News Reader

Comment by neillyons | Hacker News Reader

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.

View on HN

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.

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/

This was a nice enhancement with very few drawbacks, but I can see how it wouldn't necessarily be appropriate in Go.

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

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

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.

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.

Reply on news.ycombinator.com