3 ms·
> If you're writing a lot of boilerplate in Go, you're either doing it wrong or chose it for something wildly out of its wheelhouse Like shoehorning a set use
by apta 7y ago
> If you're writing a lot of boilerplate in Go, you're either doing it wrong or chose it for something wildly out of its wheelhouse
Like shoehorning a set use case into a map? Or trying to get the list of keys or values in a map without writing out 5 lines of code?
I find golang code to be much more verbose than Java. You find code littered with one off functions that amount to nothing more than map/filter/etc. operations which are 1 liners in Java.
- jerf 7y agoI find my code occasionally has those things, and that it is a minor inconvenience, not that it is littered with it. If it is littered with it, you are probably in the "doing it wrong" category. Do not try to force Go to do "functional programming". Or you're way out of scope. (I have lost count of the number of people I've counseled to not use Go if their first interest is numeric programming, for instance.) (I am underwhelmed by the crowd that insists map/reduce/filter is so important anyhow. I've used a substantial amount of Haskell. In Haskell, map/reduce/filter is the beginning of the functional style, not the completion of it. It goes beyond just "an alternate way to write for loops", which is most of what I see non-Haskell usage doing with it. In Go... just write the for loops. It's the same thing, just spelled differently. In Haskell, it's not the same thing.)
- apta 7y ago> If it is littered with it, you are probably in the "doing it wrong" category. How else do you suggest transforming slices from one type to another, removing entries in slices based on certain conditions, etc. without looping? This is one of the most common operations in any basic application.