5 ms·

> No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in t

> No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in the language itself, it's with you and your team. Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes it easy, which java fails at.

throw_m239339 5y ago
> Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes it easy, which java fails at. Go makes it pretty easy to ignore errors, it's even worse than Java. An uncaught managed exception will not compile, and an uncaught unmanaged exception might terminate your program. _ := YieldsAnError() will will never terminate your program. Go makes it pretty easier to do the wrong thing.
- philosopher1234 5y ago
  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. 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. 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.
  - throw_m239339 5y ago
    > 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.
- Mawr 5y ago
  > An uncaught managed exception will not compile, and an uncaught unmanaged exception might terminate your program. While it's nice that uncaught exceptions stop the program from continuing with invalid state, it'd be strictly better to not have them in the first place. That's what languages with explicit error returns provide - can't have uncaught errors if you're forced to explicitly deal with every possible error. The resulting software is way more robust that way. > _ := YieldsAnError() This is a deliberate decision to ignore the error - the programmer needed to explicitly type this out. As such, it's not a problem at all. Even if it was, writing a linter to detect it would be trivial. The real issue with Go's error handling is that you are allowed to implicitly ignore errors in certain cases. Most of them are caught by linters, but some edge cases remain and not compiling is better than needing a linter in the first place.
  - throw_m239339 5y ago
    > This is a deliberate decision to ignore the error - the programmer needed to explicitly type this out. As such, it's not a problem at all. Even if it was, writing a linter to detect it would be trivial. So is not handling Java exceptions is deliberate, and again, Java forces you to handle managed exceptions. > While it's nice that uncaught exceptions stop the program from continuing with invalid state, it'd be strictly better to not have them in the first place. That's what languages with explicit error returns provide - can't have uncaught errors if you're forced to explicitly deal with every possible error. The resulting software is way more robust that way. Errors as value in Go are purely a convention, nothing precludes you from doing the exact same thing in Java, or JavaScript or any other possible language that has exceptions. Furthermore, Go has (stupid) exceptions, it's called panics.
    - Mawr 5y ago
      > So is not handling Java exceptions is deliberate That's the thing, there's no visible difference between a deliberately ignored exception and a purposefully ignored one. The code looks exactly the same: foo() Did I purposefully ignore the exception or not? Can `foo()` even throw an exception? There's no way to know. Once you've programmed with explicit error returns, coming back to exceptions is unnerving. Anything may or may not throw at any time and there's no way to know. > Java forces you to handle managed exceptions. I'm referring to the far more common unchecked exceptions. Java's checked exceptions are a whole another bag of demons I don't want to get into right now. > Errors as value in Go are purely a convention, nothing precludes you from doing the exact same thing in Java, or JavaScript or any other possible language that has exceptions. Thing is, conventions matter. A lot. The proof is in the pudding: - what's the ratio of exception-based Java code to error-based Java code? - what's the ratio of error-based Go code to exception-based Go code? Somehow both ratios end up close to 100%, despite neither language forcing their users to use a specific error handling method. That's because there's space between forcing something and completely ignoring it. I often call it "nudging". Languages often do, and should, nudge their programmers into certain ways of programming that fit their philosophy. > Furthermore, Go has (stupid) exceptions, it's called panics. I assume by "stupid" you mean that panics are underfeatured compared to "real" exceptions. That's intended, you're not supposed to catch panics in the first place. They're only there to address runtime issues that are almost always unrecoverable: running out of memory, out-of-bounds array access, regex compilation failure, etc.
azth 5y ago
The right thing is to automatically maintain error context (e.g. stack traces) which golang fails at. Furthermore, the vast majority of the time you will have a top level handler that will log the error anyway. golang is just introducing boilerplate for the sake of it, with none of the upsides. Not to mention it also makes it easy to accidentally ignore or overwrite errors, I've seen several instance of that happening over several years of working in golang. Something that would never have happened in an exception based language.
- morelisp 5y ago
  > Something that would never have happened in an exception based language. Please, over-swallowed exceptions happen all the damn time. Same shit different day. A really common Java problem: T x = foo(); return x.bar(); Now foo() can throw, OK try { T x = foo(); return x.bar(); } catch (Something exc) { return quux(); } You just ate anything from bar(). Instead you gotta do T x; try { x = foo(); } catch (Something exc) { return quux(); } return x.bar(); Which is longer and now your happy-path logic is noised up even worse than most Go handling.
  - smw 5y ago
    Only with checked exceptions, which I think most of java has made an anti-pattern now?
    - morelisp 5y ago
      No, it's got nothing to do with checked exceptions. It's from not wanting all the error-handling noise between the two steps of your happy-path logic. And at least in extant Java code and many Java programmers I interview, it's not considered an anti-pattern (but I agree it should be).
      - azth 5y ago
        It's quite trivial to write a generic function that handles a particular exception else returns a default value, which addresses the above scenario. final var x = getOrDefault(C::foo, Something.class, quux()); return x.bar(); And now with pattern matching in Java, it's trivial to write something similar to Rust's/Scala's `Result<T, E>`/`Try<T>` types and be explicit about all exceptions. I haven't compiled the following, but it's along the lines of: final var x = switch (foo()) { case Ok(var r) -> r; case Error e -> quux(); } return x.bar();

