[asdfologist]

People here keep bemoaning the golang designers' decision to not upgrade their language with things like generics, but suddenly their panties get twisted in a bunch when the Python community actually decides to fix problems in their language.

Get off your high horse and upgrade your code. So many people did it before you, and so can you.

[BigJono]

Meanwhile in Javascript land, if your code is a year old you're already running out of prospective hires that are familiar enough with the language to maintain it haha.

[netheril96]

If Go upgrades itself with support with generics but break backwards compatibility in a horrible way and the breaks cannot be caught at compile time, people will be complaining and resisting upgrade just the same.

[Retra]

And what should the Go team do if the only reasonable way to add generics is to break backward compatibility? Just rip the bandage off? Stagnate? Abandon the language and start a new one?

[netheril96]

A key point you ignore in my comment is the "caught at compile time" part. If generics breaks backward compatibility, but the breaks can be caught at compile time, upgrading a medium codebase may take only an afternoon, and that would be reasonable commitment. Huge difference from the Python 3 scenario.

[zzzcpan]

Programming languages are not like that. There is an unlimited amount of ways to implement a feature without breaking backward compatibility. Perl, for example, at some point kept compatibility even with bugs, because many people were relying on them.

[Retra]

I don't understand this at all. Yes, you can add features, but if they are not ergonomic, then why bother? For instance, you can't just add features that introduce syntactic ambiguity or change your parser to become context sensitive without making the language significantly more complex all around.

Yes, you can add anything without breaking backward compatibility. That's why I qualified it with "reasonable" -- there are very good reasons to break backward compatibility, and being a slave to it will pile up technical debt in very unpleasant and potentially avoidable ways.

It's like trying to make a skyscraper taller without rebuilding the foundation. Sure, you can add giant ugly supports on the side, but once you've done that a few times, nobody is going to feel safe near your building. And no self-respecting architect would do it.

[zzzcpan]

There is nothing stopping you from implementing a feature in a reasonable and ergonomic way without breaking backward compatibility. Programming languages are fun like that. Anything can be done, your imagination is your only limit. And on this level technical debt is not a concern, not even a little. But having good rationale for a feature is, and a huge one. Most of the time the authors themselves don't know why they need it, they just feel like having it.

[shadowmint]

suddenly? you mean 7 years ago?

This is an old pointless fight. :/