3 ms·

Well, boilerplate is a nuisance, but it is cheap. It’s not generally where your bugs are coming from (and certainly not your most insidious bugs)—they come from

Well, boilerplate is a nuisance, but it is cheap. It’s not generally where your bugs are coming from (and certainly not your most insidious bugs)—they come from your complexity, especially your incidental complexity. In exchange, Go is a very easy language to learn, which is an important property for software development teams—you don’t need to restrict your hiring pool to candidates with experience in $language; you can train anyone to productivity in _days_. This is actual cost savings over a nebulous idea that boilerplate is evil. Anyway, Go needs generics and sum types and those two features get rid of 99% of boilerplate and still keep it below an order of magnitude of the complexity that you see in Java, C++, etc, so I don’t buy your argument that the extra features are a net positive value.

pjmlp 7y ago
The usual Go answer, Java boilerplate bad, Go's boilerplate good. Java was once like Go, and ironically DisVM also had support for Java, back in those days.
- weberc2 7y ago
  Usually your responses are well-reasoned and interesting; this one was disappointingly lazy. I didn’t say Java’s boilerplate was bad nor that Go’s was good. I criticized Go’s boilerplate and Java’s complexity.
  - pjmlp 7y ago
    Which Java only got by starting out just like Go, being a simple language against the establishment, catering for easy to hire resources, ignoring the likes of Delphi, Modula-3, Sather and Eiffel, while building up on C++'s familiarity. And adding half baked features to keep relevant while avoiding a Python 3, which any language that wants to survive in the market has to do, as not everyone can afford to alienate their user base. If anything, Java complexity is the Ghost of Christmas yet to come of Go's future.
    - weberc2 7y ago
      I think the important distinction is that Go holds simplicity as a virtue, while Java’s position was “please give us time to add all of the features you are requesting!”. How long was it before Java shipped exceptions and inheritance? If that isn’t a commitment to incidental complexity, what is? By the way, it’s fine that Java takes a different philosophy on simplicity; Go’s trade offs won’t suit every use case. But I think Go’s tradeoffs are better for more use cases by a pretty wide margin.
      - pjmlp 7y ago
        Java had exceptions and inheritance right from the start. If Go's wants to stay relevant it will eventually grow such features, no matter what. Even C now has such niceties like _Bool and _Complex, because adding them was not considered relevant, let alone the bags of money that have been spent trying to retrofit security solutions while keeping backwards compatibility with the "C Spirit". Oh and even if it is quite limited, modern C also has _Generic.
        weberc2 7y ago
        That’s the crux of the issue. Go aims to be useful, not relevant. Obviously some relevance is necessary for utility (a language isn’t useful if there is no community around it), but when you optimize for relevance directly, you end up with solutions in search of problems. Like inheritance.

pjmlp 7y ago

The usual Go answer, Java boilerplate bad, Go's boilerplate good. Java was once like Go, and ironically DisVM also had support for Java, back in those days.

weberc2 7y ago
Usually your responses are well-reasoned and interesting; this one was disappointingly lazy. I didn’t say Java’s boilerplate was bad nor that Go’s was good. I criticized Go’s boilerplate and Java’s complexity.
- pjmlp 7y ago
  Which Java only got by starting out just like Go, being a simple language against the establishment, catering for easy to hire resources, ignoring the likes of Delphi, Modula-3, Sather and Eiffel, while building up on C++'s familiarity. And adding half baked features to keep relevant while avoiding a Python 3, which any language that wants to survive in the market has to do, as not everyone can afford to alienate their user base. If anything, Java complexity is the Ghost of Christmas yet to come of Go's future.
  - weberc2 7y ago
    I think the important distinction is that Go holds simplicity as a virtue, while Java’s position was “please give us time to add all of the features you are requesting!”. How long was it before Java shipped exceptions and inheritance? If that isn’t a commitment to incidental complexity, what is? By the way, it’s fine that Java takes a different philosophy on simplicity; Go’s trade offs won’t suit every use case. But I think Go’s tradeoffs are better for more use cases by a pretty wide margin.
    - pjmlp 7y ago
      Java had exceptions and inheritance right from the start. If Go's wants to stay relevant it will eventually grow such features, no matter what. Even C now has such niceties like _Bool and _Complex, because adding them was not considered relevant, let alone the bags of money that have been spent trying to retrofit security solutions while keeping backwards compatibility with the "C Spirit". Oh and even if it is quite limited, modern C also has _Generic.
      - weberc2 7y ago
        That’s the crux of the issue. Go aims to be useful, not relevant. Obviously some relevance is necessary for utility (a language isn’t useful if there is no community around it), but when you optimize for relevance directly, you end up with solutions in search of problems. Like inheritance.