8 ms·

You discovered the Zen of Go. There are no magic one liners. It's boring, explicit and procedural. Proponents argue that this forced simplicity enhances produc

• goatlover 3y ago
  Go seems like the antithesis to Lisp.
• pharmakom 3y ago
  ... so the code ends up being really long then.
  • Spiwux 3y ago
    Yes, pretty much. It's a pain to write, but easy to read. On a larger scale the average engineer likely spends more time reading code than writing code
    • tuetuopay 3y ago
      I don't find go that easy to read. It is so verbose that the actual business logic ends up buried in a lot of boilerplate code. Maybe I'm bad at reading code, but it ends up being a lot of text to read for very little information. Like a one-line list comprehension to transform a collection is suddenly four lines of go: allocation, loop iteration, and append (don't even start me on the append function). I don't care about those housekeeping details. Let me read the business logic.
      • kiitos 3y ago
        Go offers a programming interface at a lower level of abstraction than languages like Python or Ruby. What you call boilerplate or housekeeping, I consider to be mechanical sympathy. Modulo extremes like Java, the bottleneck for programmers understanding code is about semantics, not syntax -- effectively never the literal SLoC in source files. It's not as if for i := range x { x[i] = fn(x[i]) } is any slower to read, or more difficult to parse, or whatever, than e.g. x.transform(fn) in any meaningful sense.
        • xmcqdpt2 3y ago
          Your example is very simple though. What's the go equivalent to x.map(fn).filter(predicate) ie returning a new collection of transformed items which is filtered by some predicate? Now we are talking more like 5-6 lines of Go.
          • kiitos 3y ago
            > What's the go equivalent to x.map(fn).filter(predicate) Probably something like var output []T for _, val := range input { if newval := transform(val); allow(newval) { output = append(output, newval) } } No problem?
            • xmcqdpt2 3y ago
              It's definitely less clear though, in that it involves an if statement with an assignment, three temporary variable declarations, etc. Also, type inference won't detect the type of the output automatically from the transform function type, and this of course assumes you wanted to collect into a slice, but it could be a set, or a list. For some operations, the Go style of explicit, mostly in-place mutations produces more complicated code. Whether that's balanced out by the code being "simpler" is not clear to me, but I haven't worked with Go.
              • kiitos 3y ago
                I see it as unambiguously more clear, because it makes explicit what the machine will be doing when executing the code. Whether map/filter copy values, or mutate in-place, or etc. etc. is non-obvious. I mean I'm not saying my way is the only way and I appreciate that other people have different perspectives but I just want to make it clear that "clear" in code isn't an objective measure, that's all.
                • xmcqdpt2 3y ago
                  I agree that there are no objective measure. I guess it's just different expectations. I would not say it's obvious what the machine is doing in the Go example though. For example it wasn't clear to me that append() mostly doesn't copy the full vector, but does a copy of the slice pointer. I had to look it up from a blog post, because the source for append() is gnarly https://github.com/golang/go/blob/go1.16.7/src/cmd/compile/internal/gc/ssa.go#L2841 https://github.com/golang/go/blob/go1.16.7/src/cmd/compile/i...
      • Cthulhu_ 3y ago
        It's a tradeoff; I too find one-liner list comprehensions like simple transforms or filters easier to read than the for loop equivalent. However, it's a dangerous tool that some people just can't be trusted with. Second, if you go full FP style, then you can't just hire a Go developer, they need additional training to become productive. Here's an example of functional programming within Go taken far: https://github.com/IBM/fp-go/blob/main/samples/http/http_test.go https://github.com/IBM/fp-go/blob/main/samples/http/http_tes.... It basically adds a DSL on top of Go, which goes against its principles of simplicity. There was another great resource that explains why functional programming in Go is a Bad Idea; one is function syntax (there's no shorthand (yet?)), the other is performance (no tail call optimization), and another is Go's formatter will make it very convoluted; I think it was this one: https://www.jerf.org/iri/post/2955/ https://www.jerf.org/iri/post/2955/
        • za3faran 3y ago
          First time I hear that list comprehension is a dangerous tool. The way python implements it is awkward I'll give you that, but there is a lot of success in how Java and C# implement it for example. golang just chose the easy and overly verbose way out, it's a theme they have that is visible in the rest of the language.
    • pharmakom 3y ago
      I think that shorter code is easier to read - to a point! on balance most code is too long, not too short.