Profiling Go Applications with Flamegraphs
brendanjryan.com
Profiling Go Applications with Flamegraphs
1–10 of 28 posts
Re: Profiling Go Applications with Flamegraphs
#2I’m trying to figure out why I find Go so hard to read. Am I mostly alone with this?
Re: Profiling Go Applications with Flamegraphs
#3I’m trying to figure out why I find Go so hard to read. Am I mostly alone with this?
It’s considered idiomatic in Go to use very short variable names [1], which seems masochistic to me.
Every time I look at Go code, it’s like I’m back in high school using Borland Turbo C all over again.
[1] https://github.com/golang/go/wiki/CodeReviewComments#variabl...
Re: Profiling Go Applications with Flamegraphs
#4I’m trying to figure out why I find Go so hard to read. Am I mostly alone with this?
It’s considered idiomatic in Go to use very short variable names [1], which seems masochistic to me. Every time I look at Go code, it’s like I’m back in high school using Borland Turbo C all over again. [1] https://github.com/golang/go/wiki/CodeReviewComments#variabl...
I came here to say the same thing, and I'm so relieved I'm not the only one. Looking at those one- and two-letter variable names constantly leaves me scratching my head and wasting time figuring out what they mean.
Re: Profiling Go Applications with Flamegraphs
#5I’m trying to figure out why I find Go so hard to read. Am I mostly alone with this?
It’s considered idiomatic in Go to use very short variable names [1], which seems masochistic to me. Every time I look at Go code, it’s like I’m back in high school using Borland Turbo C all over again. [1] https://github.com/golang/go/wiki/CodeReviewComments#variabl...
I find it really depends.
Small variable names for iteration variables and the `this` equivalent in struct methods are fine.
As for other situations... I guess it's an art?
Re: Profiling Go Applications with Flamegraphs
#6I’m trying to figure out why I find Go so hard to read. Am I mostly alone with this?
I find Go quite easy to read. Maybe you just need a bit more time with it? It does tend to prefer short variable names, which my brain 'likes' -- I think some people have an easier time with shorter names, some people with longer names.
Re: Profiling Go Applications with Flamegraphs
#7I would have liked to have seen how the author measured the hot spots in the graph. It wasn't immediately obvious to me that the `WriteToUDP` function was taking up a significant portion of the call.
Another thing that is omitted is what type of buffer was used. I'm assuming it was a `[]string` slice but why not use a `sync.Pool`?
Re: Profiling Go Applications with Flamegraphs
#8I’m trying to figure out why I find Go so hard to read. Am I mostly alone with this?
It’s considered idiomatic in Go to use very short variable names [1], which seems masochistic to me. Every time I look at Go code, it’s like I’m back in high school using Borland Turbo C all over again. [1] https://github.com/golang/go/wiki/CodeReviewComments#variabl...
I've mostly interpreted that to use single character names for method receivers and loop variables. I think those are defensible because you know where to find them if you need their definition (in the method definition or in the loop).
I don't think that assigning terse names (such as the variable "ra" from the OP) to variables that might be declared anywhere in a function is helpful.
Re: Profiling Go Applications with Flamegraphs
#9Earlier quoted context omitted.
It’s considered idiomatic in Go to use very short variable names [1], which seems masochistic to me. Every time I look at Go code, it’s like I’m back in high school using Borland Turbo C all over again. [1] https://github.com/golang/go/wiki/CodeReviewComments#variabl...
I've mostly interpreted that to use single character names for method receivers and loop variables. I think those are defensible because you know where to find them if you need their definition (in the method definition or in the loop). I don't think that assigning terse names (such as the variable "ra" from the OP) to variables that might be declared anywhere in a function is helpful.
I agree, and the link I posted states as much.
I think the problem comes when people take that advice without nuance and think it gives them carte blanche to make everything as obscure as possible.
And really, it’s not about whether or not we can understand our own code, but can the future developers who have to maintain it after we leave.
I kinda worry that the Go community is creating a lot of unmaintainable code right now.
Re: Profiling Go Applications with Flamegraphs
#10Earlier quoted context omitted.
It’s considered idiomatic in Go to use very short variable names [1], which seems masochistic to me. Every time I look at Go code, it’s like I’m back in high school using Borland Turbo C all over again. [1] https://github.com/golang/go/wiki/CodeReviewComments#variabl...
I've mostly interpreted that to use single character names for method receivers and loop variables. I think those are defensible because you know where to find them if you need their definition (in the method definition or in the loop). I don't think that assigning terse names (such as the variable "ra" from the OP) to variables that might be declared anywhere in a function is helpful.
Though that would still be idiomatic go code. For what it is worth, I do agree with you. Short variable names on a function are a hassle. You have to lookup what they mean, which slows down understanding.
n = copy(p, b.buf[b.r:b.w])
Oh better go to the top and see what those are again...
https://github.com/golang/go/blob/master/src/bufio/bufio.go#...