3 ms·

IMO: The position of "we aren't sure what the right approach to improvement is so we aren't going to do anything" has killed far bigger and more important proje

by 827a 1y ago

IMO: The position of "we aren't sure what the right approach to improvement is so we aren't going to do anything" has killed far bigger and more important projects, companies, and even countries, than Golang. Adapt or die; the world isn't going to wait for you. (I love the Go team, and appreciate everything they do. I'm just sad to see a language I used to love fail to keep pace with many of the other options out there today.)

justin66 1y ago
Go adoption has only increased over time.
- 827a 1y ago
  There's no methodologically sound way to measure its popularity available to most people to make an argument on its popularity one way or the other. That's why I didn't, and that's why you shouldn't either.
  - justin66 1y ago
    If you say so, but the concern you floated (The position of "we aren't sure what the right approach to improvement is so we aren't going to do anything" has killed far bigger and more important projects, companies, and even countries, than Golang. ) is fundamentally silly, given how long Go has been in business and seemingly thriving while applying this approach to a few select, controversial features. If it was going to be killed by this approach, it would now be dead.
MeetingsBrowser 1y ago
Changing too quickly is a much bigger problem. It may not be ideal, but I think leaning towards being slow makes sense in this context. Every person/company using Go chose to use it knowing how errors are handled. Each new way of error handling seems to upset a large number of users, some of which may not have chosen Go had the newer system been in place originally. If it is impossible to know which choice is correct, at least everyone has some baseline level of acceptance for the status quo.
- 827a 1y ago
  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? That's weak.
  - MeetingsBrowser 1y ago
    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?
acedTrex 1y ago
In this particular case the argument seems to be that there is not even consensus improvement is NEEDED. If you cant even agree on that then how do ever hope to agree to a change in the general sense.
arp242 1y ago
> Adapt or die It's not my impression Go is dying. Seems rather overblown. And this "but $other_lang has it! You must have it! Adapt or die!" type of reasoning is how you end up with C++.
- 827a 1y ago
  I never said Go is dying. I said go must adapt, or it will die. That's future-tense. Sure, you can end up with C++ (which is still by some measures the most popular programming language in the world, so that's not a bad place to be). You can also end up with Rust, or Kotlin, or any one of the literally every other programming languages in any ranking's Top 30, all of which have more ergonomic error handling. A better example in the opposite direction is Java: Its a language that spent years refusing to adapt to the ever-changing needs of software engineers. Its legacy now. That is not Go's present, but it is Go's future at its current pace. Still powering a ton of projects, but never talked about except in disdain like "ugh that Go service is such tech debt, can we get time modernize it next sprint". I don't want that for the language.

by 827a 1y ago

justin66 1y ago

Go adoption has only increased over time.

827a 1y ago
There's no methodologically sound way to measure its popularity available to most people to make an argument on its popularity one way or the other. That's why I didn't, and that's why you shouldn't either.
- justin66 1y ago
  If you say so, but the concern you floated (The position of "we aren't sure what the right approach to improvement is so we aren't going to do anything" has killed far bigger and more important projects, companies, and even countries, than Golang. ) is fundamentally silly, given how long Go has been in business and seemingly thriving while applying this approach to a few select, controversial features. If it was going to be killed by this approach, it would now be dead.

MeetingsBrowser 1y ago

Changing too quickly is a much bigger problem. It may not be ideal, but I think leaning towards being slow makes sense in this context. Every person/company using Go chose to use it knowing how errors are handled. Each new way of error handling seems to upset a large number of users, some of which may not have chosen Go had the newer system been in place originally. If it is impossible to know which choice is correct, at least everyone has some baseline level of acceptance for the status quo.

827a 1y ago
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? That's weak.
- MeetingsBrowser 1y ago
  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?

acedTrex 1y ago

In this particular case the argument seems to be that there is not even consensus improvement is NEEDED. If you cant even agree on that then how do ever hope to agree to a change in the general sense.

arp242 1y ago

> Adapt or die It's not my impression Go is dying. Seems rather overblown. And this "but $other_lang has it! You must have it! Adapt or die!" type of reasoning is how you end up with C++.

827a 1y ago
I never said Go is dying. I said go must adapt, or it will die. That's future-tense. Sure, you can end up with C++ (which is still by some measures the most popular programming language in the world, so that's not a bad place to be). You can also end up with Rust, or Kotlin, or any one of the literally every other programming languages in any ranking's Top 30, all of which have more ergonomic error handling. A better example in the opposite direction is Java: Its a language that spent years refusing to adapt to the ever-changing needs of software engineers. Its legacy now. That is not Go's present, but it is Go's future at its current pace. Still powering a ton of projects, but never talked about except in disdain like "ugh that Go service is such tech debt, can we get time modernize it next sprint". I don't want that for the language.