3 ms·

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 c

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

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.