Changing too quickly is not a problem. Changing too quickly can lead to problems.
I don't agree that the problems it leads to are bigger problems than stagnation. I also don't believe they're smaller problems; sorting the problems by size is intractable, as it is situation dependent.
The challenge is in the definition of "too quickly"; if fifteen years of stagnation in addressing more productive error handling is the "right pace" of innovation, or lack-there-of; is twenty years? Thirty years? One hundred years? How do you decide when the time is right? Is the Go team just waiting out the tides of the Vox Populi, and maybe one day a unified opinion from the masses will coalesce?
Is it really fair to say a language is stagnating if it does not re-invent itself every ten years to match whatever language features are popular at the time?
> How do you decide when the time is right?
When people are migrating away from Go because of the error handling.
> maybe one day a unified opinion from the masses will coalesce?
Maybe. What is the alternative? If there are five alternative error handling proposals each with support from 20% of users, should they pick one at random and upset 80% no matter what?
I don't agree that the problems it leads to are bigger problems than stagnation. I also don't believe they're smaller problems; sorting the problems by size is intractable, as it is situation dependent.
The challenge is in the definition of "too quickly"; if fifteen years of stagnation in addressing more productive error handling is the "right pace" of innovation, or lack-there-of; is twenty years? Thirty years? One hundred years? How do you decide when the time is right? Is the Go team just waiting out the tides of the Vox Populi, and maybe one day a unified opinion from the masses will coalesce?
That's weak.