5 ms·

This is a common theme with criticisms of Go. Relative amateurs assuming that the people who work on Go know less about programming languages than themselves,

This is a common theme with criticisms of Go. Relative amateurs assuming that the people who work on Go know less about programming languages than themselves, when in almost all cases they know infinitely more. The amateur naively assumes that whichever language packs in the most features is the best, especially if it includes their personal favorites. The way an amateur getting into knife making might look at a Japanese chef's knife and find it lacking. And think they could make an even better one with a 3D printed handle that includes finger grooves, a hidden compartment, a lighter, and a Bluetooth speaker.

throwawaymaths 1y ago
To be fair there are lots of people who have used multiple programming languages at expert levels that complain about go - in the same ways - as well! They might not be expert programming language designers, but they have breadth of experience, and even some of them have written their own programming languages too. Assuming that all complainants are just idiots is purely misinformed and quite frankly a bit of gaslighting.
- philosophty 1y ago
  "To be fair there are lots of pilots who have flown multiple aircraft at an expert level that complain about the Airbus A380 - in the same ways - as well! They might not be expert airplane designers, but they have a breadth of experience, and even some of them have created their own model airplanes too." Yes, non-experts can have valid criticisms but more often than not they're too ignorant to even understand what trade-offs are involved.
  - throwawaymaths 1y ago
    see there you go again assuming. im talking about people who have written programming languages that are used in prod with millions of users, not people with toy languages. is the entire go community this toxically ignorant?
    - philosophty 1y ago
      You said nothing that indicates you were referring to other expert language designers. This entire thread is full if amateurs making ignorant comments. So what expert criticisms are you referring to? You accused me of "gaslighting" and being "toxically ignorant" while I have been entirely civil.
Yoric 1y ago
FWIW, I have designed several programming languages and I have contributed (small bits) to the design of two of the most popular programming languages around. I understand many of Go's design choices, I find them intellectually pleasing, but I tend to dislike them in practice. That being said, my complaints about Go's error-handling are not the `if err != nil`. It's verbose but readable. My complaints are: 1. Returning bogus values alongside errors. 2. Designing the error mechanism based on the assumptions that errors are primarily meant to be logged and that you have to get out of your way to develop errors that can actually be handled.
- kiitos 1y ago
  > Returning bogus values alongside errors. Unless documented otherwise, a non-nil error renders all other return values invalid, so there's no real sense of a "bogus value" alongside a non-nil error. > Designing the error mechanism based on the assumptions that errors are primarily meant to be logged and that you have to get out of your way to develop errors that can actually be handled I don't see how any good-faith analysis of Go errors as specified/intended by the language and its docs, nor Go error handling as it generally exists in practice, could lead someone to this conclusion.
  - packetlost 1y ago
    > Unless documented otherwise, a non-nil error renders all other return values invalid, so there's no real sense of a "bogus value" alongside a non-nil error But you have to return something to satisfy the function signature's type, which often feels bad. >> Designing the error mechanism based on the assumptions that errors are primarily meant to be logged and that you have to get out of your way to develop errors that can actually be handled > I don't see how any good-faith analysis of Go errors as specified/intended by the language and its docs, nor Go error handling as it generally exists in practice, could lead someone to this conclusion. I agree to a point, but if you look at any random Go codebase, they tend to use errors.New and fmt.Errorf which do not lend themselves to branching on error conditions. Go really wants you to define a type that you can cast or switch on, which is far better.

throwawaymaths 1y ago

To be fair there are lots of people who have used multiple programming languages at expert levels that complain about go - in the same ways - as well! They might not be expert programming language designers, but they have breadth of experience, and even some of them have written their own programming languages too. Assuming that all complainants are just idiots is purely misinformed and quite frankly a bit of gaslighting.

philosophty 1y ago
"To be fair there are lots of pilots who have flown multiple aircraft at an expert level that complain about the Airbus A380 - in the same ways - as well! They might not be expert airplane designers, but they have a breadth of experience, and even some of them have created their own model airplanes too." Yes, non-experts can have valid criticisms but more often than not they're too ignorant to even understand what trade-offs are involved.
- throwawaymaths 1y ago
  see there you go again assuming. im talking about people who have written programming languages that are used in prod with millions of users, not people with toy languages. is the entire go community this toxically ignorant?
  - philosophty 1y ago
    You said nothing that indicates you were referring to other expert language designers. This entire thread is full if amateurs making ignorant comments. So what expert criticisms are you referring to? You accused me of "gaslighting" and being "toxically ignorant" while I have been entirely civil.

Yoric 1y ago

FWIW, I have designed several programming languages and I have contributed (small bits) to the design of two of the most popular programming languages around. I understand many of Go's design choices, I find them intellectually pleasing, but I tend to dislike them in practice. That being said, my complaints about Go's error-handling are not the `if err != nil`. It's verbose but readable. My complaints are: 1. Returning bogus values alongside errors. 2. Designing the error mechanism based on the assumptions that errors are primarily meant to be logged and that you have to get out of your way to develop errors that can actually be handled.

kiitos 1y ago
> Returning bogus values alongside errors. Unless documented otherwise, a non-nil error renders all other return values invalid, so there's no real sense of a "bogus value" alongside a non-nil error. > Designing the error mechanism based on the assumptions that errors are primarily meant to be logged and that you have to get out of your way to develop errors that can actually be handled I don't see how any good-faith analysis of Go errors as specified/intended by the language and its docs, nor Go error handling as it generally exists in practice, could lead someone to this conclusion.
- packetlost 1y ago
  > Unless documented otherwise, a non-nil error renders all other return values invalid, so there's no real sense of a "bogus value" alongside a non-nil error But you have to return something to satisfy the function signature's type, which often feels bad. >> Designing the error mechanism based on the assumptions that errors are primarily meant to be logged and that you have to get out of your way to develop errors that can actually be handled > I don't see how any good-faith analysis of Go errors as specified/intended by the language and its docs, nor Go error handling as it generally exists in practice, could lead someone to this conclusion. I agree to a point, but if you look at any random Go codebase, they tend to use errors.New and fmt.Errorf which do not lend themselves to branching on error conditions. Go really wants you to define a type that you can cast or switch on, which is far better.