7 ms·

Now that Go has generics (and the workspace handling mentioned here) I think it's going to get down to complaining about verbose error handling...

heavyset_go 5y ago
I like Java-style checked exceptions and Rust's Result enums, and my ideal error handling would be more verbose compared to Go's error handling.
- KptMarchewa 5y ago
  Rust's Result type is way less verbose than Go's error handling though. Checked exceptions would have been fine if they composed decently with rest of the language...
  - heavyset_go 5y ago
    With Rust's result type, you either have to unwrap() them or explicitly handle them with match expressions, whereas if you really wanted to in Go, you could just choose to ignore errors.
    - KptMarchewa 5y ago
      Rust has extremely useful "?" operator.
      - heavyset_go 5y ago
        Yep, I mentioned that up-thread. It's a very convenient feature.
- deleted 5y ago
  [deleted]
- foolfoolz 5y ago
  there’s really no reason this has to be 3 lines if err != nil { return err } i’m hoping they find a way to simplify this
  - preseinger 5y ago
    Returning an unannotated error like this is an antipattern. Every error return should include an annotation via fmt.Errorf.
    - nkozyra 5y ago
      Why? Errors are annotated by definition. I wouldn't feel better about returning my own string versus the error which already includes a message. How much additional context needs to be there and how often is this convention used by simply duplicating the message with basically repetitive text? panic(err) become "Problem with date formatting: invalid date format" or similar I also think "antipattern" gets thrown around too often. This sounds more like a preference or convention.
      - srer 5y ago
        I presume as a method of manually constructing backtrace, as the same error may occur in multiple places it's helpful to understand the context. I too would label it a preference. To get out of the error handling tedium in our platform I largely opt to panic instead whenever viable, which gives a nice trace for free. (I am but human, and the error handling particularly grates once you have gotten used to just typing `?`.)
        nkozyra 5y ago
        I also panic whenever possible from the caller, in which case I get a pretty clear stack trace. I understand you don't always want that but imo I don't have a lot of cases where I'm ultimately throwing my hands up on a non-exception error. I think V2 errors are taking more of a lead from the pkg/errors error.Wrap approach anyway.
tmp_anon_22 5y ago
I wonder how practical it would to implement much of Rust's error handling syntactic sugar in Golang. I'm sure a lot doesn't transfer over, but Rust seems to have learned a lot from other languages like Golang in this regard.
obilgic 5y ago
it's going to get down to complaining about introducing generics way too late.
- pstuart 5y ago
  Only for those who want to make a stink about it.
aphistic 5y ago
There's much more to differentiate Rust and Go than support for generics and error handling verbosity. In my mind (and experience) they don't even occupy the same problem space.
- monkey26 5y ago
  I struggle to see what problem space is better for one or the other. I’ve replaced all my web service type stuff with Rust and couldn’t be happier. Also a lot of stuff I used to do in Python is more concise in Rust. No I hung up my Go boots in 2018, so may be a little out of touch.
  - srer 5y ago
    IMHO: Rust integrates a bit better with existing software. Inclusion of Rust in Linux being an example. Go culture tends to value pure Go projects a bit more than Rust's, where Rust wrappers around C libs are more accepted and common. Go is generally easier from a social point of view, there's not much to learn as it's largely a repeat of what people are familiar with. So introducing it in a workplace is easier as the on ramp is minor. Ubiquitous greenthreading in Go seems to make the integration piece a bit harder, but the onramp a bit easier.
- pstuart 5y ago
  I was being cheeky. I love Go and have been too busy/lazy to dive into Rust but would like to. Yes, different problem spaces but they often get compared head to head because we need to have stuff to argue over.
riyadparvez 5y ago
This reminds me of Dan Luu post about outages and post-mortems [1]: > For more on this, Ding Yuan et al. have a great paper and talk: Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems. The paper is basically what it says on the tin. The authors define a critical failure as something that can take down a whole cluster or cause data corruption, and then look at a couple hundred bugs in Cassandra, HBase, HDFS, MapReduce, and Redis, to find 48 critical failures. They then look at the causes of those failures and find that most bugs were due to bad error handling. 92% of those failures are actually from errors that are handled incorrectly. [1] https://danluu.com/postmortem-lessons/ https://danluu.com/postmortem-lessons/
- throwaway894345 5y ago
  I believe this, but I don't think it addresses whether implicit or explicit error handling is more likely to result in correctly handled errors. My opinion is that explicit is better than implicit (and I'm using implicit and explicit loosely here--the `?` operator is technically explicit, but I'm considering it to be implicit since it's easy to overlook a single character).
  - deleted 5y ago
    [deleted]
  - stouset 5y ago
    It's impossible to overlook that single character because your code won't compile otherwise. Unlike Go, you cannot accidentally ignore an error condition in Rust. There is no way to discard the error without explicitly doing so, and even then you still have to decide on a non-error return value to return (because Rust functions that fail provide an error or a value and not both, unlike fallible golang functions). People who believe Golang is explicit and hard to ignore errors but think that Rust is implicit and easy to ignore errors have never used both languages, full stop. I challenge you to provide me with an example of Rust code that ignores an error without explicitly and obviously doing so.
    - 5y ago

