Hacker News Reader

Comment by medstrom | Hacker News Reader

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

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

Reply on news.ycombinator.com