5 ms·

Golang has a similar property as a side-effect of the following design decision. ... the language has been designed to be easy to analyze and can be parsed w

Golang has a similar property as a side-effect of the following design decision. ... the language has been designed to be easy to analyze and can be parsed without a symbol table Taken from https://go.dev/doc/faq https://go.dev/doc/faq The "top-level declarations" in source files are exactly: package, import, const, var, type, func. Nothing else. If you're searching for a function, it's always going to start with "func", even if it's an anonymous function. Searching for methods implemented by a struct similarly only needs one to know the "func" keyword and the name of the struct. Coming from a background of mostly Clojure, Common Lisp, and TypeScript, the "greppability" of Go code is by far the best I have seen. Of course, in any language, Go included, it's always better to rely on static analysis tools (like the IDE or LSP server) to find references, definitions, etc. But when searching code of some open source library, I always resort to ripgrep rather than setting up a development environment, unless I found something that I want to patch (which in case I set up the devlopment environment and rely on LSP instead of grep to discover definitions and references).

remram 2y ago
In golang you get `func (someName someType) funcname`, so it's much less greppable than languages using `func funcname`
tuetuopay 2y ago
Go is horrible due to the absence of specific "interface implementation" markers. Gets pretty hard to find where or how a type implements an interface.
- kiitos 2y ago
  Interfaces are consumer contracts, they say "I need this" not "I provide this". Regardless, any reasonable LSP will let you "Find implementations" of any interface definition.
  - tuetuopay 2y ago
    Yup, but we're talking about grep, not lsp. And that's precisely why I don't write go without an lsp (the rare times I do write go).
eptcyka 2y ago
Golang gets zero points from me because function receivers are declared between func and the name of the function. God ai hate this design choice and boy am I glad I can use golsp.
- alienchow 2y ago
  I very rarely use literal grep at all. Perl grep is my standard goto. For functions: grep -P '^func funcName\(' For methods: grep -P '^func [^)]+\) methodName\('
- aadhavans 2y ago
  What about piped grep statements? grep func | grep functionName
- medstrom 2y ago
  Is it just hard to get used to, or does it fundamentally make something more difficult?
  - ljm 2y ago
    Can’t say I’ve ever had an issue with it, but it does get a bit wild when you have a function signature that takes a function and returns one, unless you clear it up with some types. func (s *Recv) foo(fn func(x any) err) func bar(y any) (*Recv, err) As an exaggerated example. Easy to parse but not always easy to read at a glance.
  - kragen 2y ago
    this thread is about using `grep` to find things, and this subthread is specifically about how the `func` keyword in golang makes it easy to distinguish the definition of a function from its uses, so yes, because `grep 'func lart('` will not find definitions of `lart` as a method. you might end up with something like `grep 'func .*) *lart('` which is both imprecise and enough noise that you will not want to type it; you'll have to can it in a script, with the associated losses of flexibility and transparency
    - 2y ago
madeofpalk 2y ago
The culture of single letter variables in golang, at least in the codebases I've seen, undoes this.
- VonGallifrey 2y ago
  The way I have seen this is that single letter variables are mostly used when declaration and (all) usages are very close together. If I see a loop with i or k, v then I can be fairly confident that those are an Index or a Key Value pair. Also I probably don't need to grep them since everything interacting with these variables is probably already on my screen. Everything that has a wider scope or which would be unclear with a single letter is named with a more descriptive name. Of course this is highly dependent on the people you work with, but this is the way it works on projects I have worked on.
- lelanthran 2y ago
  > The culture of single letter variables in golang, at least in the codebases I've seen, undoes this. The convention, not just in Go, is that the smaller the scope, the smaller the variable reference. So, sure, you're going to see single-letter variables in short functions, inside short block scopes, etc, but that is true of almost any language. I haven't seen single-letter variables in Go that are in a scope that isn't short. Of course, this could just mean that I haven't seen enough of other peoples Go source.
  - marcosdumay 2y ago
    > that is true of almost any language You'd be surprised how often language-local cultures break that rule on either side. And a few times it's even an improvement.
  - iudqnolq 2y ago
    I like using l for logger and db for database client/pool/handle even if there's a wider scope. And if the bulk of a file is interacting with a single client I might call that c.
  - lanstin 2y ago
vitus 2y ago
I'm not so sure about greppability in the context of Go. At least at Google (where Go originates, and whose style guide presumably has strong influence on other organizations' use of the language), we discourage "stuttering": > A piece of Go source code should avoid unnecessary repetition. One common source of this is repetitive names, which often include unnecessary words or repeat their context or type. Code itself can also be unnecessarily repetitive if the same or a similar code segment appears multiple times in close proximity. https://google.github.io/styleguide/go/decisions#repetitive-with-package https://google.github.io/styleguide/go/decisions#repetitive-... (see also https://google.github.io/styleguide/go/best-practices#avoid-repetition https://google.github.io/styleguide/go/best-practices#avoid-...) This is the style rule that motivates the sibling comment about method names being split between method and receiver, for what it's worth. I don't think this use case has received much attention internally, since it's fairly rare at Google to use grep directly to navigate code. As you suggest, it's much more common to either use your IDE with LSP integration, or Code Search (which you can get a sense of via Chromium's public repository, e.g. https://source.chromium.org/search?q=v8&sq=&ss=chromium%2Fchromium%2Fsrc https://source.chromium.org/search?q=v8&sq=&ss=chromium%2Fch...).
- alexvitkov 2y ago
  Wild that the people who made the language that forces me to type if err != nil { return nil, err } after every second statement are advising against code repetition.
  - kiitos 2y ago
    Wild that you don't distinguish between error handling and name repetition.
    - alexvitkov 2y ago
      The issue is about "repetition" - a concept that exists on the syntactic level, and is unavoidable in Go. To put it in a way you may understand, it's when you have to press keys in the same order a lot of times and you get sad.

