3 ms·
Go design is not around being concise as possible, in fact it's the complete opposite. One of the cores behind Go is to make language simple, even if at the ex
by joaohaas 2mo ago
Go design is not around being concise as possible, in fact it's the complete opposite.
One of the cores behind Go is to make language simple, even if at the expense of more verbose code.
Two main examples of this is the infamous 'if err != nil' and how you handle filter/map/funcional operations.
- bushbaba 2mo agoYes but it’s err not error. The variable and method names are meant to be concise and highly readable without the CS fluff of Java naming hell.
- joaohaas 2mo agoI don't think naming convention is the kind of stuff that helps save tokens, specially considering how text is tokenized. On the other hand, being able to write 'list.filter(v => v.selected)' (or something similar) instead of: listFiltered := []Item{} for _, item := range list { if item.selected { listFiltered = append(listFiltered, item) } } would save much more tokens.
- maleldil 2mo agoYou can have that with generic functions, although Go's lambda syntax is too verbose. The slices package has DeleteFunc, which is kind of the opposite. I don't know why they have Filter. https://pkg.go.dev/slices#DeleteFunc https://pkg.go.dev/slices#DeleteFunc
- Cthulhu_ 2mo agoWhile Go has first-class functions and the like, functional programming is discouraged in Go; it's not optimized for it in either the language or the compiled result. It doesn't have tail call optimization for example, and naive functional coding may look "nice" (especially if it had for example arrow function syntax), but it won't have "mechanical sympathy". That is, no functional code (in Go) will be as fast as just iterating over a slice. [0] has some good reasonings too, with history. [0] https://www.reddit.com/r/golang/comments/c2a7b0/why_isnt_go_functional/ https://www.reddit.com/r/golang/comments/c2a7b0/why_isnt_go_...]
- Cthulhu_ 2mo agoVariable naming is a convention though, not a language feature.