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.

Is it just hard to get used to, or does it fundamentally make something more difficult?

I have to always add wildcards between func and the function name, because I can never know how the other developer has decided to specify the name of the receiver. This will always be a problem as far as grepping with primitive tools that don't parse the language.

FYI, many people use thin wrappers like this, it's still a primitive tool that doesn't parse the language, but it can handle that problem: https://jumpshare.com/s/zMENBSr2LwwauJVjo1wS (GIF)

On machines where I control the tooling, this is not an issue. But I can’t take my config to my colleagues machine.

If only AFS had succeeded. What would a modern version of this look like?

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.

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

That's fair, I see many examples in this thread where people pass an exact string directly to grep, as you do. I'm an avid grepper, but my grep tool [1] translates spaces to ".*?", so I would just type "func lart(" in that example and it would work.

An incremental grep tool with just this one transformation rule gets you a lot more mileage out of grep.

[1] https://github.com/minad/consult/blob/screenshots/consult-li...

EDIT: Better demo https://jumpshare.com/s/zMENBSr2LwwauJVjo1wS

that's going to find all the functions that take an argument named lart or of a lart type too, but it also sounds like a thing i really want to try

Also, anything that contains "func" and "lart" as a substring, e.g. foobar(function), blart(baz).

It's not far off from my manually-constructed patterns when I want to make sure I find a function definition (and am willing to tolerate some false positives), but I personally prefer fine-grained control over when it's in use.

Mmh, I type "func\ lart(" when I need the literal string. But it's less often, so it's fair that it's slightly more to type.

yeah!

For functions: grep -P '^func funcName\('

For methods: grep -P '^func [^)]+\) methodName\('

Hope that helps.

thanks, that definitely looks better! pcre is kind of working against you here tho; i assume you're invoking it out of habit

I am actually unaware of downsides of PCRE. Could you explain? I hardly ever use literal grep nowadays.

oh, i mean that instead of

    grep -P '^func [^)]+\) methodName\('

you could say

    grep 'func [^)]*) methodName('

which is a bit less typing

however, i have to admit that i sort of ensnared myself in my own noose here by being too clever! i forgot that grep's regexp dialect only supports + if you \ it, and it took me six tries to figure out why i wasn't getting any grep hits. there's a lot to be said for the predictability and consistency of pcre!

No need for any func, you can just

    grep '\) methodName\('

    grep: Unmatched ) or \)

but your main point might be right; the few non-method matches to (pcre) '\)\s*\w+\s*\(' in /usr/share/go-1.19 seem to be uncommon things like this:

    static void __attribute__ ((constructor)) sigsetup(void) {
    void poison() __attribute__ ((weak));
    C3 = -(R + I) // ADD(5,6) NEG(-5,-6)

I search ") myFunc" to find member functions. It would be nice to search "c myFunc", but a parentheses works

Yea, that was my workaround for Go as well. Go both gains and loses points here.

How many God AI's have expressed their hate for this design? /s

Receivers are utterly idiotic. Like how could anyone with two working brain cells sign off on something like that?

If you don't want OOP in the language, but want people to be able to write thing.function(arg), you just make function(thing, arg) and thing.function(arg) equivalent syntax.

C# did this for extension methods and it Just Works. You just add the "this" keyword to a function in a pure-static class and you get method-like calling on the first param of that function.

If the function has to be modified in any way in order to grant permission to be used that way, then it is not quite "did this".

Equivalent means that there is no difference at the AST level between o.f(a) and f(o, a), like there is no difference in C among (a + i), a[i], i[a] and (i + a).

However, a this keyword is way better than making the programmers fraction off a parameter and move it to the other side of the function name.

A search term here is "Uniform Function Call Syntax", as present in (e.g.) D:

https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax

I completely agree with that.

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\('

What about piped grep statements?

grep func | grep functionName

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

Single letter variables in Golang are to be used in small, local contexts. Akin to the throwaway i var in for loops. You only grep the struct methods, the same way no one greps 'this' or 'self'.

The code bases you've been reading, and even some of the native libraries, don't do it properly. Probably due to legacy reasons that wouldn't pass readability approvals nowadays.

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.

> 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.

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.

> 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.

Zipf's law, right - these rules are a formalization of our brain's functionality with language.

Of course, with enough code, someone does everything.

E.g. food and art are very important in Japan, so stomach is i and a drawing/painting is e.

Food is very very important in France so we call it nourriture :)

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-...

(see also 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%2Fch...).

The thing about stuttering is that the first part of the name is fixed anyway, MOST of the time.

If you want to search for `url.Parse`, you can find most of the usages just by searching for `url.Parse`, because the package will generally be imported as `url` (and you won’t import Parse into your namespace).

It’s not as good as find references via LSP but it is like 99% accurate and works with just grep.

That works somewhat for finding uses of a native Go module, although I've seen lots of cases where the module name is autogenerated and so you need to import with an alias (protobufs, I'm looking at you). It also doesn't work quite so well in reverse -- you need to find files with `package url;`, then find instances of '\bfunc Parse\('.

Lastly, one of the bigger issues is (as aforementioned sibling commenter mentioned) the application of this principle to methods. This is especially bad with method names for established interfaces, like Write or String. Even with a LSP server, you then need to trace up the call stack to figure out what concrete types the function is being called with, then look at the definitions of those types. I can't imagine wanting to do that with only (rip)grep at my disposal.

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.

Wild that you don't distinguish between error handling and name repetition.

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.

Repetition at the syntactic level, as you describe here, is, statistically, zero percent of the time spent in any meaningful software project. It, quite literally, doesn't matter.

Time spent by authors typing source code characters into their editor is almost entirely irrelevant. The only thing that matters is the time spent by readers parsing and understanding the source code in the VCS.

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

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.

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.

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).