5 ms·
I've only been using Go for less than a week and my impressions are less than good. I'm still waiting and hoping to understand what it is that people like about
by dyadic 12y ago
I've only been using Go for less than a week and my impressions are less than good. I'm still waiting and hoping to understand what it is that people like about Go, but I'm starting to suspect that won't happen.
The biggest problem I have had most so far is when reading other code, finding the meaning amongst all of the error nil checks and the sprawling if conditions that they bring.
Another thing that makes it difficult is the preference for scattering returns everywhere and avoiding `else if`s, I read code structurally so code like this from slide 29 (http://talks.golang.org/2014/readability.slide#29 http://talks.golang.org/2014/readability.slide#29) is really difficult to parse.
func finishStatus(r Result, complete bool) int {
if !complete {
return http.StatusAccepted
}
if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 {
return stat.Code
}
if r.Created {
return http.StatusCreated
}
return http.StatusOK
}
- wolf550e 12y agoThat is the way it is done in C: avoid indentation if you can fail out. It is very readable.
- deleted 12y ago[deleted]
- dyadic 12y agoI disagree, and saying "That is the way it is done in C" doesn't mean that it's the right way. When I see code like this I will assume that it's going to check every condition: if !complete { // do something } if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 { // do something } if r.Created { // do something } If the first condition matching causes the second, third, nth condition to not be checked then why not make it clear in the code by adding an `else`? The recommended way means that I can't trust my assumption and that I'll have to read the entire function and examine the `//do something`s instead
- tptacek 12y agoIf you are religious about single-return style --- and I was an observant practitioner of it until recently --- you simply aren't going to like Golang. For that matter, if you hate C programming --- not in the sense of "C is dangerous and error prone" and more in the sense of "I hate the way I feel when I write C code", you also aren't going to like Golang. The former issue grinds on me a bit, though I'm coming to appreciate what it does for the reliability of my code versus languages with exceptions. On the other hand, I love writing C code, and that probably makes up for it.
- dyadic 12y agoI suspect you're right. I'm going to continue with Go for a little while longer to give it a real chance, there are a few things I like about it such as the dependency management and the lightning fast compilation so there's still a chance that I will grow to like it.
- tptacek 12y agoI really hate Golang error handling, but I have to grudgingly acknowledge that it results in code that is more reliable than Ruby or Python (and much more reliable than C). That's a dividend paid by explicitness. I would not say I've grown to like the error handling, but when I trudge through it now, I do so realizing that there's probably an actual benefit to my program of the annoyance. The Go standard library is also really, really well designed.
- deleted 12y ago[deleted]
- zzzcpan 12y agoYes, this is a really bad abstraction that was yanked from its context and made code really hard to follow and understand which will lead to a bug someday. But we don't have to follow his advise on this and are better off keeping our code sane.