6 ms·

What are you talking about, only Rust actually forces you to handle errors. Go functions merely return a tuple with an error along with the result, with a conve

What are you talking about, only Rust actually forces you to handle errors. Go functions merely return a tuple with an error along with the result, with a convention that you must checktror a non-nil error before using the result. Rust bakes this into the type system, a function can truly return a result or an error.

bayindirh 2mo ago
> with a convention that you must checktror a non-nil error before using the result. So, you handle the error in the end, or forcefully and intentionally ignore it. Again, if the code goes boom, it's on the developer, not on Go. > Rust bakes this into the type system, a function can truly return a result or an error. Error being a variable or baked into the type system doesn't change the practical result. You must handle the error or purposefully ignore it. > only Rust actually forces you to handle errors. When you have two programming languages which makes you handle the error, the word only becomes a little invalid. Semantics doesn't change the result. You have to acknowledge and act on the error either way.
- resonious 2mo ago
  > if the code goes boom, it's on the developer This is the same argument C (and Zig!) people have for manual memory management. You can avoid memory problems by being a good developer.
  - yoghurtwere 2mo ago
    https://www.reddit.com/r/programming/comments/1p0srgs/comment/npld8vh/ https://www.reddit.com/r/programming/comments/1p0srgs/commen...
    - stefr- 2mo ago
      You pasting this comment link on all the replies clearly shows you don't understand what actually went wrong in this Cloudflare outage. But Rust bad.
  - bayindirh 2mo ago
    While I have my opinions on manual memory management, I'll not open that file today (well, it may leak). On the other hand, Go explicitly warns and tries to prevent you from ignoring or not handling possible errors. This is a bit different than a happy C compiler which doesn't warn you about leaking memory.
- madeofpalk 2mo ago
  > So, you handle the error in the end, or forcefully and intentionally ignore it. Again, if the code goes boom, it's on the developer, not on Go. Except Go doesn’t actually require you to handle the error. You can forget to handle the error, or forget to do a nil check. And Go won’t tell you until it crashes and explodes at runtime. Technically the user’s fault, but good systems protect the users from their own mistakes.
  - majormajor 2mo ago
    It's not hard to ignore an error in Rust, IME? Especially as someone who's read a lot of code written by newcomers to Rust.
  - yoghurtwere 2mo ago
    .unwrap() https://www.reddit.com/r/programming/comments/1p0srgs/comment/npld8vh/ https://www.reddit.com/r/programming/comments/1p0srgs/commen...
    - rowanG077 2mo ago
      Unwrap is an explicit action. Checking an error is usually just forgotten. No unwrap can enter your code without the dev being accutely aware of it.
      - bayindirh 2mo ago
        Your Go code won't compile if you don't check the error, though.
        rowanG077 2mo ago
        Did you ever use go? ``` package main import ( "errors" "fmt" ) func getMessage() (string, error) { return "DO NOT INSPECT", errors.New("something went wrong") } func main() { msg, _ := getMessage() // Ignore the error. fmt.Println(msg) } ``` Compiles normally and prints "DO NOT INSPECT"
