9 ms·

Literally the first non-trivial code I wrote in go (running a bunch of goroutines to download a ton of files from a website in parallel)... I knew exactly where

Literally the first non-trivial code I wrote in go (running a bunch of goroutines to download a ton of files from a website in parallel)... I knew exactly where and how things could fail and where things were failing just by looking at the code. Coming from C++ and C# and Python, there was no comparison. I had never been so confident in the code I'd written, even though I was a newbie at Go and a veteran of the other languages.

kazinator 7y ago
Did you know where every page fault would happen, and manually check every memory access and fix the situation? You didn't have to because there is an precise, robust non-checked exception handling system which takes care of that: the hardware catches the situation, dispatches a handler in the operating system which fixes it and re-starts your program at the original machine instruction to try the memory access again.
- mikeschinkel 7y ago
  You do not have to be precise in Go either, and you don't have to know all the faults. All you have to know if where a return value that implements the interface `error` is not nil.
KirinDave 7y ago
I guess then I have to ask, why would try() make that worse? Because I can't stand Golang error handling. It's repetitive, it's error prone, and other language features interact with it so that when you make a mistake it can be as hard as a double free to track down where the erroneous default value was introduced. On the other hand, using Rust, Ocaml, F# or Haskell I understand how my code composed and I can be confident I can just use an error handling strategy. The only complexities appear, as with everyone else, when we have asynchronous code. So I don't mean to disagree with your feelings, but they're sure not mine and they're part of why I don't use Golang. I was excited about try() because it at least addressed the most tedious part.
- Thaxll 7y ago
  How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant stacktraces or with Python and people not knowing what to do inside a try / except.
  - _hardwaregeek 7y ago
    It's error prone in that you aren't forced to handle the error. In languages such as Rust or Haskell, you have a Result type which can either be an Ok(val) or an Err(err). In order to "unwrap" a Result, you have to check the error case. Basically there's a compile time guarantee that errors are handled.
    - Thaxll 7y ago
      I'm not a Rust expert but afaik Rust doesn't enforce error checking since you explicitly need to unwrap(). It's very possible to panic because you forgot to check something. It's similar in Go since you can't compile with unused variable so you need to explicitly discard the error with _. Ex: result, _ := func() This is for multi-value returns, for single value you can even omit the _ https://golang.org/doc/effective_go.html#blank https://golang.org/doc/effective_go.html#blank
      - jpittis 7y ago
        Having unwrap() in your Rust code is like littering your code base with panic(). It’s not appropriate to use in most production code, but is convenient in prototypes, examples and tests. Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error. For example err := doThingThatErrs() and doThingThatErrs() are both valid Go code.
        Thaxll 7y ago
        My example is correct I explained all of that, multi values -> need to omit, single value can ignore everything.
RcouF1uZ4gsC 7y ago
>I knew exactly where and how things could fail and where things were failing just by looking at the code. Same could be said about assembly language.
chc 7y ago
I don't see how allowing ergonomic features like try into the language would hamper this. For example, Rust also represents errors as return values — you know exactly where and how things could fail just by looking at the code for a function — but it still has the equivalent of Go's proposed try.
takeda 7y ago
This is interesting, I didn't feel that with go I understand my code better, but I also don't think I was lost in other languages. My impression of go, is that it is very boring to program in it, and some decisions weren't thought well. For example if you use anything else for numbers than int, int64 or float64 you will have very bad time. Lack of generics forces you to duplicate your code, duplicating increases chances of errors and make it harder to fix bugs. The errors are passed as values, but then you need to use different return value to pass them, defeating the whole point of having that. On top of that the language is very rigid. I'm wondering if introducing macros could solve a lot of those issues.
jayd16 7y ago
I'm never more confident than when I'm a newbie.
danielparks 7y ago
> Literally the first non-trivial code I wrote in go… I knew exactly where and how things could fail and where things were failing just by looking at the code. Could you give an example? I think you’re talking about something different than what I’m understanding. One of the major frustrations I have with Go error handling is the lack of stack traces, which means I often have to modify code in order to find out where an error occurred. I’m pretty sure that’s not what you’re talking about, though.
peteretep 7y ago
> I knew exactly where and how things could fail and where things were failing just by looking at the code Don't you just mean you knew where fatal exceptions could be raised? That's substantially different from "fail".