throw_m239339 5y ago

> Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes it easy, which java fails at. Go makes it pretty easy to ignore errors, it's even worse than Java. An uncaught managed exception will not compile, and an uncaught unmanaged exception might terminate your program. _ := YieldsAnError() will will never terminate your program. Go makes it pretty easier to do the wrong thing.

philosopher1234 5y ago
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. 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. 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.
- throw_m239339 5y ago
  > 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.
Mawr 5y ago
> An uncaught managed exception will not compile, and an uncaught unmanaged exception might terminate your program. While it's nice that uncaught exceptions stop the program from continuing with invalid state, it'd be strictly better to not have them in the first place. That's what languages with explicit error returns provide - can't have uncaught errors if you're forced to explicitly deal with every possible error. The resulting software is way more robust that way. > _ := YieldsAnError() This is a deliberate decision to ignore the error - the programmer needed to explicitly type this out. As such, it's not a problem at all. Even if it was, writing a linter to detect it would be trivial. The real issue with Go's error handling is that you are allowed to implicitly ignore errors in certain cases. Most of them are caught by linters, but some edge cases remain and not compiling is better than needing a linter in the first place.
- throw_m239339 5y ago
  > This is a deliberate decision to ignore the error - the programmer needed to explicitly type this out. As such, it's not a problem at all. Even if it was, writing a linter to detect it would be trivial. So is not handling Java exceptions is deliberate, and again, Java forces you to handle managed exceptions. > While it's nice that uncaught exceptions stop the program from continuing with invalid state, it'd be strictly better to not have them in the first place. That's what languages with explicit error returns provide - can't have uncaught errors if you're forced to explicitly deal with every possible error. The resulting software is way more robust that way. Errors as value in Go are purely a convention, nothing precludes you from doing the exact same thing in Java, or JavaScript or any other possible language that has exceptions. Furthermore, Go has (stupid) exceptions, it's called panics.
  - Mawr 5y ago
    > So is not handling Java exceptions is deliberate That's the thing, there's no visible difference between a deliberately ignored exception and a purposefully ignored one. The code looks exactly the same: foo() Did I purposefully ignore the exception or not? Can `foo()` even throw an exception? There's no way to know. Once you've programmed with explicit error returns, coming back to exceptions is unnerving. Anything may or may not throw at any time and there's no way to know. > Java forces you to handle managed exceptions. I'm referring to the far more common unchecked exceptions. Java's checked exceptions are a whole another bag of demons I don't want to get into right now. > Errors as value in Go are purely a convention, nothing precludes you from doing the exact same thing in Java, or JavaScript or any other possible language that has exceptions. Thing is, conventions matter. A lot. The proof is in the pudding: - what's the ratio of exception-based Java code to error-based Java code? - what's the ratio of error-based Go code to exception-based Go code? Somehow both ratios end up close to 100%, despite neither language forcing their users to use a specific error handling method. That's because there's space between forcing something and completely ignoring it. I often call it "nudging". Languages often do, and should, nudge their programmers into certain ways of programming that fit their philosophy. > Furthermore, Go has (stupid) exceptions, it's called panics. I assume by "stupid" you mean that panics are underfeatured compared to "real" exceptions. That's intended, you're not supposed to catch panics in the first place. They're only there to address runtime issues that are almost always unrecoverable: running out of memory, out-of-bounds array access, regex compilation failure, etc.

azth 5y ago

The right thing is to automatically maintain error context (e.g. stack traces) which golang fails at. Furthermore, the vast majority of the time you will have a top level handler that will log the error anyway. golang is just introducing boilerplate for the sake of it, with none of the upsides. Not to mention it also makes it easy to accidentally ignore or overwrite errors, I've seen several instance of that happening over several years of working in golang. Something that would never have happened in an exception based language.

morelisp 5y ago
> Something that would never have happened in an exception based language. Please, over-swallowed exceptions happen all the damn time. Same shit different day. A really common Java problem: T x = foo(); return x.bar(); Now foo() can throw, OK try { T x = foo(); return x.bar(); } catch (Something exc) { return quux(); } You just ate anything from bar(). Instead you gotta do T x; try { x = foo(); } catch (Something exc) { return quux(); } return x.bar(); Which is longer and now your happy-path logic is noised up even worse than most Go handling.
- smw 5y ago
  Only with checked exceptions, which I think most of java has made an anti-pattern now?
  - morelisp 5y ago
    No, it's got nothing to do with checked exceptions. It's from not wanting all the error-handling noise between the two steps of your happy-path logic. And at least in extant Java code and many Java programmers I interview, it's not considered an anti-pattern (but I agree it should be).
    - azth 5y ago
      It's quite trivial to write a generic function that handles a particular exception else returns a default value, which addresses the above scenario. final var x = getOrDefault(C::foo, Something.class, quux()); return x.bar(); And now with pattern matching in Java, it's trivial to write something similar to Rust's/Scala's `Result<T, E>`/`Try<T>` types and be explicit about all exceptions. I haven't compiled the following, but it's along the lines of: final var x = switch (foo()) { case Ok(var r) -> r; case Error e -> quux(); } return x.bar();