remram 2y ago

In golang you get `func (someName someType) funcname`, so it's much less greppable than languages using `func funcname`

tuetuopay 2y ago

Go is horrible due to the absence of specific "interface implementation" markers. Gets pretty hard to find where or how a type implements an interface.

kiitos 2y ago
Interfaces are consumer contracts, they say "I need this" not "I provide this". Regardless, any reasonable LSP will let you "Find implementations" of any interface definition.
- tuetuopay 2y ago
  Yup, but we're talking about grep, not lsp. And that's precisely why I don't write go without an lsp (the rare times I do write go).

eptcyka 2y ago

Golang gets zero points from me because function receivers are declared between func and the name of the function. God ai hate this design choice and boy am I glad I can use golsp.

alienchow 2y ago
I very rarely use literal grep at all. Perl grep is my standard goto. For functions: grep -P '^func funcName\(' For methods: grep -P '^func [^)]+\) methodName\('
aadhavans 2y ago
What about piped grep statements? grep func | grep functionName
medstrom 2y ago
Is it just hard to get used to, or does it fundamentally make something more difficult?
- ljm 2y ago
  Can’t say I’ve ever had an issue with it, but it does get a bit wild when you have a function signature that takes a function and returns one, unless you clear it up with some types. func (s *Recv) foo(fn func(x any) err) func bar(y any) (*Recv, err) As an exaggerated example. Easy to parse but not always easy to read at a glance.
- kragen 2y ago
  this thread is about using `grep` to find things, and this subthread is specifically about how the `func` keyword in golang makes it easy to distinguish the definition of a function from its uses, so yes, because `grep 'func lart('` will not find definitions of `lart` as a method. you might end up with something like `grep 'func .*) *lart('` which is both imprecise and enough noise that you will not want to type it; you'll have to can it in a script, with the associated losses of flexibility and transparency
  - 2y ago

madeofpalk 2y ago

The culture of single letter variables in golang, at least in the codebases I've seen, undoes this.

VonGallifrey 2y ago
The way I have seen this is that single letter variables are mostly used when declaration and (all) usages are very close together. If I see a loop with i or k, v then I can be fairly confident that those are an Index or a Key Value pair. Also I probably don't need to grep them since everything interacting with these variables is probably already on my screen. Everything that has a wider scope or which would be unclear with a single letter is named with a more descriptive name. Of course this is highly dependent on the people you work with, but this is the way it works on projects I have worked on.
lelanthran 2y ago
> The culture of single letter variables in golang, at least in the codebases I've seen, undoes this. The convention, not just in Go, is that the smaller the scope, the smaller the variable reference. So, sure, you're going to see single-letter variables in short functions, inside short block scopes, etc, but that is true of almost any language. I haven't seen single-letter variables in Go that are in a scope that isn't short. Of course, this could just mean that I haven't seen enough of other peoples Go source.
- marcosdumay 2y ago
  > that is true of almost any language You'd be surprised how often language-local cultures break that rule on either side. And a few times it's even an improvement.
- iudqnolq 2y ago
  I like using l for logger and db for database client/pool/handle even if there's a wider scope. And if the bulk of a file is interacting with a single client I might call that c.
- lanstin 2y ago

vitus 2y ago

I'm not so sure about greppability in the context of Go. At least at Google (where Go originates, and whose style guide presumably has strong influence on other organizations' use of the language), we discourage "stuttering": > A piece of Go source code should avoid unnecessary repetition. One common source of this is repetitive names, which often include unnecessary words or repeat their context or type. Code itself can also be unnecessarily repetitive if the same or a similar code segment appears multiple times in close proximity. https://google.github.io/styleguide/go/decisions#repetitive-with-package https://google.github.io/styleguide/go/decisions#repetitive-... (see also https://google.github.io/styleguide/go/best-practices#avoid-repetition https://google.github.io/styleguide/go/best-practices#avoid-...) This is the style rule that motivates the sibling comment about method names being split between method and receiver, for what it's worth. I don't think this use case has received much attention internally, since it's fairly rare at Google to use grep directly to navigate code. As you suggest, it's much more common to either use your IDE with LSP integration, or Code Search (which you can get a sense of via Chromium's public repository, e.g. https://source.chromium.org/search?q=v8&sq=&ss=chromium%2Fchromium%2Fsrc https://source.chromium.org/search?q=v8&sq=&ss=chromium%2Fch...).

alexvitkov 2y ago
Wild that the people who made the language that forces me to type if err != nil { return nil, err } after every second statement are advising against code repetition.
- kiitos 2y ago
  Wild that you don't distinguish between error handling and name repetition.
  - alexvitkov 2y ago
    The issue is about "repetition" - a concept that exists on the syntactic level, and is unavoidable in Go. To put it in a way you may understand, it's when you have to press keys in the same order a lot of times and you get sad.