131–135 of 135 posts
I write primarily in Go, I have to admit that I can't stand the name of it. When doing a search I constantly have to write "go golang" in my searches to get relevant results. It's too generically named, like naming something "The"
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
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.
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 the…
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.
Earlier quoted context omitted.
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 the…
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…
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.
Earlier quoted context omitted.
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…
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…