> Because they think go needs something better, and if this passes, they'll never get it?
More that they will never get rid of it, even after something better comes along. Same reason Go has been careful about adding generics. There have been many generics proposals over the years. Any one of them – or even all of them – could have been implemented, but all of them had faults that the Go maintainers did not way to forever saddle the language with even when a better way to do generics comes along.
Unfortunately, they saddled the language with the lack of generics, which has a nonzero cost, too.
Worse yet, Go community may develop, or already has, a taste to the lack of genetics. When a really really good proposal comes along, and is implemented, it may produce a Python 2/3 rift with the existing code bases, or not be accepted at all because of this.
I would argue that the definition of a “really really good proposal”, is one that fits in to the language so naturally that such a rift/disagreement would not exist. If you can’t imagine such a proposal, it’s precisely because it is be very hard (maybe impossible) to do this to Go, as it’s written today.
IMO, this is because with generics (and we even get shades of this in error handling), we are running into limits with the type system itself. Coming up with a proposal that’s universally acceptable for generics would probably require a bottom-up (and potentially compatibility-breaking) refactor of the type system. Would that be this worth the effort? Eventually, probably, yes, because you might unlock other benefits for free (compilation time, GC efficiency, etc.).
Today, however, there are many lower hanging & valuable fruit to pluck. In the meantime, new languages with better type systems are invited to capture market share. :)
More that they will never get rid of it, even after something better comes along. Same reason Go has been careful about adding generics. There have been many generics proposals over the years. Any one of them – or even all of them – could have been implemented, but all of them had faults that the Go maintainers did not way to forever saddle the language with even when a better way to do generics comes along.