3 ms·

I've... never had a problem reading Rust code. It's generally well-typed, and makes good use of "automatic" error handling constructs to ensure errors flow upwa

I've... never had a problem reading Rust code. It's generally well-typed, and makes good use of "automatic" error handling constructs to ensure errors flow upwards without visually polluting the success case. Whereas with Go code, I have to filter out all the error handling (which often takes up 2/3rds of lines of code, even when it's just "if there's an error, return the error" which it almost always is), wade through the mass of functions that take interface{} and cast it to something internally, etc etc. I've tried programming in Go and I find it horrifying - I either get to ignore errors or spend ~80% of my code doing this, repeatedly, a few times per function: foo, err := bar() if err { return nil, err }

JepZ 10y ago
My problems with the readability of Rust is related to the syntax and not so much about the code structure. For example, Smalltalk has the most readable syntax I know, while I find it's code structure average. I know that error handling in Go can be tedious, but to some extent, it is also the programmer's job to utilize the features of the language to write clean code: https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values Regarding your type problem I find very few cases where I need an empty interface (mainly container types). Most of the time I use real interfaces and the most code I have seen used non-empty Interfaces too.
- vertex-four 10y ago
  I tend to find that Rust's syntax warts are primarily in function headers (primarily due to lifetimes), and less so in the bodies. > Regarding your type problem I find very few cases where I need an empty interface (mainly container types). I've run into the issue with quite a few "generic" libraries, since Go doesn't have a generics system. For example, https://github.com/manyminds/api2go https://github.com/manyminds/api2go requires a few of them in common cases. My alternative is writing the same code over and over, and hoping that I've not missed something in one instance of it.
__david__ 10y ago
It's slightly more tolerable if you do this: foo, err := bar() if err { return nil, err } But then the Go community yells at you for daring to not using `go fmt` style.
dullgiulio 10y ago
You are not handling the error, you are just returning it. More correctly, you would decorate the error: foo, err := bar() if err != nil { return nil, fmt.Errorf("failed to do bar: %s", err) }
- vertex-four 10y ago
  Sure, in some cases you want to wrap the error type - Rust handles this by essentially having you create a custom error type which is an enum (which can be done via macros like quick-error and error-chain), and implementing From<BarError> on it which'd create your custom error type from the BarError. This trait is used by both the try!() macro and the ? operator (which do much the same thing, the latter being the updated syntax): let foo = bar()?; If you need to do something custom in converting bar()'s error into your error type - which is rare - you can use .map_err() like this: let foo = bar().map_err(|e| MyError::BarError(e, extraContext))?;

JepZ 10y ago

My problems with the readability of Rust is related to the syntax and not so much about the code structure. For example, Smalltalk has the most readable syntax I know, while I find it's code structure average. I know that error handling in Go can be tedious, but to some extent, it is also the programmer's job to utilize the features of the language to write clean code: https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values Regarding your type problem I find very few cases where I need an empty interface (mainly container types). Most of the time I use real interfaces and the most code I have seen used non-empty Interfaces too.

vertex-four 10y ago
I tend to find that Rust's syntax warts are primarily in function headers (primarily due to lifetimes), and less so in the bodies. > Regarding your type problem I find very few cases where I need an empty interface (mainly container types). I've run into the issue with quite a few "generic" libraries, since Go doesn't have a generics system. For example, https://github.com/manyminds/api2go https://github.com/manyminds/api2go requires a few of them in common cases. My alternative is writing the same code over and over, and hoping that I've not missed something in one instance of it.

__david__ 10y ago

It's slightly more tolerable if you do this: foo, err := bar() if err { return nil, err } But then the Go community yells at you for daring to not using `go fmt` style.

dullgiulio 10y ago

You are not handling the error, you are just returning it. More correctly, you would decorate the error: foo, err := bar() if err != nil { return nil, fmt.Errorf("failed to do bar: %s", err) }

vertex-four 10y ago
Sure, in some cases you want to wrap the error type - Rust handles this by essentially having you create a custom error type which is an enum (which can be done via macros like quick-error and error-chain), and implementing From<BarError> on it which'd create your custom error type from the BarError. This trait is used by both the try!() macro and the ? operator (which do much the same thing, the latter being the updated syntax): let foo = bar()?; If you need to do something custom in converting bar()'s error into your error type - which is rare - you can use .map_err() like this: let foo = bar().map_err(|e| MyError::BarError(e, extraContext))?;