1. 22
  1.  

  2. 2

    Java did the same thing quite early, and it later turned out that it wasn’t worth the trouble.

    Will be interesting whether Golang learns the same lesson as it matures.

    1. 2

      But in Go, many types are simply int with additional methods. No one subclasses Integer in Java. The cases aren’t equivalent at all.

      1. 4

        The need for adding methods to integers would be removed if Go supported an actual enum type. But, you know, enums are a very controversial feature in programming languages so…

        1. 1

          If Go had enums instead of int-valued types, this optimization would work just as well.

          1. 2

            If Go had enums instead of int-valued types, this optimization would work just as well.

            … if the enum used the same strategy as we manually do today. However, it wouldn’t have to, and you could potentially create an enum implementation that out performs this optimization.

            1. 2

              This optimization specifically applies to interface references, which must accommodate all Go types that can implement interfaces. No matter how you choose to implement enums, Go still uses (type, ptr) pairs for interface references, leaving you little room for interesting alternatives.

              You’re also assuming int-valued types are only used for enums in Go, which isn’t true.

              1. 2

                No matter how you choose to implement enums, Go still uses (type, ptr) pairs for interface references, leaving you little room for interesting alternatives.

                At the very least, enum variants are singletons, and can be compared by memory location.

                You’re also assuming int-valued types are only used for enums in Go, which isn’t true.

                Off hand, I know of two other uses. time.Duration uses an int, and this obviously could be done similarly by extending java.lang.Integer if you wanted… but, I digress. There’s likely a family of types similar to this use case… The other is as a key for context.Value, which is strangely an enum of a single variant.

                Personally, I’d rather the Duration case be implemented another way, but that’s just me.

                1. 1

                  At the very least, enum variants are singletons, and can be compared by memory location.

                  That is the exact result of this change.

                  and this obviously could be done similarly by extending java.lang.Integer if you wanted

                  But no one does, which was my entire point.

                  1. 1

                    That is the exact result of this change.

                    No. It’s literally not. The change does {type, pointer to singleton int value}. With enums, you could have Green = &{colorEnumType, greenInt}

                    1. 1

                      Also, done with this site.

                      1. 3

                        Well, that was unexpected.

                      2. 1

                        Comparing the full pair by pointer value does nothing, as anything in Go expecting an interface expects the full pair, not the pointer value. When not passed as an interface, the compiler has its type, it’s not runtime tagged, and thus compared directly by value. Your suggestion provides no utility.

          2. -2

            No one subclasses Integer in Java.

            Probably because the class is final? (Jeez. Have Go fans always live up to their reputation?)

            The cases aren’t equivalent at all.

            Java caches small integer values. Golang caches small integer values.

            1. 6

              I’m aware Integer is final, hence no one subclasses it.

              I meant that defining types as int is common in Go. Hence those interned values will likely be used significantly more than interned Integer values in Java. Declaring the optimization pointless by drawing a false equivalency makes no sense.

              Jeez. Have Go fans always live up to their reputation?

              Don’t be an ass.

              1. 1

                I can really recommend reading the article – I think it would greatly help you to clear up your misperceptions.

                Don’t be an ass.

                If you decide arguing about an article you haven’t read, at least try not being wrong.

                1. 3

                  I did read the article. I also read the linked patch implementing the change.

                  If you want to disagree with my position, then you argue that Go types are effectively never defined as int. This is wrong, therefore you would be wrong.

                  However it sounds more like you have no idea what I’m saying, hence your comment restating the extremely obvious:

                  Java caches small integer values. Golang caches small integer values.

                  Only the proper term in this instance is interning.

                  Lobsters frowns upon mud-slinging, so I am excusing myself from this conversation before I get dragged too far into the mud.