8 ms·
In practice I suspect this will lead to a Python 2/3-like fork in codebases, given the amount of electrons and emotions poured into the topic so far.
by jacques_chester 6y ago
In practice I suspect this will lead to a Python 2/3-like fork in codebases, given the amount of electrons and emotions poured into the topic so far.
- tptacek 6y agoHow do you figure? Python 3 isn't compatible with Python 2.
- striking 6y agoI think that's the point of the reply, that we'll get codebases that aren't mutually compatible due to a resistance of or lean towards using generics. I'm not so certain that that's the case, but it is an interesting position nonetheless.
- Thaxll 6y agoThere is no such thing in Go since the language / runtime is very stable / backward compatible.
- striking 6y agoI 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.
- deleted 6y ago[deleted]
- jacques_chester 6y agoIn a social/cultural sense, rather than a purely technical sense. Old Busted C++ vs Modern C++ might have been a better example. Pre-generic and post-generic codebases will likely play awkwardly together, with lots of boxing between generics and interface{}. Folks who prefer generics will start to wrap or recreate popular existing libraries in the generic style. It'll be a constant drag on everything. Of course I may be wrong and the community might embrace the proposal whole-heartedly. But I won't hold my breath. Dismissing generics has been a gopher shibboleth for years and years.