22 ms·

> you learn to design with it There is nothing to learn - it's an ugly wart you have to accept if you're using the language. There's no going around the fact

> you learn to design with it There is nothing to learn - it's an ugly wart you have to accept if you're using the language. There's no going around the fact that it's verbose, error-prone, and makes code hard to read and review.

rob74 5y ago
...as opposed to error handling with exceptions, which is not error-prone at all and makes code really easy to review (or rather, it make it easy to get a false sense of security, and months later you find out that there is an exception you forgot to handle).
thiht 5y ago
> error-prone, and makes code hard to read and review. Strong disagree on that. The fact that it’s explicit makes it extremely easy to reason about and Go code reviews are a breathe. It’s verbose, I’ll give you that, but the rest doesn’t hold.
- samhw 5y ago
  It's true that explicit code is good, but "Go code reviews are a breeze" was not remotely my experience. For me and my past teams, reading through piles of boilerplate verbiage like this - among other 'explicit' syntax - was more of an impediment to understanding the flow of the program. Personally I think what the above commenter said is pretty much spot-on, and typical of Go teams I worked in.
  - lm28469 5y ago
    > my experience. > For me and my past teams > piles of boilerplate verbiage like this I'd love to have a look at your code because this isn't my experience at all. What's your background ? What's your team background ? Are you writing go code with the mindset of a java/cpp/whatever dev ? Have a look at the source code of the top 10 go github repos, you won't find any of what the blog post talks about, because it simply isn't the way it's done
    - joshuamorton 5y ago
      > Have a look at the source code of the top 10 go github repos, you won't find any of what the blog post talks about, because it simply isn't the way it's done A quick look around k8s certainly shows evidence of lots of boilerplate-y error handling. To give my perspective, I come from a primarily python background, but have used C++ and JS enough to know my way around, and Java was what I primarily learned programming in. I write relatively little go, but I review a fair amount of it. The people whose code I'm reviewing are competent, idiomatic go programmers who follow go's style guide (https://github.com/golang/go/wiki/CodeReviewComments https://github.com/golang/go/wiki/CodeReviewComments) to the extent that it exists. I find it far more difficult to tease out what a stanza of go is doing compared to an equivalent stanza of python due to the visual noise. In python (and other languages), I usually use a somewhat functional/declarative style, so I use abstractions like comprehensions and such to allow terse transformations of data. Go doesn't have these. In essence, the tradeoff go makes is to not provide abstractions in the language. This forces users to recreate them[1] ad-hoc, or suffer without abstractions at all (which doesn't scale). This makes everyone suffer, instead of just people unfamiliar with the abstractions suffer. [1]: https://medium.com/@robertgrosse/parallelizing-enjarify-in-go-and-rust-21055d64af7e#.7vrcc2iaf https://medium.com/@robertgrosse/parallelizing-enjarify-in-g..., and yeah yeah yeah go finally is getting generics, but the same general comment applies to other common and useful abstractions. Error handling, functional stuff, take your pick.
  - zaphar 5y ago
    But the flow of the program isn't only or primarily about the happy path. I find it annoying when languages that don't force explicit error handling choices, force me to go searching for the non-happy path. Where do they handle the errors at? It's nowhere in this pull request. Are there errors to handle? You have to assume there must be because exceptions. Then I have to write a bunch of comments asking if they know whether this line can throw or not. Usually the answer is "I don't know" and then I'm the annoying one in the PR review because I tell them to please find out and either add a comment or handle/wrap the exception appropriately. If the only thing you care about is the happy path in your review then Go code will annoy you. But you are also only doing half of your job in that review.
    - simiones 5y ago
      In exception-safe code, you don't care if a particular statement can throw - if the code is correct today when some line can't throw, it should still be correct tomorrow when that line can throw. Also, it's much easier to look for catch{} blocks than it is to look for Go code that actually handles errors, since code that forwards errors, code that wraps errors, and code that handles errors all looks more or less the same in Go (if err != nil {...}).
  - azth 5y ago
    Exactly my experience and others on the team I'm in. golang is extremely verbose as to detract from the underlying logic.
- simiones 5y ago
  A common pattern in a function is to prepare/obtain several resources that seem disparate, and then use them together in some way. With common Go code patterns, you get lots of error "handling" (exception propagation done manually, most of the time) for the resource acquisition that you need to read through before you actually get to understanding what those resources are used for. And until you understand what the resources are needed for, you can't actually understand if the error handling is correct. Not to mention, to get around this, the first skill everyone reading Go code internalizes is ignoring any block that starts with `if err != nil {` that isn't more than 1-2 lines long. In contrast, when reading Java/Python/C#/CL, exception handlers are very rare, so you actually pay attention when you see one.

rob74 5y ago

...as opposed to error handling with exceptions, which is not error-prone at all and makes code really easy to review (or rather, it make it easy to get a false sense of security, and months later you find out that there is an exception you forgot to handle).

thiht 5y ago

> error-prone, and makes code hard to read and review. Strong disagree on that. The fact that it’s explicit makes it extremely easy to reason about and Go code reviews are a breathe. It’s verbose, I’ll give you that, but the rest doesn’t hold.

samhw 5y ago
It's true that explicit code is good, but "Go code reviews are a breeze" was not remotely my experience. For me and my past teams, reading through piles of boilerplate verbiage like this - among other 'explicit' syntax - was more of an impediment to understanding the flow of the program. Personally I think what the above commenter said is pretty much spot-on, and typical of Go teams I worked in.
- lm28469 5y ago
  > my experience. > For me and my past teams > piles of boilerplate verbiage like this I'd love to have a look at your code because this isn't my experience at all. What's your background ? What's your team background ? Are you writing go code with the mindset of a java/cpp/whatever dev ? Have a look at the source code of the top 10 go github repos, you won't find any of what the blog post talks about, because it simply isn't the way it's done
  - joshuamorton 5y ago
    > Have a look at the source code of the top 10 go github repos, you won't find any of what the blog post talks about, because it simply isn't the way it's done A quick look around k8s certainly shows evidence of lots of boilerplate-y error handling. To give my perspective, I come from a primarily python background, but have used C++ and JS enough to know my way around, and Java was what I primarily learned programming in. I write relatively little go, but I review a fair amount of it. The people whose code I'm reviewing are competent, idiomatic go programmers who follow go's style guide (https://github.com/golang/go/wiki/CodeReviewComments https://github.com/golang/go/wiki/CodeReviewComments) to the extent that it exists. I find it far more difficult to tease out what a stanza of go is doing compared to an equivalent stanza of python due to the visual noise. In python (and other languages), I usually use a somewhat functional/declarative style, so I use abstractions like comprehensions and such to allow terse transformations of data. Go doesn't have these. In essence, the tradeoff go makes is to not provide abstractions in the language. This forces users to recreate them[1] ad-hoc, or suffer without abstractions at all (which doesn't scale). This makes everyone suffer, instead of just people unfamiliar with the abstractions suffer. [1]: https://medium.com/@robertgrosse/parallelizing-enjarify-in-go-and-rust-21055d64af7e#.7vrcc2iaf https://medium.com/@robertgrosse/parallelizing-enjarify-in-g..., and yeah yeah yeah go finally is getting generics, but the same general comment applies to other common and useful abstractions. Error handling, functional stuff, take your pick.
- zaphar 5y ago
  But the flow of the program isn't only or primarily about the happy path. I find it annoying when languages that don't force explicit error handling choices, force me to go searching for the non-happy path. Where do they handle the errors at? It's nowhere in this pull request. Are there errors to handle? You have to assume there must be because exceptions. Then I have to write a bunch of comments asking if they know whether this line can throw or not. Usually the answer is "I don't know" and then I'm the annoying one in the PR review because I tell them to please find out and either add a comment or handle/wrap the exception appropriately. If the only thing you care about is the happy path in your review then Go code will annoy you. But you are also only doing half of your job in that review.
  - simiones 5y ago
    In exception-safe code, you don't care if a particular statement can throw - if the code is correct today when some line can't throw, it should still be correct tomorrow when that line can throw. Also, it's much easier to look for catch{} blocks than it is to look for Go code that actually handles errors, since code that forwards errors, code that wraps errors, and code that handles errors all looks more or less the same in Go (if err != nil {...}).
- azth 5y ago
  Exactly my experience and others on the team I'm in. golang is extremely verbose as to detract from the underlying logic.
simiones 5y ago
A common pattern in a function is to prepare/obtain several resources that seem disparate, and then use them together in some way. With common Go code patterns, you get lots of error "handling" (exception propagation done manually, most of the time) for the resource acquisition that you need to read through before you actually get to understanding what those resources are used for. And until you understand what the resources are needed for, you can't actually understand if the error handling is correct. Not to mention, to get around this, the first skill everyone reading Go code internalizes is ignoring any block that starts with `if err != nil {` that isn't more than 1-2 lines long. In contrast, when reading Java/Python/C#/CL, exception handlers are very rare, so you actually pay attention when you see one.