kazinator 7y ago

Did you know where every page fault would happen, and manually check every memory access and fix the situation? You didn't have to because there is an precise, robust non-checked exception handling system which takes care of that: the hardware catches the situation, dispatches a handler in the operating system which fixes it and re-starts your program at the original machine instruction to try the memory access again.

mikeschinkel 7y ago
You do not have to be precise in Go either, and you don't have to know all the faults. All you have to know if where a return value that implements the interface `error` is not nil.

KirinDave 7y ago

I guess then I have to ask, why would try() make that worse? Because I can't stand Golang error handling. It's repetitive, it's error prone, and other language features interact with it so that when you make a mistake it can be as hard as a double free to track down where the erroneous default value was introduced. On the other hand, using Rust, Ocaml, F# or Haskell I understand how my code composed and I can be confident I can just use an error handling strategy. The only complexities appear, as with everyone else, when we have asynchronous code. So I don't mean to disagree with your feelings, but they're sure not mine and they're part of why I don't use Golang. I was excited about try() because it at least addressed the most tedious part.

Thaxll 7y ago
How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant stacktraces or with Python and people not knowing what to do inside a try / except.
- _hardwaregeek 7y ago
  It's error prone in that you aren't forced to handle the error. In languages such as Rust or Haskell, you have a Result type which can either be an Ok(val) or an Err(err). In order to "unwrap" a Result, you have to check the error case. Basically there's a compile time guarantee that errors are handled.
  - Thaxll 7y ago
    I'm not a Rust expert but afaik Rust doesn't enforce error checking since you explicitly need to unwrap(). It's very possible to panic because you forgot to check something. It's similar in Go since you can't compile with unused variable so you need to explicitly discard the error with _. Ex: result, _ := func() This is for multi-value returns, for single value you can even omit the _ https://golang.org/doc/effective_go.html#blank https://golang.org/doc/effective_go.html#blank
    - jpittis 7y ago
      Having unwrap() in your Rust code is like littering your code base with panic(). It’s not appropriate to use in most production code, but is convenient in prototypes, examples and tests. Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error. For example err := doThingThatErrs() and doThingThatErrs() are both valid Go code.
      - Thaxll 7y ago
        My example is correct I explained all of that, multi values -> need to omit, single value can ignore everything.

RcouF1uZ4gsC 7y ago

>I knew exactly where and how things could fail and where things were failing just by looking at the code. Same could be said about assembly language.

chc 7y ago

I don't see how allowing ergonomic features like try into the language would hamper this. For example, Rust also represents errors as return values — you know exactly where and how things could fail just by looking at the code for a function — but it still has the equivalent of Go's proposed try.

takeda 7y ago

This is interesting, I didn't feel that with go I understand my code better, but I also don't think I was lost in other languages. My impression of go, is that it is very boring to program in it, and some decisions weren't thought well. For example if you use anything else for numbers than int, int64 or float64 you will have very bad time. Lack of generics forces you to duplicate your code, duplicating increases chances of errors and make it harder to fix bugs. The errors are passed as values, but then you need to use different return value to pass them, defeating the whole point of having that. On top of that the language is very rigid. I'm wondering if introducing macros could solve a lot of those issues.

jayd16 7y ago

I'm never more confident than when I'm a newbie.

danielparks 7y ago

> Literally the first non-trivial code I wrote in go… I knew exactly where and how things could fail and where things were failing just by looking at the code. Could you give an example? I think you’re talking about something different than what I’m understanding. One of the major frustrations I have with Go error handling is the lack of stack traces, which means I often have to modify code in order to find out where an error occurred. I’m pretty sure that’s not what you’re talking about, though.

peteretep 7y ago

> I knew exactly where and how things could fail and where things were failing just by looking at the code Don't you just mean you knew where fatal exceptions could be raised? That's substantially different from "fail".