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 (i.e., numeric computing). If

by jerf 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 (i.e., numeric computing). If you're writing a lot of boilerplate in Java, you're either doing it wrong, chose it for something wildly out of its wheelhouse, or you choose frameworks or libraries that have either forced or afforded high boiler-plate code. The latter is probably the major difference that is what people are feeling. On paper Go and Java are virtually the same language, but just a few differences in the spec and a bit of focus by the developer community means that Go just generally has less annotations, external XML files for this, weird build systems, and a whole bunch of other frippery. Although I do think that it's easy to underestimate how much cleaner it turns out to be to do interfaces the way Go does rather than Java. It seems like such a small change, but it has a big effect on how much OO boilerplate you need. You don't have to guess what interfaces someone may someday need and write them all out in advance. And, I mean, in both languages, let's not underestimate the amount of "doing it wrong". There's a lot of us whose exposure to Java is being on the receiving end of a pile of Java code that is not written with maximal skill and precision. That's not really Java's fault. (To the extent it is, it is not uniquely so; I can tell that story about a lot of languages.)

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 ago
  I 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.

by jerf 7y ago

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 ago
I 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.