heavyset_go 5y ago

I like Java-style checked exceptions and Rust's Result enums, and my ideal error handling would be more verbose compared to Go's error handling.

KptMarchewa 5y ago
Rust's Result type is way less verbose than Go's error handling though. Checked exceptions would have been fine if they composed decently with rest of the language...
- heavyset_go 5y ago
  With Rust's result type, you either have to unwrap() them or explicitly handle them with match expressions, whereas if you really wanted to in Go, you could just choose to ignore errors.
  - KptMarchewa 5y ago
    Rust has extremely useful "?" operator.
    - heavyset_go 5y ago
      Yep, I mentioned that up-thread. It's a very convenient feature.
deleted 5y ago
[deleted]
foolfoolz 5y ago
there’s really no reason this has to be 3 lines if err != nil { return err } i’m hoping they find a way to simplify this
- preseinger 5y ago
  Returning an unannotated error like this is an antipattern. Every error return should include an annotation via fmt.Errorf.
  - nkozyra 5y ago
    Why? Errors are annotated by definition. I wouldn't feel better about returning my own string versus the error which already includes a message. How much additional context needs to be there and how often is this convention used by simply duplicating the message with basically repetitive text? panic(err) become "Problem with date formatting: invalid date format" or similar I also think "antipattern" gets thrown around too often. This sounds more like a preference or convention.
    - srer 5y ago
      I presume as a method of manually constructing backtrace, as the same error may occur in multiple places it's helpful to understand the context. I too would label it a preference. To get out of the error handling tedium in our platform I largely opt to panic instead whenever viable, which gives a nice trace for free. (I am but human, and the error handling particularly grates once you have gotten used to just typing `?`.)
      - nkozyra 5y ago
        I also panic whenever possible from the caller, in which case I get a pretty clear stack trace. I understand you don't always want that but imo I don't have a lot of cases where I'm ultimately throwing my hands up on a non-exception error. I think V2 errors are taking more of a lead from the pkg/errors error.Wrap approach anyway.

tmp_anon_22 5y ago

I wonder how practical it would to implement much of Rust's error handling syntactic sugar in Golang. I'm sure a lot doesn't transfer over, but Rust seems to have learned a lot from other languages like Golang in this regard.

obilgic 5y ago

it's going to get down to complaining about introducing generics way too late.

pstuart 5y ago
Only for those who want to make a stink about it.

aphistic 5y ago

There's much more to differentiate Rust and Go than support for generics and error handling verbosity. In my mind (and experience) they don't even occupy the same problem space.

monkey26 5y ago
I struggle to see what problem space is better for one or the other. I’ve replaced all my web service type stuff with Rust and couldn’t be happier. Also a lot of stuff I used to do in Python is more concise in Rust. No I hung up my Go boots in 2018, so may be a little out of touch.
- srer 5y ago
  IMHO: Rust integrates a bit better with existing software. Inclusion of Rust in Linux being an example. Go culture tends to value pure Go projects a bit more than Rust's, where Rust wrappers around C libs are more accepted and common. Go is generally easier from a social point of view, there's not much to learn as it's largely a repeat of what people are familiar with. So introducing it in a workplace is easier as the on ramp is minor. Ubiquitous greenthreading in Go seems to make the integration piece a bit harder, but the onramp a bit easier.
pstuart 5y ago
I was being cheeky. I love Go and have been too busy/lazy to dive into Rust but would like to. Yes, different problem spaces but they often get compared head to head because we need to have stuff to argue over.

riyadparvez 5y ago

This reminds me of Dan Luu post about outages and post-mortems [1]: > For more on this, Ding Yuan et al. have a great paper and talk: Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems. The paper is basically what it says on the tin. The authors define a critical failure as something that can take down a whole cluster or cause data corruption, and then look at a couple hundred bugs in Cassandra, HBase, HDFS, MapReduce, and Redis, to find 48 critical failures. They then look at the causes of those failures and find that most bugs were due to bad error handling. 92% of those failures are actually from errors that are handled incorrectly. [1] https://danluu.com/postmortem-lessons/ https://danluu.com/postmortem-lessons/

throwaway894345 5y ago
I believe this, but I don't think it addresses whether implicit or explicit error handling is more likely to result in correctly handled errors. My opinion is that explicit is better than implicit (and I'm using implicit and explicit loosely here--the `?` operator is technically explicit, but I'm considering it to be implicit since it's easy to overlook a single character).
- deleted 5y ago
  [deleted]
- stouset 5y ago
  It's impossible to overlook that single character because your code won't compile otherwise. Unlike Go, you cannot accidentally ignore an error condition in Rust. There is no way to discard the error without explicitly doing so, and even then you still have to decide on a non-error return value to return (because Rust functions that fail provide an error or a value and not both, unlike fallible golang functions). People who believe Golang is explicit and hard to ignore errors but think that Rust is implicit and easy to ignore errors have never used both languages, full stop. I challenge you to provide me with an example of Rust code that ignores an error without explicitly and obviously doing so.
  - 5y ago