tomhp 2mo ago
Rust is neither the only nor the first language to contain a result type (https://en.wikipedia.org/wiki/Result_type https://en.wikipedia.org/wiki/Result_type). Definitely a much nicer way to handle errors though.
wannabe44 2mo ago
In practice you use Go with a linter, so this is not a problem in practice. I have never seen a missed error. The problem is painstakingly and manually having to build the stack trace, and then unwrapping it few layers above if you ever need to check what error it was.
- bayindirh 2mo ago
  You don't need a linter. Practically Go code will not compile without declaring and using the "err" returning from a function call. I have written a fresh example at https://files.bayindirh.io/misc/error_example.go https://files.bayindirh.io/misc/error_example.go. Give it a Go. ;) OTOH, gopls is a great LSP, though, and it warns you about this immediately.
  - comex 2mo ago
    The problem is that this stops working once you have multiple assignments to err in the same function.
    - bayindirh 2mo ago
      Good point, but I personally never do that? Instead of doing (expensive) calls, I just assign the result to a variable and use that instead. Accessing to memory is pretty cheap in Go, and it's cleaned once it goes out of the scope, so why not? Considering some expensive Go calls do the same caching underneath, this is the preferred design pattern, I assume.
  - deleted 2mo ago
    [deleted]
  - wannabe44 2mo ago
    What if the method only returns an error, like file.Close()?
yoghurtwere 2mo ago
.unwrap(). I am skeptical about Go's error handling, but there are cases where it is desirable to return both a result and also an error, like returning what can be returned while warning users about any errors. That can be modeled in Rust and other languages as well, though it is the default for Go.

bayindirh 2mo ago

> with a convention that you must checktror a non-nil error before using the result. So, you handle the error in the end, or forcefully and intentionally ignore it. Again, if the code goes boom, it's on the developer, not on Go. > Rust bakes this into the type system, a function can truly return a result or an error. Error being a variable or baked into the type system doesn't change the practical result. You must handle the error or purposefully ignore it. > only Rust actually forces you to handle errors. When you have two programming languages which makes you handle the error, the word only becomes a little invalid. Semantics doesn't change the result. You have to acknowledge and act on the error either way.

resonious 2mo ago
> if the code goes boom, it's on the developer This is the same argument C (and Zig!) people have for manual memory management. You can avoid memory problems by being a good developer.
- yoghurtwere 2mo ago
  https://www.reddit.com/r/programming/comments/1p0srgs/comment/npld8vh/ https://www.reddit.com/r/programming/comments/1p0srgs/commen...
  - stefr- 2mo ago
    You pasting this comment link on all the replies clearly shows you don't understand what actually went wrong in this Cloudflare outage. But Rust bad.
- bayindirh 2mo ago
  While I have my opinions on manual memory management, I'll not open that file today (well, it may leak). On the other hand, Go explicitly warns and tries to prevent you from ignoring or not handling possible errors. This is a bit different than a happy C compiler which doesn't warn you about leaking memory.
madeofpalk 2mo ago
> So, you handle the error in the end, or forcefully and intentionally ignore it. Again, if the code goes boom, it's on the developer, not on Go. Except Go doesn’t actually require you to handle the error. You can forget to handle the error, or forget to do a nil check. And Go won’t tell you until it crashes and explodes at runtime. Technically the user’s fault, but good systems protect the users from their own mistakes.
- majormajor 2mo ago
  It's not hard to ignore an error in Rust, IME? Especially as someone who's read a lot of code written by newcomers to Rust.
- yoghurtwere 2mo ago
  .unwrap() https://www.reddit.com/r/programming/comments/1p0srgs/comment/npld8vh/ https://www.reddit.com/r/programming/comments/1p0srgs/commen...
  - rowanG077 2mo ago
    Unwrap is an explicit action. Checking an error is usually just forgotten. No unwrap can enter your code without the dev being accutely aware of it.
    - bayindirh 2mo ago
      Your Go code won't compile if you don't check the error, though.
      - rowanG077 2mo ago
        Did you ever use go? ``` package main import ( "errors" "fmt" ) func getMessage() (string, error) { return "DO NOT INSPECT", errors.New("something went wrong") } func main() { msg, _ := getMessage() // Ignore the error. fmt.Println(msg) } ``` Compiles normally and prints "DO NOT INSPECT"

tomhp 2mo ago

Rust is neither the only nor the first language to contain a result type (https://en.wikipedia.org/wiki/Result_type https://en.wikipedia.org/wiki/Result_type). Definitely a much nicer way to handle errors though.

wannabe44 2mo ago

In practice you use Go with a linter, so this is not a problem in practice. I have never seen a missed error. The problem is painstakingly and manually having to build the stack trace, and then unwrapping it few layers above if you ever need to check what error it was.

bayindirh 2mo ago
You don't need a linter. Practically Go code will not compile without declaring and using the "err" returning from a function call. I have written a fresh example at https://files.bayindirh.io/misc/error_example.go https://files.bayindirh.io/misc/error_example.go. Give it a Go. ;) OTOH, gopls is a great LSP, though, and it warns you about this immediately.
- comex 2mo ago
  The problem is that this stops working once you have multiple assignments to err in the same function.
  - bayindirh 2mo ago
    Good point, but I personally never do that? Instead of doing (expensive) calls, I just assign the result to a variable and use that instead. Accessing to memory is pretty cheap in Go, and it's cleaned once it goes out of the scope, so why not? Considering some expensive Go calls do the same caching underneath, this is the preferred design pattern, I assume.
- deleted 2mo ago
  [deleted]
- wannabe44 2mo ago
  What if the method only returns an error, like file.Close()?

yoghurtwere 2mo ago

.unwrap(). I am skeptical about Go's error handling, but there are cases where it is desirable to return both a result and also an error, like returning what can be returned while warning users about any errors. That can be modeled in Rust and other languages as well, though it is the default for Go.