3 ms·
I think you may have missed the thrust of the earlier comment (which is that some developers may elect to never use libraries that use generics, whereas some de
by striking 6y ago
I think you may have missed the thrust of the earlier comment (which is that some developers may elect to never use libraries that use generics, whereas some developers may prefer libraries that use generics, and it could cause a schism in the community without being a necessarily language-level-breaking change), but it's also worth noting that Go absolutely has broken tooling through a language update in the past (https://github.com/golang/go/issues/24661 https://github.com/golang/go/issues/24661) and just generally does not have a particularly great history or coherent philosophy of good versioning practices and as such we should not just assume stability or backwards compatibility where there may not be any.
- tptacek 6y agoWhat's a major Go project that had to be ported, or maintained in two separate versions or branches, in order to target two different versions of the Go language itself? I don't think the Python comparison is particularly apt, whatever our other concerns about Go stability might be.