lo(dash) coding style

[dtrudg]

Hey all,

@preminger has been doing some great work on revising code to support build-args in definition files, that we are cherry-picking from Apptainer (#1738).

There's a little question, in my mind at least, as to whether we want to fully embrace the use of the lo Go module, which brings lodash style set operations, map/reduce etc. to Go.

I personally like lo for operations like this:

unusedArgs, _ := lo.Difference(lo.Keys(buildArgsMap), lo.Uniq(overallConsumedArgs))

... which my caffeine addled brain can easily read. I think it's nice a nice clear and concise way of performing list comparisons etc.

I personally am not so keen on lo for operations like those below:

totalRaw := lo.Sum(lo.Map(revisedDefs, func(d types.Definition, _ int) int {
    return len(d.Raw)
}))

revisedDefs[nDefs-1].Raw = lo.Reduce(revisedDefs, func(soFar []byte, thisOne types.Definition, _ int) []byte {
    return append(soFar, thisOne.Raw...)
}, make([]byte, 0, totalRaw))

My view would be that these are a bit 'un-Go -like' and significantly more difficult to read than a for loop. I've used similar constructs in e.g. Python, but I think the Go syntax makes them a bit confusing / clunky to read.

Of course, my tastes are my own... and I'm more JS adverse than much of the developer world... so it makes sense to follow the preference of the majority of those who would likely be reading and contributing to the code :-)

Please let your opinion be known!

[preminger]

I'm the person who wrote both of the code snippets cited above (the latter, albeit, as part of a draft PR) - which I guess makes me in favor of this style of coding, by default...? - but in truth, I'm happy either way. I tend to agree with @dtrudg that our code style should definitely accommodate things like lo.Difference, since they replace what would otherwise be considerably clunkier code. But I'm happy to take or leave the lo.Map / lo.Sum / lo.Reduce stuff, as the community sees fit.

If I were nevertheless asked to mount a defense of the lo.Map / lo.Sum / lo.Reduce part of things, it would go like this:

Go has function literals. And having function literals without "map", "filter", and the rest of their friends is a half-measure. Now, it's absolutely true, as @dtrudg points out, that Go lacks the syntactic sugar that languages like Python, for example, provide for this sort of thing. That is in a sense the whole reason a package like lo is even necessary in the first place. But the use of things like "map" and "reduce" is not just about syntactic brevity; it's also about enabling certain modes of thinking about code. A for-loop can do lots of things that e.g. lo.Reduce(lo.Map(...)) cannot. Using the latter is therefore more restrictive, and as we all know, restrictiveness can be a useful guard rail when writing code. It supports good design principles. (A well-trodden example would be private variables, which cannot be accessed from outside their package of origin.) So when all your loop is doing is mapping a function to every cell in a slice to produce a slice of results, one could argue that you should be using something like lo.Map in lieu of a for-loop, to make it clear that you're not doing anything more than "map" (since, again, a for-loop is very much capable of doing much more complex & powerful things).

So, that would be my "maximalist" sales pitch for the full range of patterns discussed above. But, as I said, I'd gladly accept the opposite verdict, too.