6 ms·

> You're arguing a technicality, which is a waste of time. We should focus on reality, not imaginary theoretical issues. In reality, that never happens. And peo

> You're arguing a technicality, which is a waste of time. We should focus on reality, not imaginary theoretical issues. In reality, that never happens. And people even develop linters (frankly unnecessary) to guarantee it, if you're really paranoid. Because you aren't? you're projecting. > This is a social problem, influenced by language design. You need to be thinking about the way humans actually behave in practice, not how they theoretically might behave. Sure, your problem with Java is also a social issue that has nothing to do with the language. > In practice people do not accidentally skip errors in Go. In practice people do not handle errors at all in Java. This is the responsibility of the respective cultures and language designs. This isn't Java's "culture" to not handle errors at all. Go's conventions imposed in its std libs are certainly not a superior model by any measure as I previously showed. Edit: Answer to your follow up since HN ratelimits flamewars > This is java's culture, and I assert it from experience. It is a result of the language design (and communiques from language authorities). Your appeal to authority is a logical fallacy, you have never demonstrated that it is Java culture. I say it isn't Java culture the same way you establish an unfounded claim. > You only showed that it was possible to misbehave in Go, which is totally uninteresting. You have failed to show that your theoretical problem is a practical problem. This is a perfectionist argument. You don't get to say what argument is deemed interest and which isn't in a discussion. Ignoring Go errors is as much as a practical problem that not handling Java exceptions. The difference being that Java does force the developer to catch managed exceptions, Go doesn't care, it's purely a convention. A language construct to deal with errors baked into a language is in theory and practically superior to random conventions established by a vendor. PERIOD. Whatever experience you had with Java isn't representative of Java's culture at all.

philosopher1234 5y ago
>Sure, your problem with Java is also a social issue that has nothing to do with the language. Quoting myself: "This is a social problem, influenced by language design." >This isn't Java's "culture" to not handle errors at all. Go's conventions imposed in its std libs are certainly not a superior model by any measure as I previously showed. This is java's culture, and I assert it from experience. It is a result of the language design (and communiques from language authorities). You only showed that it was possible to misbehave in Go, which is totally uninteresting. You have failed to show that your theoretical problem is a practical problem. This is a perfectionist argument.
- azth 5y ago
  Having worked on golang code bases for several years now, I assure you it's not a theoretical problem. It's not fun to have ignored or overwritten errors that keep the program going as if nothing is happening.
  - randomdata 5y ago
    If you overwrite or ignore your variables you're going to have a bad time. Period. That's not unique to errors. I'm not sure you've said anything to convince us that making mistakes around errors alone is anything more than theoretical. Beyond defining an interface named error (early versions didn't even offer that), Go does not have a concept of errors, so I'm not sure it is even possible for there to be a problem specific to errors. Certainly Go could do more to help you with correctness in general.
    - azth 5y ago
      Because errors are just return values in golang, and it's not possible to write a linter to guarantee that they're handled, there's always going to be the possibility of them being overwritten by accident. Not to mention due to the lack of composability, you end up with even more hacks like what gorm does, making it even easier to mishandle errors. > Go does not have a concept of errors Exactly the problem. There needs to be a notion of error handling in the language.
      - randomdata 5y ago
        > Because errors are just return values in golang, and it's not possible to write a linter to guarantee that they're handled That's true of all types, though. Nothing specific to errors applies there. Spend enough time in Go and that's going to bite you, even when the error interface is nowhere to be found. You've still not made clear what's special about errors that makes the concern about errors, not all types, more than theoretical. > There needs to be a notion of error handling in the language. Why? The computer doesn't have a concept of errors either. All the computer offers is different states. What Go could offer is more guarantees around ensuring that you've handled different states correctly, but that has absolutely nothing to do with errors specifically. Now, humans have a concept of error. Of course. We classify specific computer states as being errors. But since the language and computer treat errors and other states as being the exact same thing, why would that human classification of error magically lead you to start making mistakes that you wouldn't make with other states? That doesn't make any sense. Here's a thought: Stop classifying those states as errors. Call them "happy fun times". Then you won't have whatever mental hangups around errors that are causing you problems specific to errors. Because, from a technical perspective, errors don't exist. They are entirely a human construct. There is nothing about that human construct that should be tripping you up in the tech. No, there should not be any special concept for errors. Errors are not special. As far as the tech is concerned, errors don't even exist. What Go could do is improve on state management generally. Applicable to not only states you've decided to call errors, but all other states as well. Anything that tries to improve state management for only what you've decided to call errors still leaves all of the exact same problems dangling for every other type. That is poor design and doesn't actually solve the problem.

philosopher1234 5y ago

>Sure, your problem with Java is also a social issue that has nothing to do with the language. Quoting myself: "This is a social problem, influenced by language design." >This isn't Java's "culture" to not handle errors at all. Go's conventions imposed in its std libs are certainly not a superior model by any measure as I previously showed. This is java's culture, and I assert it from experience. It is a result of the language design (and communiques from language authorities). You only showed that it was possible to misbehave in Go, which is totally uninteresting. You have failed to show that your theoretical problem is a practical problem. This is a perfectionist argument.

azth 5y ago
Having worked on golang code bases for several years now, I assure you it's not a theoretical problem. It's not fun to have ignored or overwritten errors that keep the program going as if nothing is happening.
- randomdata 5y ago
  If you overwrite or ignore your variables you're going to have a bad time. Period. That's not unique to errors. I'm not sure you've said anything to convince us that making mistakes around errors alone is anything more than theoretical. Beyond defining an interface named error (early versions didn't even offer that), Go does not have a concept of errors, so I'm not sure it is even possible for there to be a problem specific to errors. Certainly Go could do more to help you with correctness in general.
  - azth 5y ago
    Because errors are just return values in golang, and it's not possible to write a linter to guarantee that they're handled, there's always going to be the possibility of them being overwritten by accident. Not to mention due to the lack of composability, you end up with even more hacks like what gorm does, making it even easier to mishandle errors. > Go does not have a concept of errors Exactly the problem. There needs to be a notion of error handling in the language.
    - randomdata 5y ago
      > Because errors are just return values in golang, and it's not possible to write a linter to guarantee that they're handled That's true of all types, though. Nothing specific to errors applies there. Spend enough time in Go and that's going to bite you, even when the error interface is nowhere to be found. You've still not made clear what's special about errors that makes the concern about errors, not all types, more than theoretical. > There needs to be a notion of error handling in the language. Why? The computer doesn't have a concept of errors either. All the computer offers is different states. What Go could offer is more guarantees around ensuring that you've handled different states correctly, but that has absolutely nothing to do with errors specifically. Now, humans have a concept of error. Of course. We classify specific computer states as being errors. But since the language and computer treat errors and other states as being the exact same thing, why would that human classification of error magically lead you to start making mistakes that you wouldn't make with other states? That doesn't make any sense. Here's a thought: Stop classifying those states as errors. Call them "happy fun times". Then you won't have whatever mental hangups around errors that are causing you problems specific to errors. Because, from a technical perspective, errors don't exist. They are entirely a human construct. There is nothing about that human construct that should be tripping you up in the tech. No, there should not be any special concept for errors. Errors are not special. As far as the tech is concerned, errors don't even exist. What Go could do is improve on state management generally. Applicable to not only states you've decided to call errors, but all other states as well. Anything that tries to improve state management for only what you've decided to call errors still leaves all of the exact same problems dangling for every other type. That is poor design and doesn't actually solve the problem.